Mercury 2.5 Posts 770 Tokens per Second — and the Caveats Behind the Number
A model page lists Mercury 2.5 at 770 output tokens per second, drawing 103 points and 63 comments on Hacker News. Here is what that number does and does not say about real-world use.
What 770 tokens per second actually means
Artificial Analysis lists Mercury 2.5 at 770 output tokens per second. The figure drew 103 points and 63 comments on Hacker News.
For scale: a fast human reader takes in roughly four or five English words a second. At 770 tokens per second, a model can finish a paragraph before you have read its first line. That is past the point where a user watches text appear. The text is simply there, and interfaces built around waiting start to look wrong.
The caveat is that tokens per second is never a bare number. Every published speed is measured under chosen conditions: a particular hardware pool, a batch size, a context length, a concurrency level. What you get from a production endpoint on a busy afternoon is a different measurement, and the gap between the two can be wide. Treat a headline speed as a good-day ceiling, not a promise attached to each request.
Background matters here too. Mercury comes from Inception Labs and is built around parallel, diffusion-style generation rather than the autoregressive decoding most models use. Speed is the thing that approach most needs to prove, which is worth keeping in mind when reading its own benchmark page.
Why output speed became a hard metric
For several years, model comparisons revolved around quality: reasoning, code, math. Speed sat further down the list. Agentic workflows flipped the order.
A single task can now require thousands of output tokens, with tool calls, returned results, and new decisions in between. Output speed multiplies into real waiting time — a 20-second generation becomes minutes inside a loop that runs a dozen turns. Code completion, long-form drafting, and live transcription all feel the same pressure.
The other direction is batch work. There, tokens per second converts directly into how much a GPU can finish in a day, and from there into cost. Speed stops being a user-experience question and becomes an accounting one.
What a leaderboard can and cannot tell you
The value of a site like Artificial Analysis is comparability: one harness, one yardstick, many models placed side by side. For a quick read on an unfamiliar model, that kind of page is still the fastest entry point.
Several things sit outside the yardstick. Correctness is untouched by a throughput number. Whether a service holds its speed at peak hours is a question about operations, not benchmarks. Price, context window, and the reliability of tool calling are not on that curve either. Mercury 2.5 at 770 tokens per second is evidence of throughput, not of overall capability.
The attention on Hacker News — 103 points, 63 comments — says people are watching this space closely. Attention is its own metric, and it is not the same thing as quality.
What developers should take from it
Re-run the measurement on your own workload. Real prompts, real concurrency, real context lengths, not the short samples a benchmark page favors.
Separate time to first token from output speed. The first decides when text starts appearing; the second decides how long until it finishes. Conversational products are sensitive to both. Long-generation and batch pipelines mostly live or die on the second.
Mercury 2.5 at 770 tokens per second is worth noting as a reminder more than as a verdict. Once output speed clears a certain threshold, a lot of default assumptions in interface design have to be recalculated. Whether this technical route also holds up on quality will take longer evaluation and real usage to settle.