Mercury 3: Inception's Diffusion LLM at 1,000 Tokens per Second, Price, API Code, How Diffusion LLMs Work, and Can You Run It Locally

Mercury 3 is Inception's newest diffusion LLM, released October 19, 2026: a text model that writes its answer by refining many tokens in parallel instead of one word at a time, which is why it runs at about 1,000 tokens per second (1,068 measured on NVIDIA GPUs). It has a 1 million-token context (up from 260K in Mercury 2.5), and Inception says it matches or beats GPT-6 Luna and Anthropic's Haiku 5.5 on quality while running 4-8x faster. Price: list $0.20 per million input tokens and $0.70 per million output tokens, with a 50% launch discount to $0.10 / $0.35, cached input 90% off, and 100 million free tokens for new API accounts. You call it through Inception's OpenAI-compatible API (https://api.inceptionlabs.ai/v1, model mercury-3), OpenRouter (inception/mercury-3), Baseten or Vercel; it supports tools, structured output, streaming and a reasoning-effort setting. It is not open-weight, so you cannot run it locally, and it is not on Amazon Bedrock yet (earlier Mercury models reached Bedrock Marketplace and SageMaker JumpStart). Below: how diffusion LLMs work, specs, pricing with worked costs, Python and curl code, where it fits against autoregressive models, and the errors on a first call.

The shop's support chat answered in two to four seconds, which felt slow on a phone. Jake wanted a faster model; Ethan wanted it cheaper too. A model that streams a full answer in under a second, at a third of a dollar per million output tokens, was worth an afternoon of testing, provided it was good enough at the actual job.

Comparing fast, cheap models? The cards below cover MiniMax, DeepSeek, GPT-6.1 Sol and Kimi K3, plus local runners.

What is Mercury 3?

Mercury 3 is the fourth release of Inception's Mercury family since the first commercial diffusion LLM, Mercury 1, in June 2025. Inception says it is more than 40 times larger than Mercury 1 in total parameters and about three times as capable on standard benchmarks, while keeping the family's defining trait: speed. It is a text model (no images or audio in), available as an API, aimed at work where waiting is the problem: chat, voice assistants, search answers, autocomplete and agents that make many model calls in a row.

Inception itself is a startup founded by university researchers behind much of the early academic work on diffusion models, including Stanford's Stefano Ermon, which is why its whole product line is built on diffusion rather than the left-to-right approach almost every other lab uses.

Alongside it, Inception offers Mercury Voice, tuned for the fastest time to the first word in spoken conversations, and Mercury Decide, a model for high-volume classification and decision tasks.

Jake: "A thousand tokens a second? Our whole support answer is two hundred."

Ethan: "Which is the point. The answer is done before the phone finishes rendering the bubble."

How diffusion LLMs work (and why they are fast)

Most language models, from GPT to Llama, are autoregressive: they write one token, then use everything so far to predict the next, then the next. Each step waits for the one before, so a 500-token answer means 500 sequential steps, and speed is limited by how fast the hardware can do one step.

A diffusion LLM borrows the idea behind image generators such as Stable Diffusion. Instead of writing left to right, it starts with a rough or masked draft of a whole block of text and improves all positions at once over a small number of refinement passes, coarse to fine, until the text settles. In plain terms:

1. Start with a block of placeholder tokens the length of the expected answer (or a chunk of it).
2. Predict every position at once, keeping the confident words and leaving the uncertain ones open.
3. Refine the open positions in a few more passes, each seeing the whole draft, including words to the right.
4. Stop when the draft stops changing, then move on to the next block for long answers.

Why does that make it cheaper as well as faster? When an autoregressive model writes one token, the GPU has to read the model's weights from memory for very little arithmetic, so most of its compute sits idle waiting on memory bandwidth. A diffusion pass does the arithmetic for many positions at once with the same weight reads, so the GPU's compute is actually used. More tokens per GPU-second means a lower cost per token, which is how Mercury can be both the fastest and one of the cheapest models in its class.

