Mercury 2.5 Review: Fastest Model for Latency Sensitive Workloads

Inception has released Mercury 2.5, the latest model in their diffusion LLM family. Where most models generate text one token at a time, Mercury starts from a rough draft and refines tokens in parallel. Inception reports that this gets Mercury 2.5 to 1,107 tokens per second on widely available NVIDIA GPUs.

A model that fast opens up things slower models cannot do comfortably. Search agents that fire a dozen calls before answering, voice pipelines, coding assistants doing context compaction in the background, anywhere a request budget gets spent many times over inside a single user action.

So we wanted to see what the speed looks like in practice. Tokens per second is one measure of speed, and it is the one in the announcement. It is not the only one. A model can generate tokens quickly and still leave the user staring at a blank screen, because throughput describes how fast text comes out once it starts, and time to first token describes when it starts. We measured both.

What we tested

We tested Mercury 2.5 against three other models. We included Mercury 2, its predecessor, to see what changed inside the family, plus Claude Haiku 4.5 and Gemini 3.5 Flash-Lite, which Inception names in its announcement as comparison points. It says Mercury 2.5's quality is comparable to cost-optimized models including GPT-5.6 Luna at low reasoning, Gemini 3.5 Flash-Lite, and Claude Haiku 4.5.

Four prompts, run five times against each model, medians reported. We then repeated the entire benchmark a second time on a separate run to check the numbers held.

The first three prompts are short, 11 to 15 tokens each, so that prompt processing is not a variable. They are reproduced in full below, exactly as sent, with no system prompt and no options set beyond the model and streaming.

Answer in one sentence: what is a vector database?

Return JSON with 5 fields describing a fictional user account. JSON only.

Write a 600-word explanation of how HTTPS works.

The fourth inverts the shape. It sends a large block of filler text and then asks for a one-line summary, which isolates prompt processing rather than generation. That is the shape of a RAG or compaction workload. The filler is this paragraph, repeated 60 times.

The distributed system maintains consistency through a consensus protocol in
which each node proposes a value and the cluster converges on a single accepted
result. Replication lag is monitored continuously and the coordinator demotes
any replica that falls behind the configured threshold. Write amplification is
tracked per shard because compaction cost dominates the storage budget at this
scale.

Followed by two newlines and the instruction.

Summarize the text above in one line.

To rebuild it exactly, take that paragraph as a single line ending in one trailing space, repeat it 60 times with no separator, then append \n\nSummarize the text above in one line. The paragraph is 66 tokens, so the assembled prompt comes to 3,911 tokens and 24,039 characters.

For each request we recorded the time the request was sent, the time the first piece of text arrived, the time the stream closed, and the full text of the response. We counted output tokens by tokenizing the returned text rather than reading the API's usage field, so that the counts refer to text that actually reached us.

Throughput holds up

We used the 600-word prompt for this, since it is the only one that generates enough text for a throughput number to mean anything. For each of the ten runs we divided the tokens returned by the time between the first and last piece of text, then took the median of those ten rates.

Inception's published figure of 1,107 tokens per second sits inside our range and a little below our median, so the claim held. It held loosely rather than precisely. Mercury 2.5 was the most variable model in the set, swinging between 727 and 1,756 tokens per second across runs, where Claude Haiku 4.5 stayed within two tokens per second of its median every time.

Against the two autoregressive models the gap is roughly 5x to 15x, in line with the order of magnitude Inception has been claiming since Mercury 2. Once Mercury 2.5 starts producing text, it produces it faster than anything else we tested, by a wide margin.

One note on reading that table. Mercury 2.5 returned a median 569 tokens over a median 474ms generation window, and dividing those two medians gives 1,199 rather than 1,241. Both figures are defensible, and they differ because the median of a set of ratios is not the ratio of the medians. We report the median of the per-run rates, because each run is a real observation of the model's speed where the divided figure is not any run that actually happened.

Time to first token is a different story

The picture changes when we measure when the text starts rather than how fast it moves.

Median time to first token, in milliseconds, across two independent runs of five repetitions each.

Mercury 2.5 was the slowest of the four to produce its first character in every condition, and the two runs agree closely enough that this is not noise. On the 600-word prompt it took around five seconds before anything appeared, while the other three models started producing text in roughly 0.6 seconds.

Some of this is network, but not much of it. Our baseline to the API endpoint measured a median 85ms time to first byte, with a range of 59ms to 233ms across five requests. All four models were called from the same machine in the same session over the same connection, so the network affects them equally. The spread between 5,000ms and 600ms is the model, not the wire.

The prefill row is worth reading closely, because it rules out an obvious explanation. If Mercury 2.5 were simply slow at reading input, the 3,911-token prompt would have been its worst case. It was not. Mercury 2.5 handled the long input faster than it handled the short input with a long output. The delay scales with how much text the model is going to write, not how much it has to read.

One other thing showed up that we did not expect. Mercury 2 was consistently faster to first token than Mercury 2.5, by 2.3x on the short prompt and 8.3x on the long one. Inception's announcement says Mercury 2.5 ships with more intelligence, lower cost and the same speedup over traditional models. On throughput that holds, and Mercury 2.5 clears Mercury 2 by roughly 3x. On first-token latency the newer model was behind the older one throughout. Mercury 2 has had several months of serving optimization behind it and Mercury 2.5 is new, so we would expect this gap to move.

