Claude Opus 5.5 Fast Mode: Is 2x the Price Worth It?

It's the same Opus 5.5 model served on a faster inference configuration. Same weights, same intelligence, more output tokens per second. You turn it on per request with one field. Since October 15, 2026 it's generally available on Opus 5.5: no beta header, no waitlist, and a default fast rate limit in the Start, Build and Scale tiers. The official fast mode docs promise "up to 2.5x higher output tokens per second" and say the gain is about throughput, not time to first token.

• Price: $8 input / $40 output per MTok, against $4 / $20 at standard. Cache and data-residency multipliers stack on top of that.
• Models: Opus 5.5 (GA), Opus 5 and Opus 4.8 (research preview, beta header required). Not Sonnet, not Haiku.
• Where: the Claude API and Managed Agents, Claude Models on Google Cloud (Anthropic managed), and Microsoft Foundry deployments hosted on Azure.
• Rate limit: separate from your normal Opus limits, reported in anthropic-fast-* response headers.

If you're still deciding whether to move to Opus 5.5 at all, start with my Opus 5.5 vs Opus 5 migration notes. Fast mode on 5.5 is also cheaper than fast mode on Opus 5 ($10/$50), so it's one more reason to move.

Every blog post I found repeated the "2.5x" line. Nobody had timed it, so I did. On October 26, 2026 I sent 20 streamed requests to claude-opus-5-5 on the live API: two prompts, five rounds, both speeds, alternating which speed went first each round so neither got a warm-connection advantage. All at effort: "low". I timed every server-sent event and read usage.speed on each response to confirm what I was billed for.

Long output (write a ~900-word Python module, max_tokens: 3000, every run hit the cap):

Short output("In two sentences: what is a webhook?", ~100 tokens):

The numbers were tight. Fast mode's long-output runs landed between 371 and 386 tokens per second. Standard sat between 136 and 143. That's 2.7x on throughput and 2.8x on wall-clock time for the long task, a bit better than the docs promise. On the short answer it was 2.3x end to end.

Two things surprised me. First, time to first token also halved on the short prompt (0.85 s to 0.43 s), even though the docs only promise output speed. I'd treat that as a nice-to-have from one account on one Monday morning, not a guarantee. Second, and more interesting: on the long prompt, standard speed spent 410 to 727 tokens on adaptive thinking before writing anything, and fast mode spent zero in all five runs. That's most of the 7-second gap in first token. It isn't a rule, though. On a reasoning puzzle at effort: "medium" and "high", both speeds thought for about 100 tokens. Adaptive thinking decides per request, so don't build on fast mode thinking less. If you need thinking gone, use the levers from my turning off thinking on Opus and Sonnet 5.5 post.

Takeaway: fast mode delivered what it says on the box, roughly 2.5 to 2.8x faster output, very consistently.

Per token, exactly 2x. Per call in my long test, $0.121 instead of $0.060. The whole benchmark, including the cache and error tests below, came to roughly a dollar.

The more useful way to price it is per second of waiting removed. On the long task, fast mode saved 15.5 seconds for an extra $0.06. That works out to about $14 per hour of human waiting eliminated. On the short answer it saved 1.1 seconds for $0.0022, about $7 per hour. If the person staring at the spinner is a developer or a customer, both numbers are cheap. If nobody is staring at anything, you're buying time nobody uses.

One detail cut in fast mode's favor in my run: because standard burned up to 727 of its 3,000 tokens on thinking, fast mode returned more actual code for the same cap (about 7,400 characters vs 5,750). Per character of visible output, fast was about 1.55x the cost, not 2x. That's an artifact of this prompt and the max_tokenscap, so don't budget on it, but it shows why you should compare cost per finished answer, not per token.

Prompt caching still works, at fast-mode prices: a cache read is 0.05x of $8, so $0.40 per MTok, and a 5-minute cache write is $10. Which brings us to the gotcha.

No, and this is the one that'll quietly cost you. The docs mention it in a note under fallbacks. I wanted to see it in the usage numbers, so I sent five requests with the same 7,634-token system prompt marked with cache_control:

# 7,634-token system prompt with cache_control, same prefix every call
std-1   speed=standard  cache_write=7634  cache_read=0
std-2   speed=standard  cache_write=0     cache_read=7634
fast-1  speed=fast      cache_write=7634  cache_read=0      <- standard cache ignored
fast-2  speed=fast      cache_write=0     cache_read=7634
std-3   speed=standard  cache_write=0     cache_read=7634   <- standard cache still warm

