- Book: System Design Pocket Guide: Fundamentals
- The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
Fast mode for Claude Opus used to sit behind a door. Console organizations needed access provisioned, through an account manager or a waitlist, before a fast request would succeed, as Claude Code's fast mode page still describes it.
On October 15, Anthropic's release notes took the door off for one model. Fast mode "is out of research preview for Claude Opus 5.5, and you no longer need to request access." Every usage tier now has a default fast mode rate limit for Opus 5.5.
What you get is the same model running faster. The fast mode docs promise "up to 2.5x higher output tokens per second" at $8 per million input tokens and $40 per million output. Standard Opus 5.5 lists at $4 and $20. So you pay double per token, and the speed-up has limits worth knowing before you flip it on in production.
What changed on October 15
Three things, all from the October 15 release notes:
- Requests to Opus 5.5 no longer need the
fast-mode-2026-02-01beta header. Requests that still send it keep working. - Opus 5.5 has a default fast mode rate limit in every usage tier, so there is no access request.
- Fast mode for Opus 5.5 is now on Claude in Microsoft Foundry, for deployments hosted on Azure.
What didn't change: fast mode for Claude Opus 5 and Opus 4.8 "remains in research preview," and those requests still need the beta header, per the same entry.
Opting in is one field. This is the documented request, reformatted:
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-opus-5-5",
"max_tokens": 1024,
"speed": "fast",
"messages": [{"role": "user", "content": "Hello"}]
}'
The response's usage object carries a speed field, "fast" or "standard", so you can confirm which speed you were billed for.
What the 2x buys you, and what it doesn't
The docs are specific: "Speed benefits are focused on output tokens per second (OTPS), not time to first token (TTFT)." Same weights, same behavior, a faster inference configuration, and the gain is "most visible" with streaming.
That tells you where it pays. A request that writes a long diff, a migration or a multi-file refactor spends most of its time emitting tokens, so higher output speed shortens the wait. A short classification call that returns ten tokens spends its time before the first one, and fast mode doesn't target that part.
Fast mode speeds up output tokens per second. The wait for the first token isn't what it targets.
Here is the price side, from the pricing page. Opus 5.5 cache hits cost 0.05x the base input price, and the docs say "prompt caching multipliers apply on top of fast mode pricing," so the fast cache-hit figure below is that multiplier applied to $8:
| Opus 5.5, per MTok | Standard | Fast |
|---|---|---|
| Input | $4 | $8 |
| Output | $20 | $40 |
| Cache hit (0.05x input) | $0.20 | $0.40 |
Fast pricing is flat "across the full context window, including requests over 200k input tokens," and data residency multipliers stack on top as well, per the pricing page.
Switching speeds starts a new cache
This is the part that can cost more than the 2x. The API docs list it under considerations: "Switching between fast and standard speed invalidates the prompt cache. Requests at different speeds do not share cached prefixes."
So a long agent conversation cached at standard speed gets no cache hits on its first fast request. The whole history is read again at fast rates, plus the fast cache-write premium if you cache it again.
Claude Code handles this a little differently, and its prompt caching page spells it out. Turning on fast mode adds a request header that is part of the cache key, so the first fast request "reads the entire conversation history with no cache hits." After that first fast turn, Claude Code keeps the header and varies only the speed setting, so turning fast mode off and on again keeps the cache. The cost applies once per conversation.
Run the arithmetic on a 150,000-token Claude Code conversation using the published prices. Turning fast mode on deep into it bills those 150,000 tokens at the $8 fast input rate: $1.20. If the rebuilt prefix goes into a 5-minute cache, the 1.25x cache-write multiplier makes it $10 per million, or $1.50. The same turn at standard speed with a warm cache reads them at $0.20 per million: $0.03. That is why the Claude Code docs tell you to enable fast mode "at the start of a session rather than switching mid-conversation."
Fast and standard requests keep separate cached prefixes. Crossing over means re-reading the whole history at least once.
On the API, a 429 is not a fallback
Fast mode has "a dedicated rate limit that is separate from standard Opus rate limits," per the rate limits section. Exceed it and you get a 429 with a retry-after header. The API does not fall back to standard speed on its own. The SDKs retry such requests "up to 2 times by default," and the docs say the delay is "typically short." Claude Code behaves differently: when it hits the fast mode rate limit, it falls back to standard speed and pricing, then turns fast mode back on when the cooldown expires.
Six response headers track the pool, from anthropic-fast-input-tokens-limit to anthropic-fast-output-tokens-reset, all listed in the same section. If you call the API yourself and would rather run slower than wait, the docs show an opt-in client-side fallback. Here is a trimmed version of that pattern for the TypeScript SDK:
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
const base = {
model: "claude-opus-5-5",
max_tokens: 1024,
messages: [{ role: "user" as const, content: "Hello" }],
};
async function ask() {
try {
return await client.messages.create(
{ ...base, speed: "fast" },
{ maxRetries: 0 },
);
} catch (e) {
if (e instanceof Anthropic.RateLimitError) {
// standard price, and a prompt cache miss
return client.messages.create(base);
}
throw e;
}
}
Setting maxRetries: 0 skips the automatic retries, but it also skips them for overloaded and server errors. The full example in the docs reissues those with retries. The fallback request also starts a new cache, which the docs note too.
Where you still can't use it
The fast mode page lists the gaps:
- Not on Amazon Bedrock, Claude Platform on AWS, or Google Cloud.
- On Microsoft Foundry, only for Azure-hosted deployments, "not for deployments hosted on Anthropic."
- Not with the Batch API.
- Not with a Priority Tier commitment.
In Claude Code on a Pro, Max, Team or Enterprise plan, /fast bills "via usage credits only and not included in the subscription rate limits," and Team and Enterprise need an Owner to enable it first, per the Claude Code fast mode page. On October 15, that page still called the feature a research preview and listed Microsoft Foundry as unsupported, so the Claude Code docs hadn't caught up with the API release notes yet. If your org runs Claude Code on an API key, try /fast before you trust either page.
Whichever surface you use, turn fast mode on at the start of a session, not halfway through, and check usage.speed in the response.
If this was useful
I build Hermes IDE, so weigh this with that in mind: it is a free, source-available (BSL 1.1) app for macOS, Windows and Linux that runs Claude Code, Codex and other coding agents side by side, each on its own branch. Download it or star it on GitHub. It is not affiliated with Nous Research, Anthropic, OpenAI or any agent vendor.
Fast mode is a latency-for-money trade with its own rate-limit pool and its own cache. The System Design Pocket Guide: Fundamentals covers those building blocks: rate limits, caching, and what a system does when a dependency says no. It is one of 8 short books in the Pocket Guides for Developers series, covering agents, RAG, prompts, observability, events, databases and system design, all here.
Top comments (0)