Why the two numbers disagree

Tokens per second and time to first token measure different halves of the same request, and for a diffusion model those halves are unusually lopsided.

An autoregressive model produces token one, then token two, then token three. It can send each one as soon as it exists, which is why text appears quickly and then trickles. Its throughput number and its latency number describe more or less the same process.

A diffusion model works on the whole output at once, refining a draft until it is finished. There is no partial answer to send along the way, because until the refinement passes are done the draft is not text anyone would want to read. So the request is mostly silence, then the finished output.

That is why Mercury 2.5 can be both the fastest and the slowest model in this test without contradiction. Measured across the whole request rather than just the generation window, its effective rate on the 600-word prompt was 106 tokens per second, against 364 for Mercury 2, 214 for Gemini 3.5 Flash-Lite and 78 for Claude Haiku 4.5. The 1,241 figure is real, and so is the five second wait in front of it.

So is it the fastest model for latency sensitive workloads?

It depends entirely on what is waiting at the other end.

If the consumer is another program, Mercury 2.5 is a strong choice. On the 600-word prompt it finished the whole request in a median 5.7 seconds against 9.4 for Claude Haiku 4.5. For batch summarization, context compaction, reranking, structured extraction or anything else where a pipeline collects the finished output and moves on, arriving first is what matters and Mercury 2.5 arrives first.

If a person is watching the screen, the calculation inverts. Five seconds of nothing followed by a wall of text reads as slower than text that starts in half a second and streams, even when the streaming model finishes later. Perceived latency tracks first token, not total time.

The honest answer is that Mercury 2.5 is the fastest model we tested at producing text, and the slowest at starting. Which of those two facts matters is a property of your workload rather than of the model.

We would also treat these numbers as a snapshot. Mercury 2.5 is days old, we tested through one route on one day, and first-token latency is exactly the kind of thing that improves as serving infrastructure settles. We plan to re-run this and will update the post if the picture changes.

Try It Yourself

You can use Mercury 2.5 through Puter.js, which gives you access to it and every other model in this post through one interface with no API keys. It uses a User-Pays Model, so people running your app cover their own inference.

For a plain HTML page, add the script tag.

<html>
<body>
  <script src="https://js.puter.com/v2/"></script>
  <script>
    puter.ai.chat("Explain how HTTPS works.", {
      model: "inception/mercury-2.5"
    }).then(response => {
      document.body.innerHTML = response.message.content;
    });
  </script>
</body>
</html>

Or install it from npm.

// npm install @heyputer/puter.js
import { puter } from '@heyputer/puter.js';

puter.ai.chat("Explain how HTTPS works.", {
    model: "inception/mercury-2.5"
}).then(response => {
    document.body.innerHTML = response.message.content;
});

Given how Mercury 2.5 behaves, streaming is worth turning on. Pass stream: true and iterate the response.

const resp = await puter.ai.chat("Write a 600-word explanation of how HTTPS works.", {
    model: "inception/mercury-2.5",
    stream: true
});

for await (const part of resp) {
    if (part.type === "text") document.body.append(part.text);
}

Swap the model string to try the others. Mercury 2 is inception/mercury-2, Claude Haiku 4.5 is anthropic/claude-haiku-4-5, and Gemini 3.5 Flash-Lite is google/gemini-3.5-flash-lite.

FAQ

When was Mercury 2.5 released? Inception announced Mercury 2.5 in September 2026. A preview version, listed separately as Mercury 2.5 Preview, appeared shortly before the general release through OpenRouter.

What does Mercury 2.5 cost? Reported standard pricing is $0.20 per million input tokens and $0.75 per million output tokens, with an 80 percent launch discount bringing those to $0.04 and $0.15. Several third-party trackers currently list only the discounted rates. We have not verified these against an invoice, and the discount is a launch promotion, so treat them as current at time of writing rather than settled.

What is the context window? 260K tokens, roughly double the 128K in Mercury 2, with a maximum output of 65,536 tokens.

What changed compared to Mercury 2? Inception reports roughly a 40 percent intelligence gain, along with tunable reasoning, parallel tool calls and schema-aligned JSON output, plus the larger context window. In our own testing Mercury 2.5 was around 3x faster than Mercury 2 on generation throughput, but slower to first token in every condition we measured.

Is Mercury 2.5 really 1,107 tokens per second? In our testing the median generation rate was 1,241 tokens per second on a 600-word prompt, with individual runs ranging from 727 to 1,756, so Inception's figure sits inside what we measured. Note that this describes the rate once text starts arriving. Measured across the whole request including the wait, the effective rate was 106 tokens per second.

Is Mercury 2.5 open source? No. It is proprietary, available through Inception's API, Baseten and OpenRouter, and through aggregators including Puter.

Does it support tool calling and JSON output? Inception lists parallel tool calls and schema-aligned JSON output as Mercury 2.5 features. We exercised JSON output in this test and it returned valid JSON on every run. We did not test tool calling.

Related

• Inception Mercury 2 Is Now Available in Puter.js
• Introducing Mercury 2.5, Inception's announcement
• puter.ai.chat() reference