Mercury 2.5 writes in blocks at over one thousand tokens per second

Inception launches Mercury 2.5, a diffusion-based language model announced at 1,107 tokens per second, with a 260,000-token context window and parallel tool calling.

At 1,107 tokens per second, a thousand-token response could theoretically be produced in less than a second. That calculation also exposes the problem with the figure: it measures generation throughput, not necessarily the total time between sending a question and seeing the answer.

Mercury 2.5 is Inception’s new production model. It retains Mercury 2’s diffusion-based generation while improving across several evaluations of reasoning, tool use, and instruction following. Its context window has increased from 128,000 to 260,000 tokens.

Most large language models generate responses from left to right. They select one token, add it to the context, and then calculate the next. This sequential dependency limits how many pieces of text can be produced at the same time.

A diffusion language model follows a different process. It begins with a response area that is still masked or incomplete, then revises multiple positions over successive passes. Some words become more precise while others remain provisional. The system can therefore work on several tokens simultaneously.

The method resembles diffusion-based image generation, but the material being processed is discrete rather than continuous. The model must determine the content and position of text units, along with their grammatical relationships, without losing overall coherence.

Inception still uses a Transformer architecture. The main difference lies in how the text is learned and generated. The first Mercury research report, published in 2025, already described models trained to predict several tokens in parallel. It covered Mercury Coder Mini and Small, not Mercury 2.5.

The company describes the new release as the most capable diffusion language model available and the largest ever trained in this category. It has not disclosed the model’s parameter count, data composition, or training compute. The second claim therefore cannot be verified from the published information.

Mercury 2.5 remains a closed model. Its weights cannot be downloaded, and no repository provides access to its training process. It is available through Inception’s API and intermediaries such as Baseten and OpenRouter.

Speed is its main selling point. Inception’s chart places Mercury 2.5 at 1,107 tokens per second, compared with 321 for Gemini 3.5 Flash-Lite, 127 for Claude Haiku 4.5, and 99 for GPT-5.6 Luna with low reasoning effort.

The launch page refers to widely available NVIDIA GPUs but does not identify the exact hardware, number of accelerators, response length, reasoning setting, or batch size. Each of these parameters can substantially affect throughput. The figure of 1,107 tokens per second should be treated as a measurement achieved under Inception’s test conditions, not a guaranteed speed for every request.

The first figures reported by OpenRouter provide a different point of reference. At the time of review, the platform showed a median throughput of 346 tokens per second and median latency of 1.18 seconds. These results were recorded shortly after the model became available and may still change, but they demonstrate the difference between a provider’s published peak and a shared service operating under real-world conditions.

Throughput should not be confused with time to first token. A service may generate the rest of a response very quickly after spending time on the initial analysis. For a voice agent, that first delay can matter more than the speed reached once the text begins to appear.

Mercury’s documentation offers two display modes. Conventional streaming sends blocks of text that have already been stabilized. A `diffusing` mode shows the intermediate states by repeatedly replacing the full response until it reaches its final version. This second option is mainly intended to visualize the revision process.

Users can set reasoning effort to one of four levels: `instant`, `low`, `medium`, or `high`. `Medium` is used by default. The first setting targets voice agents and highly latency-sensitive automation, while `high` allocates more computation to complex tasks.

This creates a direct tradeoff. More reasoning can improve a difficult answer, but it also increases latency and the number of billed tokens. The API FAQ states that reasoning tokens are included in the output count and charged at the same rate.

Inception claims a 40% increase in “intelligence” over Mercury 2. This percentage does not correspond to a universal metric. It summarizes a selection of evaluations chosen by the company, with gains varying considerably between tasks.

The published chart gives Mercury 2.5 a score of 96% on Tau3Bench Telecom, up from 65% for Mercury 2. Its result rises from 41% to 68% on AA-LCR, from 25% to 37% on TerminalBench, and from 15% to 34% on DSQA with ten tool calls.

The differences are smaller elsewhere. GPQA Diamond increases from 74% to 79%, IFBench from 69% to 77%, and SciCode from 37% to 38%. Omniscience Accuracy even falls from 24% to 22%, while a separate non-hallucination metric rises from 18% to 33%.

The 40% figure therefore conceals uneven results. Mercury 2.5 improves substantially on some agentic tasks, changes little on scientific coding, and loses two points on one accuracy measurement. The launch chart does not disclose the complete prompts, reasoning budgets, or number of attempts used.

Inception also compares the model’s overall quality with GPT-5.6 Luna in Low mode, Gemini 3.5 Flash-Lite, and Claude Haiku 4.5. These are cost- and speed-optimized models rather than the most capable versions in their respective families. The publication does not provide a complete table comparing every system on each test under identical conditions.

Mercury 2.5 primarily targets tasks involving many short calls. A search agent may plan a query, rewrite several searches, rank the results, extract facts, and prepare a summary. Even a short delay becomes noticeable when repeated dozens of times.

The same logic applies to coding assistants. A primary model may delegate repository