Inception's Mercury 3 Hits 1,000 Tokens per Second With 1M Context
Inception's Mercury 3 is a diffusion-based language model that generates over 1,000 tokens per second while matching frontier speed-tier quality.
- Inception launched Mercury 3, its most capable diffusion-based LLM, at 1,068 tokens/second on NVIDIA GPUs.
- Context window jumps to 1M tokens, up from 260K in Mercury 2.5.
- More than 40x the parameters of Mercury 1, with speed maintained above 1,000 tok/sec.
- Claims to beat GPT-6 Luna and Claude Haiku 5.5 on 8 of 12 self-reported benchmarks.
- Launch pricing: $0.10/M input and $0.35/M output tokens (50% off list).
- Available via Inception API, docs here, OpenRouter, Baseten, and Vercel.
Inception has released Mercury 3, a diffusion-based large language model with a reported one-million-token context window and generation throughput above 1,000 tokens per second on NVIDIA GPUs. The model is available through Inception’s API and several hosted platforms. Inception says it is more than 40 times larger than Mercury 1 while retaining the product line’s high decoding speed.
Developers may see the largest gains in applications that make many model calls per task. In a launch demo, Mercury 3 running through the opencode coding harness used parallel subagents to complete a task roughly an order of magnitude faster and cheaper than Claude Code running Sonnet 5.5. The company has not disclosed Mercury 3’s parameter count or exact GPU configuration, and independent benchmark validation remains limited.
Diffusion moves more tokens at once
Autoregressive language models generate text sequentially, committing one token after another from left to right. Diffusion language models refine multiple token positions across a series of passes, creating more opportunities for parallel computation. The number of refinement steps, serving hardware and workload still determine the latency users experience.
Mercury 3 extends a series of increasingly capable diffusion models. Mercury 2 added reasoning, while Mercury 2.5 introduced tunable reasoning and expanded the context window to 260,000 tokens. Mercury 3 raises that limit to one million tokens and, according to Inception, delivers the line’s largest capability increase so far.
The launch claims, side by side
| Metric | Mercury 3 claim | Relevant context |
|---|---|---|
| Generation speed | 1,068 tokens per second | Measured on NVIDIA GPUs; the exact GPU configuration is undisclosed |
| Context window | 1 million tokens | Up from 260,000 tokens in Mercury 2.5 |
| Model size | More than 40 times larger than Mercury 1 | The parameter count is undisclosed |
| Comparative speed | Four to eight times faster than selected competing models | Results depend on hardware, output length and serving configuration |
| Benchmark quality | Higher scores than GPT-6 Luna and Claude Haiku 5.5 on several tests | Mercury 3 leads 8 of 12 tests in Inception’s table |
| Launch pricing | $0.10 per million input tokens and $0.35 per million output tokens | Half the listed standard prices of $0.20 and $0.70 |
Benchmark gaps narrow the conclusion
Artificial Analysis says the announcement’s AA-Omniscience and GDPval-AA v2 scores do not follow its methodology, which prevents direct comparison with scores on its official leaderboard. Inception’s results therefore establish company-reported performance rather than an independently verified ranking.
The coding demonstration measures an entire agent system, including the model, harness, subagent strategy, tool calls and concurrency. Such a comparison can reflect real application performance, although it does not isolate model latency or intelligence. Reproducing the result requires the same task, output criteria, parallelism limits and cost accounting.
Agents expose the speed advantage
Agent workflows often fan out across several model calls and then wait for every branch to finish. Latency accumulates at each step, especially when coding agents inspect files, run tools, delegate subtasks and revise their output. Mercury 3’s throughput could reduce that delay when a harness can execute independent work concurrently.
Inception demonstrated that pattern with opencode, an open-source coding-agent harness that can coordinate tools and subagents. Similar performance characteristics may suit voice systems, search pipelines and rerankers, where each interaction can trigger several time-sensitive inferences.
Tokens per second capture only part of application latency. Time to first token affects interactive systems, while tail latency determines how quickly a group of parallel agents can rejoin. Tool execution time, rate limits, retries and output quality also influence total task duration and cost.
API access comes with limited visibility
Mercury 3 is available through Inception’s API platform, OpenRouter, Baseten and Vercel. Integration guidance is available in the API docs.
- Deployment: Access is API-only, with no open weights or quantized builds announced.
- Hardware: Inception serves the model on NVIDIA GPUs but has not identified the exact configuration.
- Model size: The undisclosed parameter count prevents direct efficiency comparisons with open models.
- Validation: Independent benchmark and production-load results remain pending.
- Long context: A one-million-token limit does not establish retrieval accuracy across the full window, which requires workload-specific testing.
A practical evaluation plan
Teams evaluating Mercury 3 can run it against their current model with identical prompts, tools, concurrency settings and success criteria. A representative test should record:
- Task completion rate and output quality
- Time to first token, total latency and p95 latency
- Throughput under expected concurrency
- Total cost, including retries and failed tool calls
- Long-context retrieval accuracy at several document depths
- Rate limits, data-handling terms, regional availability and observability support
Mercury 3 is a plausible fit for coding agents, voice loops, search systems and other workloads that issue many model calls per interaction. The available evidence does not establish it as a general replacement for frontier reasoning models. Its practical value will depend on whether its speed survives representative prompts, production concurrency and the quality thresholds of the application using it.
Comments
