Opus 5.5 Fast Mode Goes GA: Double the Price and a Caching Trap

Anthropic moved Claude Opus 5.5's Fast Mode out of research preview on October 15. Developers no longer need to contact an account manager or wait in an approval queue, and every usage tier now has default fast mode rate limits. The cost is double the price—plus a caching pitfall that's easy to stumble into.

What Fast Mode actually changed

Fast Mode used to be a door that required a key. According to Claude Code's official documentation, Console organizations had to be enabled through an account manager or a waitlist before fast requests would succeed. The October 15 release notes tore that door off—but only for the Opus 5.5 model.

There are three specific changes: Opus 5.5 requests no longer need the fast-mode-2026-02-01 beta header (requests that still include it continue to work as before); every usage tier has default fast mode rate limits with no application required; and Fast Mode now supports Claude in Microsoft Foundry deployed on Azure.

What hasn't changed: Fast Mode for Opus 5 and Opus 4.8 "remains in research preview," and those requests still need the beta header. The switch itself is a single field—add "speed": "fast" to the request, and the response's usage object returns a speed field (with a value of "fast" or "standard") that you can use to confirm which speed you're actually being billed for.

Where it's fast, and where it isn't

The official documentation is explicit: the speed gains are concentrated in output tokens per second (OTPS), not time to first token (TTFT). Same model weights, same behavior, just a faster inference configuration—and the gains are "most noticeable" when streaming.

That directly determines whether it's worth it. Requests that write long diffs, do database migrations, or refactor across files spend most of their time emitting tokens, so raising output speed meaningfully cuts the wait. A short classification call that returns ten tokens, on the other hand, spends almost all its time before the first token appears—and Fast Mode doesn't target that segment at all.

On pricing, Opus 5.5 standard is $4 input and $20 output per million tokens; Fast is $8 and $40. The cache hit discount is 0.05x the base input price, and the documentation states that the prompt caching multiplier stacks on top of fast pricing, so the fast cache hit price is $0.40 per million tokens. Fast pricing is flat across the entire context window, including requests that exceed 200k input tokens, and data residency multipliers stack as well.

Opus 5.5 (per million tokens)	Standard	Fast
Input	$4	$8
Output	$20	$40
Cache hit (0.05x input)	$0.20	$0.40

Why the OTPS-versus-TTFT distinction determines the experience. TTFT (Time To First Token) measures the time from sending a request to receiving the first output token, and it's primarily determined by queuing, prefill, and network round trips. For long-context requests, the more input tokens prefill has to process, the longer TTFT becomes. OTPS (Output Tokens Per Second) measures the model's sustained token emission speed after the first token—that is, throughput during the decode phase. The two optimize different resources: TTFT is bottlenecked by prefill and queuing, while OTPS is bottlenecked by decode bandwidth and batching strategy. Fast Mode only touches OTPS, which tells you it optimizes the decode path, not the waiting path. This explains a counterintuitive phenomenon—the same model weights, nearly identical behavior, yet dramatically faster on long-output tasks. For agent-style workloads that need to stream out large volumes of tokens, OTPS is the real bottleneck.

Switching speed rebuilds the cache

This one can be more expensive than the doubled price. The API documentation notes under "Considerations": switching between fast and standard speed invalidates prompt caching, and requests at different speeds don't share cached prefixes.

In other words, a long conversation that's already cached at standard speed gets zero cache hits on its first fast request—the entire history is re-read at the fast rate, and if you cache it again you also pay the fast cache write premium.

Claude Code handles this slightly differently. Its prompt caching documentation explains that turning on fast mode adds a request header, and that header is part of the cache key, so the first fast request "reads the entire conversation history with no cache hits." After that, Claude Code keeps the header and only changes the speed setting, so turning fast mode off and back on doesn't lose the cache—you pay that cost once per conversation.