Because each pass handles many tokens in parallel, a GPU does far more useful work per step, which is where the 4-8x speed advantage comes from. The trade-off used to be quality: early diffusion text models were fast but weaker. Mercury's claim, and the reason this release got attention, is that the gap has closed for the "small, fast model" class. On the "diffusion model vs LLM" question, then: a diffusion LLM is still a large language model; diffusion is just a different way of generating the text.

Diffusion LLM vs autoregressive LLM: the practical differences

People search for "diffusion model vs LLM" and "diffusion LLM vs transformer" as if they were rival species. They are not: most diffusion LLMs, Mercury included, still use a transformer network inside. What changes is how the network is trained and how it produces text. The differences that matter when you build with one:

The bidirectional view is the underrated part. Because every position sees the whole draft, a diffusion model can fix an earlier word after writing a later one, which suits structured output (JSON that must close properly), code edits in the middle of a file, and rewriting tasks. The weakness is the flip side of speed: on long, multi-step reasoning, where each step depends on the last, the left-to-right models still lead.

Jake: "So it's still a transformer, just not writing left to right?"

Ethan: "Right. Same engine, different way of driving it. That's where the speed comes from."

Mercury 3 specs at a glance

Inception did not publish per-benchmark scores at launch, so treat the quality claims as a reason to test, not a result. The one number to read carefully is the speed: 1,068 tokens per second is measured on Inception's own GPU servers, for output generation. Your experience adds network time and the time to read your prompt, so a long prompt sent from far away will feel slower than the headline, while short chat turns will feel close to instant.

Prompting tips that suit a fast model like this:

• Keep the system prompt focused: one clear role, the policies that matter, and the output format. Long, rambling instructions cost input tokens on every call and blur the answer.
• Say how long the answer should be ("two sentences", "under 80 words") and back it with max_completion_tokens; short answers are where the speed shows.
• Give one or two examples of a good answer for recurring question types; small models follow examples better than abstract rules.
• Ask for a fixed format when code will read the answer, and use a JSON schema rather than "please reply in JSON".
• Move the reference material into retrieval instead of the system prompt once it grows past a few pages, even with a 1M-token window.

Mercury 3 vs Mercury 2, Mercury 2.5 and Mercury Coder

If you already use an earlier Mercury model, here is how the family has moved:

Upgrading is mostly a model-name change: mercury-2 becomes mercury-3 on Inception's API, and inception/mercury-2 becomes inception/mercury-3 on OpenRouter. Three things to check when you switch:

1. Re-run your evaluation set: a bigger model can change tone and length even when quality improves, which matters for UI copy and voice.
2. Review your reasoning effort: Mercury 3 may reach the same quality at a lower effort setting, which is faster and cheaper.
3. Use the bigger context deliberately: a 1M window lets you send whole manuals or codebases, but every input token is billed, so caching and retrieval still matter.

Mercury Coder, the model that launched the company, was aimed at code completion and editing, where diffusion's ability to fill gaps in the middle of a file is a natural fit. Check Inception's model list for whether a separate coder model is still offered; for most coding agents, Mercury 3 with tools is now the simpler choice.

Mercury 3 pricing, with worked costs

• List price: $0.20 per million input tokens, $0.70 per million output tokens.
• Launch price (50% off): $0.10 input, $0.35 output.
• Cached input: 90% off the input price, for repeated prompt prefixes such as a long system prompt.
• Free tier: 100 million tokens for new Inception API accounts, with no payment details needed to start.

What that means for your bill, at launch prices:

• A support chatbot: 100,000 conversations a month, each about 1,500 input and 250 output tokens. Input 150M × $0.10 = $15; output 25M × $0.35 = $8.75. About $24 a month ($48 at list price).
• An agent making many calls: 1 million calls of 3,000 input and 400 output tokens. Input 3B × $0.10 = $300; output 400M × $0.35 = $140. $440, and much less if the shared system prompt is cached.
• A trial: the 100M free tokens cover tens of thousands of test conversations, enough to evaluate it on your real prompts at no cost.

