Mercury 2.5 Preview is Inception’s reasoning diffusion language model for developers. Unlike an autoregressive LLM that emits tokens strictly left to right, a diffusion language model refines multiple token positions in parallel. The design targets lower latency without giving up reasoning, tool use, or structured output.

The word Preview matters. Mercury 2.5 is available for evaluation through Inception’s OpenAI-compatible API and OpenRouter, but it should not be treated as a frozen production target until Inception publishes stable-release commitments.

Specifications and current pricing

Item	Direct Inception	OpenRouter
Model	Mercury 2.5 Preview	inception/mercury-2.5-preview
Context	260K tokens	260K tokens
Input	$0.20/M	$0.04/M promotional
Cached input	$0.02/M	$0.004/M promotional
Output	$0.75/M	$0.15/M promotional
Status	Preview / early access	Preview provider listing

OpenRouter’s launch rates are an 80% promotional discount. They are not Inception’s direct list price and may change independently. Cost models should store both provider and effective date rather than presenting $0.04/$0.15 as Mercury’s universal price.

What is a diffusion LLM?

Mercury generates by iteratively denoising a candidate response. That lets the runtime work on multiple output positions in parallel. The important developer question is not whether diffusion sounds novel; it is whether a workload gets acceptable quality, latency, determinism, and tool reliability.

Inception describes Mercury 2.5 as its most capable reasoning dLLM and publishes comparative results. Those are vendor-reported benchmarks, not independently reproduced proof that it wins every workload.

API access

Inception exposes an OpenAI-compatible chat-completions endpoint:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.inceptionlabs.ai/v1",
    api_key="YOUR_INCEPTION_API_KEY",
)

response = client.chat.completions.create(
    model="mercury-2.5-preview",
    messages=[{"role": "user", "content": "Return a JSON deployment checklist."}],
)
print(response.choices[0].message.content)

Confirm the current direct model identifier in Inception’s account documentation before shipping; preview aliases can change. If you use OpenRouter, the routed identifier is inception/mercury-2.5-preview. Our OpenRouter guide explains provider routing, while AI gateway architecture covers fallback and spend controls.

Supported developer workflows

First-party materials document reasoning, tool use, structured output, and OpenAI-compatible integration. That makes Mercury relevant to:

• latency-sensitive assistants;
• agent loops that make several model calls;
• structured extraction and JSON workflows;
• coding and analysis tasks where responsiveness matters;
• multi-model gateways that can evaluate a preview safely.

Do not infer image input or a stable multimodal API from the general model announcement. The currently documented developer path is a text model.

Preview deployment checklist

1. Pin the exact provider and model ID. Direct Inception and OpenRouter are separate billing and routing paths.
2. Record list and promotional prices separately. Do not budget against an undated discount.
3. Validate structured output. Use schemas and safe retries rather than trusting well-formed JSON.
4. Measure end-to-end latency. Network, tools, and retries can outweigh raw generation speed.
5. Keep a fallback. A preview can change availability or behavior.
6. Run regression evaluations. Compare quality on your own tasks before moving traffic.

The AI Testing & Evaluation hub provides the evaluation framework, and our rate-limiting guide covers quotas and cost control.

Should you use Mercury 2.5 Preview?

Use it for a controlled evaluation when latency and low provider pricing matter. Keep it behind a gateway, capture traces, validate tools and structured outputs, and retain a stable fallback. Wait for a stable release before making it the only model behind a critical production workflow.

We are not publishing a Mercury comparison page yet. The preview already has a durable owner here, but a head-to-head article would be premature without stable behavior and independently useful workload evidence.