Each speed keeps its own cache. The first fast request paid for a full cache write even though the exact same prefix was warm at standard speed seconds earlier. So if your app flips between fast and standard (fast for interactive turns, standard for the background summarizer that reuses the same system prompt), you're paying two cache writes and splitting your hit rate. Same if a fallback kicks in under load.

If your cache hit rate drops after turning fast mode on, this is the first thing to check. My prompt cache miss diagnostics checklist covers the other usual suspects.

Takeaway: pick one speed per cached prefix and stick to it.

Here's how I'd split it across the kinds of systems I build for clients:

• Worth it: interactive coding and chat UIs with long answers. A 24-second wait vs an 8-second wait is the difference between someone staying in flow and someone switching tabs.
• Worth it: sequential agent loops someone is watching. Latency compounds. Ten tool-calling turns that each write a few hundred tokens add up to real minutes, and fast mode cuts every one of them.
• Maybe: customer-facing chat with short replies. You save about a second per reply. Test whether your users notice before paying double for it.
• Not worth it: batch, cron and background pipelines. n8n workflows that run at 3 a.m., nightly enrichment, report generation. Nobody is waiting, and the Batch API's 50% discount points the other way entirely.
• Not worth it: classification and extraction.Outputs are tiny, so there's no throughput to gain. Haiku 5.5 is cheaper and quick enough.

For voice agents, the bottleneck is usually time to first token and turn-taking, not tokens per second, and you're rarely running Opus there anyway. I covered where voice latency really comes from in why your voice AI agent keeps interrupting.

I sent speed: "fast" where it doesn't belong to collect the exact errors:

# claude-sonnet-5-5 or claude-haiku-5-5 with speed: "fast"
400  'claude-sonnet-5-5' does not support the `speed` parameter.
     This feature is only available on supported models.

# claude-opus-5 with speed: "fast", no beta header
400  To use the `speed` parameter with 'claude-opus-5', send the
     `anthropic-beta: fast-mode-2026-02-01` header.

# Message Batches: POST succeeds, then each result says
errored  The `speed` parameter is not supported for batch requests.

The batch one is the sneaky one. POST /v1/messages/batches returned a normal in_progressbatch. The failure only showed up about 30 seconds later in the results file, as an errored request. If your batch code doesn't read per-request errors, you won't see it at all. The parameter also works on the new 2026-10-21 API version, so the 2026-10-21 migration doesn't touch it.

The other failure mode is capacity. Fast mode has its own per-minute limits (my org's headers showed 800,000 output tokens and 4,000,000 input tokens per minute) and returns 429 or 529 when you hit them. The SDK retries 429s twice by default, waiting for retry-after. That's fine for a script, but in an interactive app you'd usually rather fall back right away.

Try fast once with retries off, and if it's a capacity error, send the same request without speed. This is what I use, with Python SDK 2.3.0:

import anthropic

client = anthropic.Anthropic()

def create_fast_or_standard(**params):
    """Try fast mode once; on a capacity error, rerun at standard speed."""
    try:
        return client.with_options(max_retries=0).messages.create(speed="fast", **params)
    except anthropic.APIStatusError as e:
        if e.status_code not in (429, 529):
            raise
        return client.messages.create(**params)  # standard speed, separate prompt cache

msg = create_fast_or_standard(
    model="claude-opus-5-5",
    max_tokens=200,
    messages=[{"role": "user", "content": "Summarize this ticket in one line: ..."}],
)
print(msg.usage.speed)  # "fast", or "standard" if it fell back

I tested both branches. Against the live API it printed fast. Against a local stub that answers fast requests with 429, and then with 529, it logged exactly one fast attempt followed by one standard request, and printed standard. Only the fast call has retries disabled, so the fallback still gets the SDK's normal retry behavior for overloads and 500s.

Remember the cache split: every fallback is a cache miss. If 429s are frequent, that's a sign to send less traffic to fast mode, not to fall back harder. My Claude 429 rate limit playbook has the monitoring side. And log usage.speed on every response, so your cost reports know which rate each call was billed at.

Takeaway: fast mode is a per-request decision. Route it to the few calls where a human is waiting, and keep everything else at standard.