Mercury 3 is Inception’s new diffusion language model, released October 19 with a one-million-token context window. Its launch API rates are $0.10 per million input tokens and $0.35 per million output tokens. The reported 1,068-token-per-second speed is a vendor measurement; application latency also depends on reasoning, input processing and tool calls.
The immediate engineering question is how to connect that speed to a useful response. A fast output phase can coexist with a long wait before an answer starts. Mercury also offers two streaming modes with different client behavior. Treating them as interchangeable can leave an application displaying repeated drafts.
Separate the launch price from the regular price
The October 19 announcement describes a 50% launch discount. Its regular input and output rates are $0.20 and $0.70 per million tokens. The announcement does not give an expiration date for the promotion, so a production budget should retain both rates.
For an illustrative request with 100,000 uncached input tokens and 10,000 billed output tokens, the launch-rate calculation is $0.0135: $0.010 for input plus $0.0035 for output. The same token counts at regular rates cost $0.027. These are arithmetic examples, excluding retries and any additional services; they are not measured task costs.
The model catalog lists discounted cache reads at $0.01 per million tokens, compared with a regular $0.02. Cache discounts matter only for input actually reported as cached. Repeating a similar prompt is insufficient evidence that a request received that rate.
Set reasoning effort explicitly
Inception’s reasoning documentation gives Mercury 3 four settings: instant, low, medium and high. The default is low. Mercury 2 and 2.5 default to medium, which makes an unchanged request a potentially misleading migration comparison.
A useful evaluation therefore names the setting alongside every timing. Start with a small task collection representing the application: a short answer, a schema-constrained extraction and a tool call that requires reading the returned result. Compare the same prompts and output constraints at each effort. Save failures as carefully as successful timings.
This separates three questions: how long the user waits, how often the answer is acceptable, and what the accepted answer costs. A faster setting that causes more retries can increase both total delay and spending. Conversely, a high-effort setting that barely improves a simple extraction may consume time without a corresponding benefit. Those are workload questions that a throughput headline cannot settle.
A minimal API request
The quickstart uses an API key from the Inception Platform. With INCEPTION_API_KEY already set, this request makes the reasoning choice visible:
curl https://api.inceptionlabs.ai/v1/chat/completions \
-H "Authorization: Bearer $INCEPTION_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "mercury-3",
"messages": [{"role": "user", "content": "Explain database connection pooling in three sentences."}],
"reasoning_effort": "low",
"max_completion_tokens": 1000
}'The documented endpoint is compatible with the OpenAI chat-completions interface. That compatibility is an integration starting point; it does not establish identical defaults, support for every client option, or equal behavior on an application’s tool schemas.
The catalog identifies Mercury 3 as text-only, with tool calling and structured outputs, and a maximum output of 131,072 tokens. The million-token context is an input-capacity specification, not a guarantee that every long-document task retains its short-context accuracy. Image understanding should not be inferred from the separate Mercury Decide product.
Diffusion streaming replaces the draft
Inception’s streaming documentation distinguishes ordinary streaming from diffusing: true. Ordinary streaming returns generated blocks. Diffusion mode exposes intermediate denoising steps, with each content chunk representing the full current text.
For a conventional append-only renderer, the distinction matters. Appending every diffusion chunk would concatenate successive versions of the answer. In diffusion mode, replace the displayed draft with the new full text. Treat intermediate text as provisional rather than immediately triggering an irreversible downstream action from it.
That last recommendation follows from the interface semantics: revisable text can change. For example, a client extracting an action from an early draft should wait for completion before using the final answer to populate a form or issue a request. This is a client-design consequence, not evidence that a particular Mercury response has failed.
Measure the delay your users experience
The launch speed is useful evidence of Inception’s serving result, but it does not specify your network, concurrency or prompt distribution. A practical measurement record should include these separate observations:
| Measure | What it answers |
|---|---|
| Time to first usable answer text | When can the user start reading something useful? |
| Time to accepted task completion | How long do reasoning, tools and repairs take together? |
| Billed cost per accepted result | Does faster generation produce an economical workflow? |
Report medians and slow-tail timings separately, with effort level and token counts attached. That makes a migration decision reviewable. Mercury 3’s price and output rate make it a reasonable evaluation candidate for latency-sensitive text applications; adoption should follow the result on the actual task, rather than an assumed translation from tokens per second to completed work.