Do the math on a 150,000-token Claude Code conversation: turning on fast mode halfway through bills those 150,000 tokens at the $8 fast input rate, which is $1.20; if the rebuilt prefix goes into the 5-minute cache, the 1.25x cache write multiplier brings the price to $10 per million, or $1.50. Meanwhile that same turn at standard speed with a warm cache costs $0.20 per million to read, or just $0.03. The gap spans two orders of magnitude. This is why the Claude Code documentation recommends "enabling fast mode at the start of a session rather than switching mid-conversation."

Why prompt caching is speed-sensitive. Prompt caching works by precomputing and storing the KV cache for a stable prefix (typically the system prompt, tool definitions, and conversation history) so that subsequent requests can reuse it directly and skip redundant prefill. Hit determination is based on an exact match of "prefix + cache key," and the cache key includes some request metadata. If the cache keys of different requests don't match, even a byte-identical text prefix is judged a miss, triggering recomputation and a cache write for the entire prefix. Fast Mode's speed setting happens to land in that key, so fast and standard naturally occupy two separate, non-communicating cache spaces. Cache writes are typically billed at 1.25x the base input price, which is why "switching once" isn't just re-reading history—it also incurs an extra write premium. For a 150,000-token conversation, that alone is enough to open up a two-order-of-magnitude gap.

A 429 on the API won't auto-downgrade

Fast Mode has a "dedicated rate limit pool separate from standard Opus rate limits." Exceeding it returns a 429 with a retry-after header, and the API does not downgrade to standard speed on its own. The SDK retries such requests up to 2 times by default, and the documentation says the delay is "usually very short."

Claude Code behaves differently: when it hits a fast mode rate limit, it downgrades to standard speed and standard pricing, then automatically switches back to fast once the cooldown ends.

Six response headers track this pool, from anthropic-fast-input-tokens-limit to anthropic-fast-output-tokens-reset. If you're calling the API yourself and would rather run slower than wait, the official documentation provides a client-side downgrade approach: catch the RateLimitError and resend the request at standard speed. Note that setting maxRetries: 0 skips automatic retries—but it also skips retries for overload and server errors, so the full example re-throws and retries those errors. Downgraded requests also open a new cache, which the documentation also notes.

Why the API chooses not to auto-downgrade. 429 Too Many Requests means a rate limit has been hit, and the retry-after header tells the client how long to wait before trying again. Fast Mode has a rate limit pool separate from standard, meaning that when the fast quota is exhausted, the standard quota may still be plentiful—so in theory there's room to downgrade. But the API layer won't make that decision for the client, because speed is a billing attribute: if the server quietly processed a fast request as standard, the caller would get a slower response without knowing it while still believing they'd bought fast. Downgrading therefore has to be explicitly initiated by the client, which then bears the consequences of opening a new cache on the downgraded request. This is a separate matter from the SDK's default retry policy: the SDK's retry is a "same-speed retry," and only after retries are exhausted does it fall to the caller to decide whether to downgrade. Setting maxRetries: 0 also turns off retries for overload and 5xx errors, which is why the official example opts to re-throw errors and handle them in one place.

Where you still can't use it

The official fast mode page lists the current capability gaps:

• Not supported on Amazon Bedrock, Claude Platform on AWS, or Google Cloud;
• On Microsoft Foundry, limited to Azure-hosted deployments, "Anthropic-hosted deployments are not supported";
• Batch API not supported;
• Priority Tier committed usage not supported.

In Claude Code on Pro, Max, Team, or Enterprise plans, /fast can only be billed through usage credits and isn't included in the subscription's rate limits; Team and Enterprise also require an Owner to enable it first.

It's worth noting the documentation is out of sync: on October 15 itself, Claude Code's fast mode page still called the feature a research preview and listed Microsoft Foundry as unsupported—Claude Code's documentation hadn't caught up with the API release notes. If your team runs Claude Code on an API key, rather than trusting any single page of documentation, just try /fast directly.

Whichever entry point you use, remember two things: turn on fast mode at the start of a session, not mid-way; and use usage.speed to confirm the speed you're actually billed for.

Fast Mode is essentially a trade of money for latency, with its own dedicated rate limit pool and its own dedicated cache.