Inception introduces Mercury 3, a diffusion LLM reported to generate 1,068 tokens per second

Mercury 3’s launch and headline specifications

Inception Labs has introduced Mercury 3, the latest model in its family of diffusion-based language models, or dLLMs. The headline figure is a reported inference speed of 1,068 tokens per second. That is the company’s claim, not a universal measure of how fast every user or application will see text arrive: actual throughput depends on hardware, serving setup, output length, and how speed is measured.

Inception also lists a context window of one million tokens and says Mercury 3’s quality is comparable to GPT-6 Luna and Claude Haiku 5.5, while generating four to eight times faster. The company’s benchmark summary says Mercury 3 leads or ties on eight of twelve tests. Those are meaningful claims, but they should be read as vendor-reported results until the model’s exact test setup, full results, and independent replications are available. A large context limit is likewise a specification, not proof that a model can reliably use every token in a million-token prompt.

How diffusion generation differs from autoregressive text generation

Most widely used language models generate text autoregressively: they predict a token, add it to the output, then use the growing sequence to predict the next token. This creates a sequential dependency. Even when the underlying hardware can perform many operations in parallel, the next generation step generally has to wait for the previous token to be produced.

A diffusion language model takes a different route. Rather than committing to the final text strictly from left to right, it starts with an incomplete or noisy representation of the output and repeatedly refines parts of the sequence. Multiple positions can be updated during a refinement step, so generation is not constrained in the same way by the number of output tokens. The approach is conceptually related to diffusion methods used in image generation, but the text model and its training and inference procedures are not simply image generation applied to words.

Parallel refinement can reduce the time to produce an answer, but it does not make quality automatic. The number and design of refinement steps, the model’s training, the serving implementation, and the task all matter. A speed figure alone does not establish that a model reasons better, is more coherent, or uses long prompts more reliably than an autoregressive alternative. Nor does it establish a particular complexity bound that applies to every input and deployment.

What the benchmark comparison can establish

Inception compares Mercury 3 with GPT-6 Luna and Claude Haiku 5.5 and reports that it is competitive in quality while running faster. Its summary says Mercury 3 leads on eight of twelve benchmarks. Without the benchmark names, task definitions, model versions, prompting details, scoring methods, and hardware conditions, however, that summary is not enough to judge how meaningful the comparison is or whether the results generalize to a developer’s workload.

There is an important distinction between evidence for the Mercury model family and evidence for this specific release. Inception’s earlier Mercury Coder research describes diffusion-based language modeling and reports results for earlier models. That work can help explain the technical approach, but it does not independently validate Mercury 3’s one-million-token context, its 1,068-token-per-second figure, or the stated comparison with the named reference models. Results for one version should not be transferred to another without evidence that the model, evaluation, and serving conditions are comparable.

The available announcement details also do not establish that the twelve tests were run by an independent evaluator. The reported eight-of-twelve result should therefore be treated as a claim about Inception’s evaluation, not as a settled general ranking. A stronger comparison would disclose the test suite and methodology and allow third parties to rerun it on the same model configurations.

Reliability, long contexts, and the limits of the evidence

A one-million-token context window indicates a stated input capacity; it does not show that Mercury 3 can retrieve details accurately from anywhere in a prompt that long or maintain consistent reasoning throughout it. Long-context reliability needs its own evaluation, such as tests that vary where relevant information appears, how much of the context is distracting, and whether the model can combine evidence from distant sections.

The evidence provided for this article does not include an independent Mercury 3 study demonstrating stable coherence across the full one-million-token range. Nor does it provide a complete technical paper for Mercury 3 with enough detail to audit its training data, alignment methods, or the exact procedures behind the headline benchmarks. Earlier technical work on Mercury is useful background, but it should not be presented as a peer-reviewed or independent validation of the new model unless that status is documented.

The same caution applies to the speed comparison. A high token-per-second rate may describe output throughput under particular conditions; it is not necessarily the time from a user’s request to a complete, useful answer. End-to-end latency also includes prompt processing, queueing, tool calls, network delays, and any additional steps in an agent workflow. The available information does not provide a verified cost-per-token comparison for Mercury 3 against the named reference models, so a claim that it is cheaper per task would be premature.

What faster inference could mean for AI agents

An agent often makes several model calls in sequence: it may interpret a request, select a tool, inspect the tool’s result, and then decide what to do next. In that kind of workflow, reducing the generation time of each call could make the overall interaction feel more responsive. It may also give developers more room to add checks or intermediate steps without making the user wait as long.

That benefit depends on the whole system. A model can generate quickly while an agent remains slow because a tool is delayed, a request sits in a queue, or the application repeats work. Similarly, a fast model does not make a voice assistant feel instantaneous if speech recognition, speech synthesis, or network latency dominates. The useful measure for an application is the time to complete a correct task, not just the model’s reported token rate.

Mercury 3’s reported speed may make it worth evaluating for latency-sensitive work such as extraction, summarization, tool routing, or interactive assistance. For tasks where mistakes are costly or reasoning is difficult, teams should compare it against their current model using their own prompts and success criteria. A practical evaluation should measure accuracy, failure rates, full-response latency, and total cost for completed tasks. The supplied evidence does not establish Mercury 3’s inference price relative to GPT-6 Luna or Claude Haiku 5.5, so cost should be checked against current pricing and actual usage rather than inferred from speed.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.