Mercury 2.5 Guide: What Changed in Inception's Diffusion LLM

Mercury 2 showed, on Inception's own measurements, that a diffusion language model could reason at speeds few autoregressive models reach. The open question was whether it could get smarter without losing that speed. Mercury 2.5 is Inception's answer, and the useful way to read it is as a list of what moved and what did not.

Inception released Mercury 2.5 on 8 September 2026 and calls it its most capable production model, and, to its knowledge, the largest diffusion language model trained so far. It does not publish a parameter count. Like its predecessor it is a hosted, text-only model with tool calling, schema-aligned JSON and tunable reasoning, available through Inception's API, Baseten and OpenRouter. If diffusion decoding is new to you, the Mercury 2 guide explains how it works.

What moved, side by side

Comparing Inception's own figures for the two models:

• Context window — 128K for Mercury 2, 260K for Mercury 2.5.
• Throughput — 1,009 tokens per second on Blackwell for Mercury 2; 1,107 tokens per second on widely available NVIDIA GPUs for 2.5. The hardware descriptions differ, so treat this as the same speed tier rather than a 10% gain.
• Quality — Inception claims a 40% increase in intelligence over Mercury 2 without naming the index behind that figure.
• Tool use — 2.5 adds parallel tool calls to the feature list.
• List price — input falls from $0.25 to $0.20 per million tokens; output stays at $0.75.

The announcement does not say which benchmarks or index produce the 40% figure. Treat it as a direction rather than a measurement, and rerun the tasks you care about, since a headline gain rarely lands evenly across task types.

Read the launch price as a promotion

At the time of writing OpenRouter lists Mercury 2.5 at about $0.04 per million input tokens and $0.15 per million output. Those match the 80% launch discount Inception announced on top of its standard $0.20 and $0.75. Inception has not said when the promotion ends.

Budget at list price. A pipeline that looks almost free at $0.15 output costs five times as much on the day the discount lapses, and teams that sized volume around the promotional rate will find out on an invoice. Input vs output token pricing covers which side of the bill to model carefully; for a reasoning model it is nearly always output.

Even at list price, 2.5 is cheaper than Mercury 2 on input and identical on output, so there is no cost argument for staying on the older model.

Where 260K context changes the job

Doubling the window matters most for the use cases Inception now leads with: search agents and RAG pipelines, and coding subagents doing context compaction, routing and tool search. Those jobs read a lot and write a little, so a larger window lets one fast call summarise or filter more material before a slower model sees it.

Inception publishes customer reports to that effect. It says Augment Code cut compaction latency from about 150 seconds to 27 and cost by 90% while maintaining quality, and that OpenCall saw a median model response close to 170 milliseconds. These are vendor-published case studies, useful as a signal of the intended job rather than as numbers to plan on.

A larger advertised window is not the same as reliable recall across it, especially in a new architecture. Context length vs effective context explains how to test the part you will actually use.

The quality question

Inception compares Mercury 2.5 with cost-optimised frontier models, naming GPT-5.6 Luna at low effort, Gemini 3.5 Flash-Lite and Claude Haiku 4.5, without publishing head-to-head numbers. That is the right peer group: this is a fast-tier model, not a replacement for a large one on hard reasoning.

Independent evaluation of a model released this recently is thin, so do not treat any single figure, vendor or third-party, as settled. The test that matters is whether 2.5 is good enough for the specific latency-bound calls you would give it.

Should you move off Mercury 2

For most teams, yes, after a test. Inception describes the new model as its largest, has twice the context, claims better quality and costs no more at list price. The only reason to wait is an existing evaluation suite tuned to Mercury 2 that you have not yet re-run.

1. Pin both model IDs so neither changes under you mid-test.
2. Run your existing evaluation set against both at the same reasoning setting.
3. Record accuracy, output tokens and wall-clock time per task, not just tokens per second.
4. Check JSON validity and tool-call correctness separately, since parallel tool calls are new.
5. Price the result at list rates, not the launch discount.

If 2.5 matches or beats Mercury 2 on your set, switch. If you are deciding whether a diffusion model belongs in your stack at all, put it in front of a slower model as a first-pass router or summariser and escalate on failure. Model routing and fallbacks covers how to structure that cascade.