Inception's Mercury 3 Hits 1,068 Tokens per Second, Beating GPT-6 Luna

Inception has released Mercury 3, a language model that iteratively denoises a block of token positions and updates many positions in parallel. Inception reports output throughput of 1,068 tokens per second on NVIDIA GPUs, roughly four to eight times the speed of the speed-tier models in its comparisons.

The company says Mercury 3 matches or exceeds GPT-6 Luna and Claude Haiku 5.5 across its benchmark suite. Those performance and quality figures come from Inception’s launch materials and still require independent reproduction, but they present a consequential engineering proposition: diffusion decoding may reduce generation latency without surrendering the quality expected from smaller production models.

Parallel decoding changes the latency equation

Autoregressive models such as GPT and Claude generate tokens sequentially, with each new token conditioned on the preceding sequence. That dependency limits how much of a response can be computed in parallel and causes generation time to rise with output length.

A diffusion language model begins with a noisy or masked representation of the target sequence, then refines token positions over several passes. Parallel updates can produce substantially higher throughput, although end-to-end latency still depends on output length, denoising steps, hardware, batching, prompt processing, and the way completed text is returned to the client.

Inception says Mercury 3 has more than 40 times as many parameters as Mercury 1 Mini and records a threefold increase on its aggregate benchmark measure. The cited material provides no absolute parameter count, which limits direct comparisons of model size and inference cost. The result nevertheless extends Inception’s argument that diffusion language models improve as training scale increases.

The numbers developers should inspect

Inception targets the speed tier occupied by models such as Claude Haiku, Gemini Flash, and GPT Luna. Workloads requiring top-end mathematical reasoning, extended planning, or repository-wide code changes remain better candidates for separate evaluation against larger reasoning models.

Agent loops expose the latency tax

Agent systems amplify generation latency because each observation, decision, tool call, and follow-up can require another model request. A modest delay per request can accumulate into several seconds across a single task, making throughput and tail latency central deployment metrics.

Inception reports testing Mercury 3 in a production web-agent harness on 50 live Mind2Web navigation tasks. The model completed 50 percent, or 25 tasks, and reportedly exceeded GPT-6.1-Sol while using the same token volume and number of agent steps. A 50-task vendor-run sample offers directional evidence; a stronger comparison would include the baseline completion rate, prompts, harness configuration, failure categories, and confidence intervals.

Customer results in the launch materials also focus on interactive latency. Smart-glasses developer Octen AI reports a median generation time of 0.9 seconds and a median end-to-end response time of 2.2 seconds. Education platform RevisionDojo says Mercury 3 returns hints and graded answers in roughly one second. Both reports should be treated as customer-provided measurements until their test conditions are published.

Workloads that fit the design

• Browser and web agents: Faster generation can reduce delays at every planning and navigation step.
• Voice assistants: Low end-to-end response latency helps maintain conversational turn-taking.
• Interactive tutoring: Rapid feedback supports hints, grading, and short iterative exchanges.
• Search and synthesis: High throughput can accelerate responses assembled from many retrieved documents.
• Customer support: Lower latency can benefit high-volume workflows after domain accuracy, safety, and compliance testing.
• Classification: Inception is targeting this workload with a separate sibling model called Mercury Decide.

The evidence has clear boundaries

• Vendor benchmarks: Inception produced the reported quality, throughput, and agent results. Independent replications have yet to establish comparable numbers.
• Throughput versus latency: Tokens per second does not reveal time to first usable text, p95 response time, prompt-processing latency, or performance under concurrent load.
• Reasoning ceiling: The comparisons focus on speed-tier models, leaving performance against larger reasoning systems unresolved.
• Long-context quality: A 1-million-token limit describes capacity. Retrieval accuracy and instruction retention across that window require separate tests.
• Architecture access: Inception has released neither open weights nor a detailed architecture paper, preventing inspection of the model and training process.
• API behavior: OpenAI-compatible request syntax does not guarantee identical streaming, tool calling, structured output, token accounting, or error semantics.

Trying Mercury 3 takes one endpoint change

Mercury 3 is available through Inception’s API platform, OpenRouter, Baseten, and Vercel. Developers can inspect responses in the chat playground or review the API docs.

An existing OpenAI Python client can call the model by changing the base URL, API key, and model identifier:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.inceptionlabs.ai/v1",
    api_key=os.environ["INCEPTION_API_KEY"],
)

response = client.chat.completions.create(
    model="mercury-3",
    messages=[
        {
            "role": "user",
            "content": "Draft a concise reply to this customer email."
        }
    ],
)

print(response.choices[0].message.content)

A production bake-off should measure complete application behavior under realistic traffic and prompt distributions:

1. Score task completion and response quality with representative inputs.
2. Record median and p95 end-to-end latency, including prompt processing and network time.
3. Test concurrency, rate limits, retries, and provider-specific errors.
4. Verify streaming or chunk delivery before using the model in voice and chat interfaces.
5. Check tool calls, JSON schemas, stop conditions, and token accounting.
6. Measure retrieval accuracy throughout the advertised context window.
7. Compare total workflow cost, including failed runs and repeated agent steps.

Independent tests will decide the architecture case

Mercury 3 gives developers a production API for testing diffusion decoding against established autoregressive models. A favorable result requires comparable task success, lower tail latency, and lower total cost under realistic concurrency. Until independent evaluations publish those measurements, Inception’s release supports a credible engineering hypothesis whose practical value will vary by workload.