Yesterday — 11 September 2026 — one of my long generations came back at roughly 250 tokens per second. Not a spec sheet and not a vendor benchmark: one run, on my own account, with the rate visible in the client. It was fast enough that I stopped and checked the number twice.
Here is what a rate like that actually means.
What 250 tokens per second buys you
The arithmetic is simple: 15,000 tokens a minute, or roughly 900,000 tokens an hour of continuous output. In practice, a generation ends while you are still reading the prompt:
- a 500-word answer (~670 tokens) lands in under 3 seconds
- a 1,000-token reply — a full page of prose — in 4 seconds
- a 2,000-token chunk of code or a long refactor in 8 seconds
- a 4,000-token file in 16 seconds
The other side of the comparison
The other model I run comes in around 30 tokens per second — same kind of work, roughly eight times slower. The arithmetic is unforgiving:
- a 500-word answer: under 3 seconds against 22 seconds
- a 1,000-token reply: 4 seconds against 33 seconds
- a 4,000-token file: 16 seconds against 2 minutes 13 seconds
That gap is not cosmetic, it changes behaviour. At 30 tokens per second you batch, you write smaller prompts, and you let context go stale because re-reading it costs minutes. At 250, those habits stop being necessary — and an agent loop that retries three times costs a few seconds instead of a coffee break.
Put together with everything else I run, it seems DeepSeek Flash is simply the fastest model I have access to right now — not by a few percent, but by a factor of eight. That is an observation about my own setup and my own workloads, not a league table: a different connection, a different host, or a much larger model would tell a different story.
Two caveats, because a rate comparison is easy to over-read. The 30 tokens per second figure is my own observation from normal use, not a benchmark — same as the 250. And rate is not quality: a slower model can be the better one on the task in front of you. This is about how long you wait, not about which answer is right.
Why speed changes how you work, not just how it feels
The interesting effect is not comfort, it is the shape of the work. When a 4,000-token answer costs 16 seconds, you stop batching: you ask for the whole file instead of a diff, you ask for the paragraph to be rewritten instead of patched, and you let an agent loop take three attempts instead of one. Latency is the tax on iteration, and at this rate the tax mostly disappears.
There is a practical consequence for agent setups specifically. The expensive part of a loop stops being the generation and becomes the tool calls around it — when the model writes faster than your script can save the file, the bottleneck has moved somewhere else. Worth knowing before you spend effort optimising the wrong half.
The honest caveats
A single run is not a benchmark, and I would distrust anyone who presents one as if it were:
- Output rate is not throughput. 250 tokens per second is what came back out. The prompt still has to be read first, and prefill is a separate cost that grows with context.
- It varies with time of day and load. DeepSeek runs an off-peak discount window, so both price and speed follow the queue. My 250 will not be everyone's 250.
- It varies with what you ask for. A short answer, a long code block and a heavy tool-use turn do not sample the same path. One number cannot describe all of them.
- It says nothing about quality. A fast wrong answer is still wrong. Speed only makes it cheaper to iterate until it is not.
The bigger point
Speed like this deserves attention for a second reason: it is not a closed API party trick. The model behind it shipped with open weights, as I noted when DeepSeek V4.1 Flash was released, which means behaviour in this range will eventually show up wherever the model can be hosted — including your own hardware, at whatever rate that hardware manages.
So I will keep measuring. When a number like this appears in a single run, the useful next step is not to publish the trophy — it is to run it ten more times and find out what the floor looks like. That is the part that tells you whether it is a fast model or a lucky one.
