Chat: same models, same prices, in the browser

Every model listed on Onlist can now be opened in a browser chat at /chat. Pick a model, pick a provider or let routing decide, and talk to it. There is no API key to create and no SDK to install: sign in and send.

Most gateways have a playground, so the existence of a chat page is not news. The decision underneath it is what this post is about.

One billing pipe, not two

A web chat request travels the exact same pipeline as an API request: the same listing, the same provider price, the same prepaid wallet, the same settlement record. There is no separate "web price", no free allowance quietly funded by marking something else up, and no separate infrastructure that behaves differently from what your code will hit later.

We considered the alternative and rejected it. Onlist is a marketplace: providers set prices and buyers compare them. If browser users paid different effective prices than API users for the same listing, the price a provider advertises would mean two different things depending on which door you walked in through. That breaks the one number the whole marketplace is built on.

The consequence is occasionally blunt. If your wallet is empty, chat tells you so, the same way the API would. In exchange, what you observe in chat (latency, output quality, how a provider handles a long prompt) is exactly what your application will observe, because it is the same route.

Chat calls are tagged separately in your usage log, so a browser experiment never gets confused with production traffic.

What is in the box

• A model picker with search and category groups, plus a filter for models that accept image input.
• A provider picker. The default is automatic routing by price and availability. You can also pin one seller; each candidate row shows its rating, price, and 7-day availability, the same signals the routing layer weighs.
• Streaming by default, with a stop button.
• Image input, up to four images per message.
• Reasoning models show their thinking in a collapsible section instead of dumping it into the answer.
• A per-conversation system prompt.
• A chat memory control. By default only the last 8 messages are resent with each turn. Chat interfaces resend history on every message, so sending everything makes cost grow quadratically with conversation length. The default keeps casual chats cheap; you can raise the window, up to unlimited, when a task needs full context.
• Separate image generation sessions for image models, with reference-image editing.

What it does not do yet

Conversations are stored in your browser, not on our servers. That is partly a privacy stance and partly a missing feature: chat transcripts are never persisted server-side, and consequently there is no sync between devices. Clear your browser storage and the history is gone. Cloud sync is on the list; it is not there today.

There is no web search. The model answers from what it knows, and OpenRouter-style :online suffixes are not supported (the models doc says so explicitly). Sampling parameters like temperature are currently fixed at sensible defaults. And a few listings marked "Claude Code only" are greyed out, because those providers accept traffic from the Claude Code client and nothing else.

Why bother

The obvious reason is trying a model before wiring it into code. The marketplace reason is better: chat is the fastest way to compare sellers of the same model. Open two conversations, pin a different provider in each, and ask the same question. Same model id, same billing mechanics as production, and any difference you see is the providers themselves.

Your first conversation costs what the listing says it costs, and not a different number because you used a browser.

Open Chat →