How does that compare with the alternatives? The same support chatbot (150 million input and 25 million output tokens a month) priced on other fast models:

At launch prices Mercury 3 is the cheapest of these; at list price it costs more than GPT-6 Luna, so the case for it then rests on speed rather than price. Caching changes the picture for every model: with a long system prompt cached at 90% off, the input line shrinks dramatically, so compare with caching switched on before you decide.

Prompt caching matters most for agents and chat with long instructions; our prompt caching guide explains the idea in the Bedrock context, and it carries over.

How to use Mercury 3: Python, curl and OpenRouter

Because the API is OpenAI-compatible, the standard openai package works with a different base URL:

import os
from openai import OpenAI

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

reply = client.chat.completions.create(
    model="mercury-3",
    messages=[
        {"role": "system", "content": "You are a friendly support agent for an online shop. Keep answers short."},
        {"role": "user", "content": "Can I return a jacket I bought in a sale?"},
    ],
    max_completion_tokens=1024,
    reasoning_effort="low",            # more effort = slower but more careful
)
for choice in reply.choices:
    print(choice.message.content)

Streaming is the same stream=True you already use; at this speed, streaming mostly helps the first word appear sooner. With curl:

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 a diffusion LLM in two sentences."}]}'

Through OpenRouter, swap the base URL to https://openrouter.ai/api/v1, use your OpenRouter key, and set model="inception/mercury-3"; OpenRouter lists tools, response_format for structured output, and the reasoning settings for it. That is the easiest way to compare it side by side with other models in one script.

Steps to evaluate it properly before switching:

1. Collect 50-100 real prompts from your logs, with the answers you consider good.
2. Run them through your current model and Mercury 3 with the same system prompt.
3. Score the answers (a person, or a stronger model as judge) and record latency and token counts.
4. Try reasoning effort low and medium; pick the cheapest setting that passes.
5. Route a small share of live traffic to it for a week before moving the rest.

Jake: "It passed 46 of our 50 support questions. The current model passed 47, at four times the latency."

Ethan: "Then route the simple questions to Mercury and keep the old one for refunds and complaints."

Reasoning effort: low, medium or high?

Mercury 3 can think before it answers, and reasoning_effort sets how much. The trade is simple: more effort means more hidden reasoning tokens, which cost time and output tokens, in exchange for more careful answers on harder questions. A practical way to choose:

• Low: routine support answers, rewriting, classification, extraction and most voice replies. Start here.
• Medium: questions that combine several facts, policy decisions ("can this order be refunded?") and agent planning steps.
• High: the occasional hard problem where a wrong answer costs more than a second of waiting.

Run your evaluation set at each level and keep the lowest one that passes. In an app, you can also decide per request: send simple intents at low effort and escalate only when a first answer fails a check, such as missing a required field.

Building a voice assistant on Mercury 3

Voice is where a fast model is most noticeable, because people expect a reply within about a second of finishing a sentence. A voice assistant has three stages, and each adds delay:

1. Speech to text: a streaming recognizer turns the caller's words into text as they speak.
2. The language model: writes the reply; with Mercury 3, the first block of text arrives very quickly.
3. Text to speech: starts speaking as soon as the first sentence is ready, not after the whole reply.

The language model used to be the slowest stage; with a diffusion model it often becomes the fastest, which moves the bottleneck to speech recognition and the network. Practical tips: stream the reply into the speech engine sentence by sentence, keep the system prompt short and cached, set reasoning effort low for small talk, and host the speech stages close to your users. Inception's Mercury Voice model is tuned specifically for the time to the first spoken word, so compare it with Mercury 3 if voice is your main use.

Jake: "Our phone bot pauses for two seconds before every answer."

Ethan: "Time each stage first. If the model is half of it, Mercury fixes half the pause; the rest is speech and network."

