DeepSeek AI chat online, plus the reference we actually tested

Using it without an account

The chat at the top of this page is the whole product. Type a question, press Enter, read the answer. There is no sign-up form, no email verification, no trial that expires and no card on file. That is unusual enough to be worth explaining rather than just claiming.

The trade-off is that nothing is tied to you, which cuts both ways. There is no saved history across devices, no way to pick up yesterday's thread on your phone, and no support ticket we can look up if something goes wrong. The conversation lives in the browser tab and is gone when you close or reload it. It is not written to your browser's storage and it is not written to ours. We hold the last 20 messages of context in memory so the model follows a conversation — a question and its reply are two messages — and that context never touches our database.

Fair use is five messages a minute, thirty an hour and one hundred a day. Those limits exist because the API costs real money per token and one script left running would drain the budget for everyone else inside an hour. If you hit the minute limit, wait sixty seconds; the hourly and daily allowances take longer to reset, and the message tells you which one you have reached. There is no paid tier that lifts them.

Picking a model for the job

The toggle offers Fast and Pro. Fast is the right default for most everyday questions: rewriting a paragraph, explaining an error message, sketching a function, summarizing something you paste in. It answers in a couple of seconds and is rarely the reason an answer is wrong.

Pro is worth the wait when the problem has several dependent steps — a proof, a refactor across files, a schema design with constraints that interact. In our own long-context benchmark the larger tier scored 56.3% on strict exact retrieval against 49.3% for the faster one. That gap is real but it is not the difference between useless and reliable; both need checking.

There is also a vision tier that accepts an image alongside text and returns text. It is not wired into this chat, which is text-only, but it is available through the API and priced the same as the fast tier.

What the pricing actually works out to

Published rates are per million tokens, and a token is roughly four characters of English. A dense page of prose is about 700 tokens. That makes the arithmetic less alarming than the model names suggest.

At the fast tier's cache-miss input rate, feeding in a 50-page document costs a few cents. The output side is where spend accumulates, because generation is priced at three times input and long answers are long. A chatbot answering a thousand questions a day with 500-token replies is spending single-digit dollars a day, not hundreds.

Two things move the number more than the tier does. Off-peak billing is materially cheaper, so batch work that can wait should wait. And cache hits on a repeated prefix are priced at a fraction of a cache miss — if you are sending the same long system prompt on every call, structuring it so it caches is the single highest-leverage change you can make.

Running the open weights

Weights for several models are published, which is the main structural difference from the closed frontier labs. You can download them and run them on your own hardware, which means no per-token cost, no data leaving your network, and no dependency on anyone's uptime.

The catch is hardware. The smaller distilled models run on a decent consumer GPU and are genuinely useful for classification, extraction and simple drafting. The full-size models need multiple data-center cards, and quantizing them down to fit consumer hardware costs accuracy in ways that are hard to predict from the benchmarks. Ollama and LM Studio make the small end easy; vLLM is the sensible choice once you are serving more than one person.

Check the license for the specific release you intend to use rather than assuming. Terms differ between model families, and "open weights" is not the same as "do anything you like with it".

Getting better answers out of it

Most disappointing answers are underspecified questions. The model cannot see your codebase, your house style or the constraint you did not mention, and it will not ask — it will guess, confidently.

State the format you want. Say how long. Give it the constraints that matter, including the ones you think are obvious. If you want code, name the language, the version and the libraries already in the project. Paste the actual error rather than describing it. When an answer is close but wrong in one respect, say which respect instead of starting again — the context is still there and correcting is cheaper than re-asking.

For anything you will act on, ask it to show its reasoning or list its assumptions. A wrong answer with visible assumptions is easy to catch. A wrong answer delivered as a flat assertion is not.

Where it falls down

Citations are the clearest failure we have measured. Testing DeepSeek’s official consumer chat with Search enabled, in a 24-question July 2026 baseline, 79.2% of citation URLs (76 of 96) resolved to a real source, but only 69.8% of claim-to-citation links (118 of 169) actually supported the claim, and just 4 of 24 questions passed a strict review. That test covered the official consumer chat with Search on — not the API, and not this site’s chat. A plausible URL attached to an unsupported sentence is worse than no citation, because it looks like evidence.

Long context is the second. A million-token window is a capacity, not a promise: retrieval accuracy in our benchmark was 49.3% on the fast tier and 56.3% on the larger one across synthetic exact-match tasks, and latency at the 95th percentile reached 162 seconds. Putting an entire codebase in the prompt is possible; relying on the model to find the one relevant line is not.

Then the ordinary ones. No live web access, so nothing about this week. It cannot open a link you paste. Arithmetic on long numbers is unreliable. And it will invent a plausible library function rather than say it does not know one exists.

Privacy, and what not to paste

When you send a message here, it goes from your browser to our server and from there to the API. We do not write it to a database and we keep no transcript. But it does reach a third party we do not control, and what happens to it after that is governed by their terms, not ours.

So treat the box as a public form. No passwords, no API keys, no card or bank details, no government identifiers, no medical records, nothing covered by a confidentiality obligation to a client or an employer. If you would not paste it into a stranger's website, do not paste it here. For genuinely sensitive work, run the open weights locally, where nothing leaves your machine.

Where the numbers on this page come from

Prices and specifications are taken from the published documentation and carry the date we checked them. Benchmark figures are from runs we performed ourselves, with the method, the sample size and the raw results published on the research pages so you can disagree with our reading of them.

When something we published turns out to be wrong we correct the page and change the date rather than quietly editing it away. Nothing here is sponsored, and DeepSeek does not review, approve, fund or influence anything we publish. Site pages are written and checked by a human editor before publication; chat replies are generated on demand and nobody reviews those before you see them.

Against the closed frontier models, the argument is price and openness rather than raw capability. On output tokens the gap is large enough to change what is economically sensible to build: workloads that would be uncomfortable at frontier pricing become routine, and the ability to download weights removes the dependency entirely. On the hardest reasoning and on polished long-form writing, the frontier labs still have an edge that shows up in practice, not just in benchmarks.

Against the other open-weight families, the comparison is quality per parameter and clarity of license. Several competing releases match or beat these models on individual benchmarks at similar sizes, and some carry more permissive terms. What is harder to match is the combination of published weights and a cheap, well-documented hosted API from the same source — you can prototype against the API and move to your own hardware later without rewriting anything.

The honest weakness is consistency. Capability moves between releases in ways that are not always obvious from version numbers, and behavior that worked in one checkpoint can shift in the next. If you are building something durable, pin a model version, keep a small evaluation set of your own, and re-run it when you upgrade.

The pragmatic way to choose: start with the cheapest tier that could plausibly work and measure it on your own task rather than on a leaderboard. Move up a tier only where you can show the cheaper one failing. Consider local weights when data cannot leave your network, when volume makes per-token pricing painful, or when you need a model that will not change under you. For everything else, the hosted API at the fast tier is almost always the right starting point.