Short version. Since 15 October, fast mode on Claude Opus 5.5 needs no waitlist and no beta header on the Claude API. It costs $8 in and $40 out per million tokens, twice the standard rate, for up to 2.5x faster output. The catch we'd plan around: fast and standard requests don't share a prompt cache, so the fallback recipe in Anthropic's own docs can turn a cheap cache hit into a full cache write.
Your agent streams a long refactor and somebody's staring at the terminal while it types. That's the case fast mode was built for, and as of 15 October anyone on the Start, Build or Scale tier can switch it on for Opus 5.5 with one field, speed: "fast". No access request. No fast-mode-2026-02-01 header (old requests that still send it keep working). We read the fast mode page and the pricing page line by line, because the price is the easy part. It's the cache rules that'll surprise people.
What left preview, and what didn't
Only Opus 5.5 graduated. Fast mode on Opus 5 and Opus 4.8 is still a research preview: you join a waitlist or ask your account manager, and you keep sending the beta header. If you pinned an older Opus and wondered why your teammate got fast mode without asking, that's why.
Availability is narrower than the model's. Fast mode runs on the Claude API, including Managed Agents, and on Claude in Microsoft Foundry for deployments hosted on Azure. It's not on Claude Platform on AWS, not on Foundry deployments hosted on Anthropic, and not on the partner clouds (Bedrock, Vertex). It also won't combine with the Batch API or a Priority Tier commitment. Organizations still in the Evaluation tier have to move up to Start before the default limit applies.
The rate limit is its own bucket, separate from your standard Opus limits. When it runs dry you get a 429 with a retry-after header, and six response headers tell you where you stand, from anthropic-fast-input-tokens-remaining to anthropic-fast-output-tokens-reset. Anthropic doesn't print the default numbers in the docs; the Console's Rate limits page shows yours. Every response also carries usage.speed, set to "fast" or "standard", which is the field we'd log if you want to reconcile the bill later.
The price, with every multiplier stacked
Standard Opus 5.5 is $4 in and $20 out. Fast mode is $8 and $40, and it stays flat across the whole 1M window, including prompts past 200K. That part's clean. Then the modifiers pile on top, and the docs say they all stack:
- Cache reads on Opus 5.5 bill at 0.05x input, so a fast cache hit is $0.40 per million instead of $0.20. A 5 minute cache write is 1.25x ($10), a 1 hour write is 2x ($16).
- US-only inference with
inference_geo: "us"adds 1.1x on every category, which takes fast mode to $8.80 and $44.
Is it worth it? Twice the price for "up to" two and a half times the output speed reads like a fair trade when a person is waiting on the stream. It doesn't help time to first token at all, the docs are explicit about that, so short answers barely change. For background agents nobody watches, it's money spent on nothing, and the Batch API at $2 and $10 is a quarter of the fast price. We'd also be careful with the "up to". Anthropic doesn't publish a floor, and we haven't measured it ourselves, so I'd test it on your own prompts at your busiest hour before moving a whole team over.
The fallback that costs you the cache
Here's what we'd flag in any design review. The docs suggest a sensible pattern: send the request with speed: "fast" and max_retries at 0, and if you get a 429, retry at standard speed instead of waiting. The same page then warns that "requests at different speeds do not share cached prefixes." So the fallback lands on a cold cache.
Run the numbers on a coding agent that carries a 150K token cached prefix. On fast mode, a cache hit on that prefix costs 0.15 x $0.40, so $0.06. Fall back to standard and the prefix has to be written again at the 5 minute rate: 0.15 x $5, or $0.75. If the fast cache has expired by the time capacity comes back (the default lifetime is 5 minutes), switching again means another write, this time at $10 per million, so $1.50. One rate limit at the wrong moment turns six cents into more than two dollars of cache writes, before a single output token. On a long-context agent that flips back and forth a few times an hour, it adds up fast.
Our take: for long cached sessions, let the SDK do its default two retries on the fast bucket, since Anthropic says replenishment is continuous and the retry-after is usually short, and only fall back when the context is small. For short prompts with little or no cache, the fallback recipe's fine as written. I might be wrong about where the break-even sits for your traffic, so log usage.speed next to the cache read and write counts for a week and look.
We've updated the Opus 5.5 row in our LLM API pricing tracker to drop the preview label. The model's other quirks are in our Opus 5.5 breaking changes piece.
FAQ
Do I still need the fast-mode-2026-02-01 header for Opus 5.5?
No. Since 15 October it isn't required for claude-opus-5-5, though requests that still send it keep working. Opus 5 and Opus 4.8 still need it, along with an approved access request.
Is fast mode a different or smaller model?
No. Anthropic says it's the same model and weights on a faster inference configuration, with no change in capability. The gain is in output tokens per second, not in time to first token.
Can I use fast mode through Bedrock or Vertex?
Not today. It's limited to the first-party Claude API and to Azure-hosted deployments of Claude in Microsoft Foundry. Claude Platform on AWS doesn't offer it either.
What happens if I hit the fast mode rate limit?
The API returns a 429 with a retry-after header, and the SDKs retry twice by default. Retrying at standard speed works, but it misses the prompt cache, because the two speeds don't share cached prefixes.
Sources: Anthropic, Claude Platform release notes (15 October 2026); Anthropic, Fast mode documentation; Anthropic, Pricing (fast mode, prompt caching, data residency); ClaudeFast, Claude Code fast mode guide.