Tool calling and JSON output with Mercury 3

Mercury 3 supports the standard tools parameter and structured output, so agent code written for OpenAI-style APIs carries over. A compact example that asks for an order lookup and then a JSON answer:

import json, os
from openai import OpenAI

client = OpenAI(api_key=os.environ["INCEPTION_API_KEY"], base_url="https://api.inceptionlabs.ai/v1")
tools = [{"type": "function", "function": {
    "name": "order_status",
    "description": "Current status and delivery date for an order number",
    "parameters": {"type": "object", "properties": {"order_id": {"type": "string"}}, "required": ["order_id"]},
}}]
messages = [{"role": "user", "content": "Where is order 10442?"}]
first = client.chat.completions.create(model="mercury-3", messages=messages, tools=tools)
msg = first.choices[0].message
if msg.tool_calls:
    messages.append(msg)
    for call in msg.tool_calls:
        args = json.loads(call.function.arguments)
        result = {"order_id": args["order_id"], "status": "shipped", "eta": "2026-10-23"}   # your real lookup here
        messages.append({"role": "tool", "tool_call_id": call.id, "content": json.JSONEncoder().encode(result)})
    final = client.chat.completions.create(model="mercury-3", messages=messages, tools=tools)
    print(final.choices[0].message.content)

The loop is the same one you would write for any OpenAI-style model: the first call returns tool_calls instead of text, your code runs each function, and a second call turns the results into the final answer. With a fast model the two round trips together still finish quicker than one call to a slow model, which is why agent builders care about raw speed. Keep the tool descriptions specific (what the tool returns and when to use it), because a vague description leads to missing or wrong calls whatever the model.

