Mercury 3 arrives: launch pricing, API access and the limits of a speed headline

What shipped on October 19

Inception introduced Mercury 3 on October 19, 2026. The launch announcement describes a diffusion-based language model and reports generation speed of 1,068 tokens per second on NVIDIA GPUs. That figure is Inception’s reported result, not a Promptwire test or a guarantee for every request.

The announcement lists availability through the Inception API Platform, OpenRouter, Baseten and Vercel. Its target workloads include support, interactive education, search and browser agents.

Public record: Inception — October 19 Mercury 3 launch announcement

Diffusion changes how the text is produced

Vercel’s October 19 integration notice describes Mercury 3 as generating text through parallel refinement. It confirms AI Gateway availability and the model identifier inception/mercury-3.

For a product team, the architecture is a reason to investigate performance, rather than an acceptance test by itself. A support reply still needs the correct policy, a search answer needs the right evidence, and an agent must choose the correct next action. Faster text matters when those requirements survive the change.

Public record: Vercel — October 19 Mercury 3 AI Gateway release

Current API rates separate the offer from the list price

Inception’s model documentation, checked October 26, lists a 50% launch discount for Mercury 3. The table below preserves both the promotional and regular rates, in US dollars per million tokens.

Promotional pricing may change. Check the active provider rate before budgeting.

Public record: Inception Platform — current models, pricing and API settings

Check capabilities and settings before comparing runs

The same documentation lists a one-million-token context window, up to 131,072 output tokens, tool calling and structured outputs for the text model. It supports instant, low, medium and high reasoning effort, with temperature adjustable from 0.5 to 1.0. Its direct API example uses mercury-3 at v1/chat/completions.

Choose a reasoning setting deliberately and keep it recorded in your comparison. Otherwise a faster result could reflect a different effort budget as well as a different model. Also check the returned structure and tool arguments: a response that arrives quickly but fails your parser creates another round of work.

Public record: Inception Platform — current models, pricing and API settings

The waiting-time calculation that matters

Consider a hypothetical workflow that spends two seconds on model generation and six seconds retrieving records, waiting for tools and preparing the interface. Even if generation became four times faster, the full task would fall from eight seconds to six and a half. That is an 18.75% reduction in elapsed time, not a fourfold improvement in the whole service.

This illustration is arithmetic, not a Mercury measurement. It shows why a throughput headline needs a task-level denominator. A workload dominated by long generation could benefit differently from one dominated by external tools.

Before changing providers, split a representative request into retrieval, model work, tool execution and final delivery. Measure when the user first gets something useful and when the job is actually complete. A stream of partial output can look responsive while a customer still waits for the answer they need.

A practical trial: turn a return policy into a valid decision

Use a fictional retailer with a short return policy and a small set of orders. Include an eligible return, an expired window, a missing purchase date and an exception that needs staff review. Write the expected decision and supporting policy passage for each case.

Have your current model and Mercury 3 produce the same structured decision, explanation and proposed next action. Keep tools, context and acceptance criteria fixed. Inspect whether each answer identifies the relevant rule, asks for missing information and avoids promising a refund outside the policy.

Count accepted outcomes, retries, total token charges and time to a finished decision. Run at the concurrency your application expects, rather than judging from a single quiet request. For budgeting, use both current promotional rates and regular rates so the trial remains useful after an offer changes.

Promptwire has not independently benchmarked Mercury 3. Our suggested decision rule is simple: adopt a faster model when it reduces the measured wait for correct, usable work. Keep the comparison grounded in the customer’s completed task.