Claude Code fast mode is out of preview: 2.5x faster for double the price. Worth it?
Claude Code fast mode is Opus running up to 2.5x faster for double the price per token. You type /fast and that's it.
What nobody tells you: that speed doesn't come out of your Max plan. It comes out of your credit card. And if you turn it on in the middle of a long conversation, the first message reprocesses the entire context uncached, at full fast-mode price.
And now it's out of research preview on Opus 5.5. The changelog for version 2.1.304 removed the "(research preview)" label from the /fast dialog, and the API docs now list the feature as available on Opus 5.5 with no beta header. In this tutorial you'll see what fast mode really is, what it costs on paper, how to turn it on in every environment (CLI, settings, VS Code, headless) and when it actually pays off.
TL;DR
- What it is: Claude Code's fast mode. The same Opus with an inference configuration that prioritizes speed. Up to 2.5x more output tokens per second. Same quality.
- Models: Opus 5.5 (default), Opus 5 and Opus 4.8. Not available on Sonnet or Haiku.
- Cost: $8/$40 per MTok (input/output) on Opus 5.5, versus $4/$20 for standard Opus 5.5. Exactly double.
- Subscription: on Pro, Max, Team and Enterprise, it bills usage credits. Never your plan's included usage.
- Gotcha: turning it on mid-conversation charges the whole context as uncached input on the first message.
- Docs: fast mode in Claude Code and fast mode in the API.
Context: what changed when fast mode left preview
Fast mode is not a new model. The official docs are explicit: it's Claude Opus running on a different API configuration that trades cost efficiency for speed. Same intelligence, same capabilities, faster responses.
And "faster" comes with a fine print most people skip. According to the API docs, the gain is in output tokens per second (OTPS), not time to first token (TTFT). In other words: the model doesn't start answering sooner. It writes faster once it starts.
What changed, in three verifiable points:
- VERIFIED: the Claude Code changelog for version 2.1.304 says: "Removed the '(research preview)' label from the
/fastdialog title on Opus 5.5". - VERIFIED: in the API, fast mode on Opus 5.5 no longer needs a beta header or an access request, and it has a default rate limit in the Start, Build and Scale tiers. Opus 5 and Opus 4.8 remain in research preview and require the
fast-mode-2026-02-01header. - Nuance: the Claude Code fast mode page still carries the general research preview notice, because the feature covers three models and two of them are still in preview. What left preview is fast mode on Opus 5.5.
The history explains today's price. Fast mode debuted on Opus 4.6 (version 2.1.36). In 2.1.154 it got much cheaper on Opus 4.8: "2x the standard rate for 2.5x the speed". Since 2.1.280, the fast mode default is Opus 5.5. The formula held: double the price, up to 2.5x the output speed.
The question stops being "does it work?" and becomes "when is it worth paying double for latency?". That answer isn't in the docs. It depends on your workflow, your context size and what your time waiting on the agent is worth. That kind of call, when to pay for speed and when to let the agent run at standard pace, is what we put on the table every week, live, in the Clã Beer and Code: people running harnesses and agents in production, comparing real bills.
Claude fast mode pricing, on paper
The official table, checked on the pricing page on 10/26/2026:
| Model | Standard (input/output per MTok) | Fast mode (input/output per MTok) |
|---|---|---|
| Opus 5.5 | $4 / $20 | $8 / $40 |
| Opus 5 | $5 / $25 | $10 / $50 |
| Opus 4.8 | $5 / $25 | $10 / $50 |
Three details that change the math:
- Pricing is flat across the whole context. No step above 200k tokens. It applies to the full 1M window.
- Caching still applies. Prompt caching multipliers stack on top of fast mode pricing. On Opus 5.5, a cache hit costs 0.05x the base input. In fast mode, that's $0.40/MTok instead of $0.20.
- Cache isn't shared across speeds. Fast and standard keep separate caches. That's where the gotcha comes from.
The uncached context gotcha
The Claude Code docs spell it out: the first time you turn on fast mode in a conversation, you pay the full fast-mode uncached input price for the entire conversation context. And every later switch between fast and standard reads part or all of the context uncached again.
Run the numbers on a session with 150k tokens of context, which is normal after an hour working in a repo:
Sessão em velocidade padrão, próxima mensagem (cache hit):
150.000 tokens x US$ 0,20/MTok = US$ 0,03
Liga /fast nessa mesma sessão, primeira mensagem (sem cache):
150.000 tokens x US$ 8,00/MTok = US$ 1,20
(Standard speed with a cache hit: $0.03. First message after /fast, uncached: $1.20.)
The same message costs 40x more on input alone. Once is nothing. The problem is the habit of toggling /fast on and off several times a day in long sessions. Every round trip rebuilds the cache.
The rule Anthropic itself recommends: turn fast mode on at the start of the session, not in the middle. If the session is already bloated and you want speed, it's sometimes cheaper to open a new session with lean context. I covered how prefix caching dominates your bill in the post on saving tokens in Claude Code, Codex and Cursor. Fast mode just amplifies all of that.
Subscription: it doesn't come out of your Max
This is what catches most people. On Pro, Max, Team and Enterprise, fast mode is billed only to usage credits. The docs are blunt: "Fast mode usage draws directly from usage credits, even if you have remaining usage on your plan."
In practice:
- You need usage credits turned on. Without them,
/fastreplies "Fast mode requires usage credits". - On Pro and Max, turn them on under Settings > Usage on claude.ai, or run
/usage-creditsto open the page. - On Team and Enterprise, fast mode is off by default. An Owner has to enable it under Organization settings > Claude Code, and someone with billing access has to turn on the organization's usage credits.
- Spend shows up in your monthly usage credits total, with no separate fast mode line.
If you pay for Max precisely so you never see a meter running, fast mode brings the meter back. To compare against the rest of your Claude Code bill, check the real Claude Code pricing in 2026.
Prerequisites
Before turning it on, check:
- [ ] Claude Code is up to date. Opus 5.5 as the fast mode default requires v2.1.280 or later. Run
claude --version. - [ ] Logged in with a subscription (Pro, Max, Team, Enterprise) with usage credits on, or a paid Claude Console organization.
- [ ] Direct Anthropic API. Fast mode in Claude Code doesn't run on Amazon Bedrock, Google Cloud Agent Platform, Microsoft Foundry or Claude Platform on AWS.
- [ ] On Team/Enterprise: an Owner has already enabled the feature.
To check how you're logged in, run /status. If you see a Login method row (like Claude Max account), you're on a subscription. If you see API key, billing goes to the Console organization.
A tutorial shows you the way — in the Clã you build alongside us. A live class every week, real AI Engineering projects, next to people already in production.
Join the ClãHands-on: how to turn on Claude Code fast mode
Step 1: turn it on in the CLI with /fast
In the terminal, inside a session:
/fast
A dialog opens. Press Space to toggle and Enter to confirm. You'll see "Fast mode ON" and a ↯ icon next to the prompt while fast mode is active.
Details worth knowing:
- If your current model doesn't support fast mode (Sonnet, for example), turning it on switches you to Opus.
- You can run
/fastwhile Claude is working. The current turn finishes at the original speed and fast mode applies from the next one. - Turning fast mode off keeps you on Opus. To switch models, use
/model. - Switching to an unsupported model turns fast mode off. Switching back to a supported Opus turns it on again, if your saved preference is on.
Step 2: make it the default (or block it) via settings
The /fast toggle is saved in the fastMode setting. You can set it directly in your user settings file:
{
"fastMode": true
}
By default, fast mode you turn on in an interactive session persists into the next ones. If you run several sessions in parallel, that's an efficient way to burn credits without noticing. To require opt-in per session:
{
"fastModePerSessionOptIn": true
}
With that, every session starts with fast mode off and you turn it on explicitly with /fast. Team and Enterprise Owners can roll this out organization-wide via server-managed settings. To disable the feature entirely on a machine:
export CLAUDE_CODE_DISABLE_FAST_MODE=1
Step 3: VS Code, web and headless
VS Code: the extension offers a Toggle fast mode command in the command palette when the selected model supports fast mode. The toggle is also saved to fastMode. Note the fix in version 2.1.300: previously, fast mode stayed on after usage credits ran out, and every request was refused and resent. Now it turns off and shows an error notice until you turn it back on.
Claude Code on the web and cloud sessions: type /fast on in the session. It applies to that session only and doesn't become your default. At claude.ai/code there's also a switch in the model menu of the message box. Requires v2.1.271 or later in the session's environment.
Headless (claude -p): /fast only works if the session is launched with fast mode in its settings. Requires v2.1.205 or later:
claude -p --settings '{"fastMode": true}' "rode os testes e corrija o que falhar"
In this case the toggle applies only to that run and isn't saved as your default. But think twice before using it in a pipeline: the docs themselves list batch and CI/CD as cases where standard mode makes more sense. Nobody is watching the terminal waiting for tokens.
Step 4: understand the fallbacks
Fast mode has its own rate limit, separate from standard Opus, and all fast-mode models share the same pool. When you hit the limit:
- Claude Code automatically falls back to standard speed.
- The
↯icon turns gray to indicate cooldown. - You keep working at standard speed and pricing.
- When the cooldown expires, fast mode comes back on its own.
If you run out of usage credits mid-session, each rejected request is retried at standard speed, with no cooldown. In an interactive session, you'll see "Fast mode disabled · usage credits exhausted" and fast mode turns off for the rest of the session. In non-interactive mode with --output-format stream-json and in the Agent SDK, the notice arrives as a system message with subtype notification, and fast mode stays on.
Remember the gotcha? Every fallback from fast to standard is also a cache miss. The API docs confirm it: requests at different speeds don't share cached prefixes.
Is fast mode on Opus 5.5 worth it? When to use it and when not to
Run the numbers on a typical agentic loop: 30 requests in one task, each with 80k tokens of cached context and 2k output tokens, on Opus 5.5.
Padrão por request: 80k x US$ 0,20 + 2k x US$ 20 = US$ 0,016 + US$ 0,040 = US$ 0,056
Fast por request: 80k x US$ 0,40 + 2k x US$ 40 = US$ 0,032 + US$ 0,080 = US$ 0,112
30 requests: US$ 1,68 (padrão) vs US$ 3,36 (fast), sem contar o cache miss inicial
(Standard: $0.056 per request, $1.68 for 30. Fast: $0.112 per request, $3.36 for 30, not counting the initial cache miss.)
Double the cost, no surprise. The same latency-versus-price debate came up with GPT-5.6 Sol Ultrafast, except there it was dedicated hardware. What decides whether it's worth it is the time you save. And here's where the OTPS detail matters: fast mode speeds up text generation. It doesn't speed up the npm test the agent runs, the build, the repo search or the time to first token. In a loop where half the clock is tools executing, the real gain is well below 2.5x.
Use fast mode when:
- You're iterating live, watching the terminal, and every response blocks you.
- Real-time debugging, with hypothesis, test and fix in short cycles.
- Tight deadlines where your hour is worth far more than a few dollars.
- Long text or code responses, where OTPS dominates the clock.
Stay on standard when:
- Long autonomous tasks you'll leave running.
- Batch, CI/CD, headless pipelines.
- Loops dominated by tool execution.
- Sessions already heavy with context (the initial cache miss eats the advantage).
A combination the docs suggest: fast mode with a lower effort for simple tasks. Fast mode keeps quality and cuts latency; low effort cuts thinking time. Together you get maximum speed, knowing low effort can lose quality on complex tasks.
Limitations and caveats
- Silent persistence. Fast mode turned on in an interactive session becomes the default for the next ones. Five open terminals, five running meters. Use
fastModePerSessionOptInif that worries you. - Gateways and proxies. Before offering fast mode, Claude Code checks availability directly at
api.anthropic.com, ignoringANTHROPIC_BASE_URL. Behind an LLM gateway that blocks direct egress,/fastmay say it's unavailable even with your organization enabled. TheCLAUDE_CODE_SKIP_FAST_MODE_NETWORK_ERRORSandCLAUDE_CODE_SKIP_FAST_MODE_ORG_CHECKvariables bypass the client-side check, but they don't unlock anything the API rejects. - No third-party clouds in Claude Code. Bedrock, Agent Platform, Foundry and Claude Platform on AWS are out for Claude Code.
- No Batch API and no Priority Tier. In the API, fast mode works with neither.
- Opus 4.7 isn't supported. Fast mode for Opus 4.7 was deprecated on 06/25/2026 and removed on 07/24/2026. Switching to it turns fast mode off.
- Pricing may change. Opus 5 and Opus 4.8 are still in research preview. Check the pricing page before locking in a budget.
Quick FAQ
Does Claude Code fast mode make responses worse? No. According to the official docs, it's the same model with a different inference configuration, with identical quality and capabilities. What changes is output speed and price. If you want to trade quality for speed, the lever is effort, not fast mode.
Does /fast use up my Max plan's limits?
No. Fast mode bills only usage credits, even if you have usage left on your plan. Without usage credits on, /fast won't even turn on. Track spend under Settings > Usage on claude.ai, or with /usage on Team and Enterprise.
Why doesn't fast mode show up for me?
The most common causes: unsupported model (Sonnet, Haiku, Opus 4.7), usage credits off, a Team/Enterprise organization where the Owner hasn't enabled it, managed settings with fastMode: false, login via Bedrock, Agent Platform or Foundry, or a gateway blocking the check at api.anthropic.com.
Can I use fast mode directly in the API, outside Claude Code?
Yes. On Opus 5.5, just send "speed": "fast" in the Messages API request, no beta header. The response's usage object includes a speed field telling you whether it ran fast or standard. Details in the API docs.
Conclusion
Claude Code fast mode left preview on Opus 5.5 with an honest pitch: double the price for up to 2.5x output speed, same model, same quality. What isn't obvious is where the math works out. It bills usage credits, not your plan, switching speeds breaks the cache, and the gain only shows up where text generation dominates the clock.
The practical rule: turn it on at the start of the session, for interactive work, and turn it off for anything that runs on its own.
If you use Claude Code headless to orchestrate tasks, see how to set that up properly in Claude Code headless: how claude -p becomes an agent orchestrated by your code.
{AI Engineer} — apaixonado por Laravel, arquitetura de software e construir produtos com impacto. Compartilho aqui tutoriais, descobertas e reflexões sobre o dia a dia de engenharia.
There is no shortage of content. What is missing is someone to untangle it: what matters now is how to implement it the right way. In the Clã you get that live, every week, with people who have already filtered out the noise.
Join the Clã