For structured output, pass response_format with a JSON schema (the same shape as OpenAI's) and parse the reply; diffusion's whole-draft view makes well-formed JSON a strength rather than a risk. Two habits help with any fast model in an agent: validate tool arguments before acting on them, and cap the number of tool rounds per request so a confused loop cannot run up calls.

Measure Mercury 3's speed yourself

"1,000 tokens per second" is a server-side number; what your users feel is time to first token plus network time. Measure both from where your app runs:

import os, time
from openai import OpenAI

client = OpenAI(api_key=os.environ["INCEPTION_API_KEY"], base_url="https://api.inceptionlabs.ai/v1")
start = time.perf_counter(); first = None; chunks = 0
stream = client.chat.completions.create(
    model="mercury-3", stream=True,
    messages=[{"role": "user", "content": "Write 300 words about caring for a leather jacket."}],
)
for part in stream:
    if part.choices and part.choices[0].delta.content:
        if first is None:
            first = time.perf_counter() - start
        chunks += 1
total = time.perf_counter() - start
print(f"time to first token: {first:.2f}s, total: {total:.2f}s, chunks: {chunks}")

Measure from the same place your users' requests come from. A laptop on office Wi-Fi and a server in a cloud Region can see very different network times, and for a model this fast, the network can be a large share of the total. Measure at the busy hour too, since shared APIs can be slower under load, and keep the prompt realistic: a test with a ten-word question says little about a production prompt with two pages of policy text.

Run it a few times from your server's Region, and the same script against your current model by changing the base URL and model name. The difference in total time is the number to put in front of whoever approves the switch. Expect the first chunk of a diffusion model to be larger than one word, since it arrives a block at a time.

Routing: send the easy questions to Mercury 3

Most teams that adopt a fast model do not switch everything; they route. A router looks at each request, decides how hard it is, and sends it to the cheapest model that can handle it. Mercury 3 is well suited to both sides of that: as the fast model that answers routine requests, and as the classifier that makes the routing decision in a few milliseconds.

A simple version for a support chat works like this. Define a handful of intents (delivery status, returns, sizing, payment problem, complaint, other). Ask Mercury 3, at low reasoning effort and with a JSON schema that only allows those intent names, which one a message belongs to. Send delivery, returns and sizing to Mercury 3 with the relevant policy text in the prompt; send complaints, payment problems and "other" to your stronger model or a person. Log every decision with the final outcome, and review a sample each week.

Three things make routing work in practice. Keep the intent list short, because a classifier with forty labels is slower and less accurate than one with six. Give each intent a one-line description in the prompt, the same way you would brief a new support agent. And measure the router on its own: a router that sends 5% of complaints to the fast model can cost more in unhappy customers than it saves in tokens. Inception's Mercury Decide model targets exactly this kind of high-volume classification, so compare it with Mercury 3 if routing is your main workload.

Running Mercury 3 reliably in production

A model that answers in under a second changes how you should handle failures, because a slow retry now costs more than the original call. A production setup should cover four things:

• Short timeouts: set the client timeout to a few seconds rather than the default minute, so a stuck request fails fast instead of holding the user.
• Retries with backoff for 429 and 5xx: one or two quick retries with a small random delay; more than that turns a brief rate limit into a pile-up.
• A fallback model: if Mercury fails twice, send the request to your previous model and log the event, so customers see a slower answer instead of an error.
• Monitoring: track latency percentiles, error rates and tokens per request; a sudden rise in output tokens usually means a prompt change made answers longer.

from openai import OpenAI, APIError, APITimeoutError, RateLimitError

fast = OpenAI(base_url="https://api.inceptionlabs.ai/v1", api_key=INCEPTION_KEY, timeout=5, max_retries=1)
backup = OpenAI(api_key=OPENAI_KEY, timeout=20)

def answer(messages):
    try:
        r = fast.chat.completions.create(model="mercury-3", messages=messages)
    except (APITimeoutError, RateLimitError, APIError):
        r = backup.chat.completions.create(model="gpt-6-luna", messages=messages)
    return r.choices[0].message.content

The SDK's max_retries handles the quick retry for you, so the code only needs the fallback. Keep both keys in a secrets store, never in the code itself.

Using Mercury 3 with LangChain and other frameworks

Anything that accepts an OpenAI-compatible endpoint works. In LangChain, point the OpenAI chat class at Inception:

import os
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="mercury-3", base_url="https://api.inceptionlabs.ai/v1",
                 api_key=os.environ["INCEPTION_API_KEY"], temperature=0.3)
print(llm.invoke("Give me three subject lines for a sale email.").content)

Two details trip people up with frameworks. First, the framework may send parameters that only OpenAI understands (some newer request fields), and an OpenAI-compatible API can reject them; if a call fails with a parameter error, remove the extras or pin the framework to plain chat completions. Second, frameworks often default to OpenAI's own model names in sub-steps such as summarizing memory or naming a chat, so set the model explicitly everywhere, or a background call quietly goes to a different provider and fails for lack of a key.

The same pattern works in LlamaIndex (its OpenAI-like LLM class), the Vercel AI SDK (an OpenAI-compatible provider with a custom base URL) and coding agents such as OpenCode, where you add Inception as a custom provider. Our LangChain guide covers chains and agents in more depth, with Bedrock as the example provider.

Mercury 3 vs other fast, cheap models

Mercury 3 competes in the "fast and inexpensive" tier rather than with frontier reasoning models. The main differences at a glance:

How it lines up in practice:

