On 8 September 2026, Inception, a startup building diffusion-based language models, released Mercury 2.5. Its two headline claims are a generation speed of 1,107 tokens per second on widely available NVIDIA GPUs, and a 40 percent gain in capability over the previous Mercury 2, which the company says brings it in line with cost-optimized frontier models. The specifics are less interesting than what they illustrate: almost every large language model you have used works one way, and Mercury works another. Understanding the difference explains where a model like this fits and where it does not.
How ordinary language models write
The models behind most chat assistants are autoregressive. They generate text one token at a time, strictly left to right, and each new token is chosen based on everything written so far. It is the sentence-completion mechanism taken to its logical end: predict the next word, append it, then predict the next word again, thousands of times over.
This design is why these models are so coherent, and also why they are fundamentally sequential. You cannot compute the tenth word until you have computed the ninth, because the ninth is part of the input for the tenth. Speed is therefore capped by how fast the hardware can run the model once per output token, and a long answer means running it many times in a row. Throughput has improved enormously through better chips and software, but the left-to-right dependency is baked into the architecture.
Two ways to generate text
The architecture behind most chat assistants writes sequentially. A diffusion model writes in parallel, which is where its speed comes from.
The same property that lets a diffusion model paint every pixel at once lets it draft every token at once.
How a diffusion model writes
Diffusion models come from image generation, where they learned to turn random noise into a picture by removing the noise in steps. Applied to text, the idea inverts the autoregressive approach. Instead of committing to one word at a time, a diffusion language model starts with a rough, noisy draft of the entire output at once and then refines it over several passes, sharpening all the tokens in parallel until the text resolves into something coherent.
An autoregressive model writes a sentence one word at a time. A diffusion model sketches the whole sentence and then brings it into focus.
On the core architectural difference
The payoff is parallelism. Because a diffusion model refines many tokens simultaneously rather than emitting them in a strict sequence, it can use the hardware far more fully and produce output much faster. That is where a figure like 1,107 tokens per second comes from: not a faster chip, but an architecture that does not have to wait for each token before starting the next. The same property that lets a diffusion model paint every pixel at once lets this kind of model draft every token at once.
The trade-off that has always defined diffusion text
None of this is free, and the honest history matters. Diffusion language models have existed for a while, and their persistent weakness has been quality: for a long time they generated text noticeably faster but noticeably worse than the best autoregressive systems. The interesting claim in the Mercury 2.5 release is not the speed, which diffusion has always had, but the assertion that it has closed enough of the quality gap to be comparable to cost-optimized frontier models while keeping the speed advantage.
A reported 40 percent capability gain
Inception's claimed improvement from Mercury 2 to Mercury 2.5, shown as a relative index with Mercury 2 set to 100. This is a company-reported figure against its own prior model, not an independently verified placement against the broader field.
The interesting claim is not the speed, which diffusion has always had, but a quality gain that keeps the speed advantage.
That claim deserves the standard caveat: the capability figures are the company's own, measured on its chosen benchmarks, and independent evaluation is what settles whether a new model is as good as it says. The 40 percent improvement over Mercury 2 is a relative number against the vendor's prior model, not an absolute placement against the broader field. The pattern to watch is not the single benchmark but whether diffusion models keep narrowing the quality gap while holding the speed lead. If they do, the architecture stops being a curiosity and becomes a genuine option for a class of workloads.
Where speed is the product
The reason a fast model matters is that not every task values the same thing. For a hard reasoning problem answered once, raw quality dominates and a few extra seconds are irrelevant. But a growing share of AI work is the opposite: high volume, latency sensitive, and repetitive. Agentic systems that make many model calls in a loop, code assistants that need to feel instant, and any application processing large batches of text all pay for slowness directly, in user-facing lag and in compute bills.
For those workloads, a model that generates an order of magnitude faster at a low price per token, Mercury 2.5 is listed at 20 cents per million input tokens and 75 cents per million output, changes what is economically feasible. Speed here is not a vanity metric; it is the difference between an agent that completes a long chain of steps in seconds and one that stalls, and between a batch job that costs a little and one that costs a lot. This is the segment diffusion models are aimed at, and it is a real and expanding part of the market.
The case for keeping your options open
The rise of a credible diffusion model alongside the dominant autoregressive ones is a specific instance of a general truth: the model layer is diversifying, and different architectures are becoming genuinely better at different jobs. A frontier autoregressive model for the hardest reasoning, a fast diffusion model for a latency-sensitive agent loop, a specialized model for a narrow scientific or coding task, the sensible design increasingly uses more than one.
That is exactly why locking an application to a single model is a quietly expensive decision. It forecloses the ability to send each task to the architecture that serves it best, and it leaves performance and cost on the table as the field moves. Keeping AI work portable across models and providers, the principle behind model-agnostic platforms like Metir, is what lets a team adopt something like a fast diffusion model for the workloads it suits without rebuilding around it, and keep the frontier model where quality still wins.
The measured read on Mercury 2.5 is that the speed is real and architectural, the quality claim is plausible but company-reported and awaiting independent tests, and the significance is less about one model than about a viable second way of building them. Autoregressive generation is not going away; it remains the best approach for the hardest problems. But a fast, cheap, parallel alternative that is closing the quality gap is a useful addition to the toolbox, and the teams positioned to benefit are the ones that did not commit everything to a single way of doing it.
Sources:
- Introducing Mercury 2.5 | Inception Labs
- Inception's Mercury 2.5 Hits 1,107 Tokens per Second, Beating Autoregressive Models | AlphaSignal
- A Diffusion Model Now Writes 1,100 Tokens a Second, Cheaply | Digital Applied
- Inception launches Mercury 2.5 diffusion model, boosts intelligence by 40% | Crypto Briefing
Image credits
Hero image: a server hall at The National Archives (UK), via Wikimedia Commons, licensed under CC BY 3.0. In-body photograph: a server room, "139 Server Room 01," via Wikimedia Commons, licensed under CC BY-SA 3.0. Both images illustrate data-center hardware generally and do not depict Inception's infrastructure.