• Against small autoregressive models (GPT-6 Luna, Anthropic's Haiku 5.5): similar quality by Inception's claim, several times faster. Test on your tasks; quality gaps show up in edge cases.
• Against cheap Chinese models such as DeepSeek V4.1 Flash and MiniMax M3.1 Flash: comparable or lower token prices there, with open weights you can self-host; Mercury's edge is raw speed.
• Against frontier models (GPT-6.1 Sol and peers): those win on the hardest reasoning and long multi-step planning; Mercury 3 wins on latency and cost per call. Inception's browser-agent result (50% of 50 Mind2Web tasks, ahead of GPT-6.1 Sol) suggests it holds up on practical agent work, but one benchmark is one benchmark.

Where Mercury 3 fits, and where it does not

Good fits for your stack:

• Voice assistants and phone bots, where every 100 milliseconds of silence is noticeable.
• Customer support chat and in-app help, where most questions are routine.
• Agents that call the model dozens of times per task, where latency multiplies.
• Search answers written over retrieved results, and autocomplete or rewriting in editors.
• High-volume classification and extraction, where Mercury Decide is the related option.

Weaker fits: anything needing images or audio as input (it is text only), the hardest math and multi-step reasoning, regulated workloads that need a specific cloud's contracts and data residency, and anything that must run offline.

Before you move production traffic, run through a short checklist:

1. Is latency actually your problem? If users wait on a database or a slow web page, a faster model changes little.
2. Does it pass your own test set at the lowest reasoning effort you can accept?
3. Does the price still work at list price, after the launch discount ends?
4. Are your data rules met? Prompts leave your cloud account; check Inception's data retention terms against your policies.
5. Is there a fallback? Keep your previous model wired in so an outage or a bad answer pattern can be routed around in minutes.

Teams that answer yes to all five usually start with a router: Mercury 3 for the simple, high-volume intents, a stronger model for the rest. That captures most of the speed and savings with little risk.

Can you run Mercury 3 locally?

No. Mercury 3's weights are not published, so there is no GGUF file, Ollama tag or LM Studio download, and anything claiming to be one is not the real model. If you need a fast model on your own hardware, look at open-weight options instead: our Qwen3.8-Flash-Next guide covers a big mixture-of-experts model that runs on a desktop, and our local runner comparison helps you pick the tool. Enterprises that need isolation can ask Inception for dedicated capacity with configurable data retention.

Why no local version? Diffusion LLMs need their own inference software, not the llama.cpp-style runners most local tools use, and Inception's business is the hosted API. If your reason for wanting local is privacy rather than cost, ask Inception about dedicated deployments; if it is cost, remember that the 100 million free tokens and the low per-token price make the API cheaper than a GPU for most small projects. And if it is curiosity about how diffusion text generation behaves on your own machine, the open models below are the way in.

Open diffusion LLMs you can run yourself (DiffusionGemma, LLaDA, Dream)

If what draws you to Mercury is the diffusion approach itself, there are open-weight diffusion language models you can download and run:

• DiffusionGemma (Google DeepMind, June 2026): the most practical one. A mixture-of-experts model with 26 billion parameters and about 3.8 billion active, built on the Gemma 4 family with the diffusion process from Google's Gemini Diffusion research. It refines blocks of 256 tokens, fits in about 18 GB of VRAM when quantized, and runs at more than 700 tokens per second on an RTX 5090 (around 1,000 on an H100). License: Apache 2.0. Download: google/diffusiongemma-26B-A4B-it on Hugging Face.
• LLaDA (8B, with the LLaDA 1.5 preference-tuned update): the research line that showed diffusion language models can scale; ByteDance's follow-up iLLaDA was trained on 12 trillion tokens.
• Dream 7B (HKU and Huawei Noah's Ark, 2025): base and instruct models, plus Dream-Coder for code.

The trade-off is quality: DiffusionGemma trails the same-size Gemma 4 model on every quality benchmark Google published, and Google positions it for experiments and speed-sensitive interactive tools rather than production. Runtime support is also narrower: Hugging Face Transformers, vLLM and MLX (Macs) load it, while llama.cpp support was still planned and it is not an Ollama download. A quick way to try it on a Linux GPU box with a recent vLLM:

pip install -U vllm
vllm serve google/diffusiongemma-26B-A4B-it --port 8000
# then call http://localhost:8000/v1 with the OpenAI SDK, model "google/diffusiongemma-26B-A4B-it"

Where these open models shine is the non-linear work diffusion is good at: inserting text into an existing paragraph, filling a gap in code, or producing tightly structured output. For a fast, high-quality local chat model, a well-chosen open autoregressive model such as Qwen3.8-Flash-Next is still the safer pick; for a hosted diffusion model with top quality, Mercury 3 remains ahead.

Jake: "Could we run DiffusionGemma on the 5090 under my desk instead of paying for Mercury?"

Ethan: "For an internal autocomplete, maybe. For customer answers, test it against Mercury first; the quality gap is real."

Diffusion LLM applications: where the approach pays off

• Voice: the reply is ready before a person would notice a pause, which is why Inception also ships a voice-tuned model.
• Code completion and edits: filling the middle of a function uses the bidirectional view directly.
• Agents with many steps: shaving seconds off each of 30 calls turns a two-minute task into a twenty-second one.
• Structured extraction: forms, tables and JSON, where the output has a fixed shape to settle into.
• Interactive writing tools: rewriting a sentence in place, or suggesting the rest of a paragraph as you type.

Where it pays off less: one-off long reports, where a few seconds of extra latency hardly matter, and deep reasoning chains, where the strongest autoregressive models still produce better answers.

Jake: "Someone posted a 'mercury-3 GGUF' on a forum."

Ethan: "Then it's something else wearing the name. No weights were released. Don't run it."

Mercury 3 on AWS

Inception's earlier models, Mercury and Mercury Coder, arrived on Amazon Bedrock Marketplace and SageMaker JumpStart in August 2025, deployed to your own endpoints. Mercury 3 was not listed in either on its launch day. If you need it inside AWS today, call Inception's API (or OpenRouter) from your application; if you need a Bedrock-native model with AWS billing and IAM, pick one from the Bedrock catalog and compare. Keep an eye on the Bedrock Marketplace for a Mercury 3 listing.

A typical pattern is a Lambda function behind API Gateway that reads the Inception key from Secrets Manager once per container, caches it in memory, and calls Mercury 3 with the OpenAI SDK packaged in a layer. Reading the secret on every invocation adds latency and Secrets Manager charges, so fetch it outside the handler. Give the function a short timeout to match the model's speed, and send the model's latency to CloudWatch as a custom metric so you can see the effect of the switch on a dashboard.

Calling an outside API from AWS is ordinary, with three practical points: keep the API key in Secrets Manager rather than in code or environment files, make sure your Lambda functions or containers have outbound internet access (a NAT gateway in private subnets), and remember that data leaves your AWS account, which matters for regulated workloads. Bedrock Marketplace models, by contrast, run on endpoints inside your account, billed per hour of instance time rather than per token.

Errors on a first call

• 401 Unauthorized: the key is missing, wrong, or from another provider; check INCEPTION_API_KEY and the Bearer header.
• 404 or "model not found": the model name is mercury-3 on Inception's API and inception/mercury-3 on OpenRouter; the base URL must end in /v1.
• 429 Too Many Requests: you hit a rate limit; add retries with backoff, or ask for higher limits.
• Answers cut short: raise max_completion_tokens; reasoning effort uses some of the budget.
• Images ignored or rejected: it is a text-only model.
• A parameter rejected that works with OpenAI models: compatibility covers the common chat-completions fields; drop vendor-specific extras and retry.
• Different results from the chat site: the website may use different settings or system prompts; set your own system prompt and reasoning effort explicitly.

Most first-call failures are one of the first two: a key from another provider, or the OpenRouter model name sent to Inception's own endpoint (or the reverse).

Frequently asked questions

The shop now sends routine support questions (delivery times, return windows, sizes) to Mercury 3 and keeps its previous model for refunds and complaints. Answers appear almost as soon as the customer presses send, and the routine traffic costs about a quarter of what it did. Ethan has a reminder in the calendar for the day the launch discount ends, to re-run the numbers at list price.

Revision note. Written October 20, 2026, the day after launch, at launch-discount prices. We will update the prices when the discount ends and add a Bedrock section if Mercury 3 arrives there.