AI
Claude Code Fast Mode and Effort Levels: Speed vs Cost
August 202612 min read
A high-speed configuration for Claude Opus that makes responses up to two and a half times faster at a higher price per token. It is not a different model and there is no quality trade — the same Opus runs with an API configuration that prioritises speed over cost efficiency. It is supported on Opus 5 and Opus 4.8 only.
The first time you enable it in a conversation, you pay the full fast-mode uncached input price for the entire existing context. The deeper into the conversation you are, the more that costs. It applies once per conversation, so toggling off and on again does not repeat it — enable it at the start of a session instead.
Fast mode gives the same model quality at lower latency and higher cost. A lower effort level means less thinking time, which is faster and cheaper but can reduce quality on complex tasks. They combine: fast mode with a low effort level is the fastest configuration for straightforward work.
Most often the availability check. Claude Code checks fast mode with a request straight to the Anthropic API, and that request does not follow a configured base URL, so a network that routes model traffic through a gateway and blocks direct egress fails the check while inference still works. Two environment variables bypass the check in different ways.
No. On a subscription plan, fast mode bills from usage credits and is not included in your plan's rate limits, and it draws from those credits even when plan usage remains. Usage credits must be turned on before it will work, and on Team and Enterprise an Owner must enable fast mode for the organisation first.
Key Takeaway
Fast mode is not a different model. It runs Claude Opus with an API configuration that prioritises speed over cost efficiency — up to two and a half times faster, at ten dollars per million input tokens and fifty per million output. Identical quality, higher price. Effort level is the other lever, and it works in the opposite direction.
I turned fast mode on forty minutes into a debugging session, watched the responses get noticeably quicker, and then found a larger bill than I expected for what felt like a small change. The speed was real. What I had missed was that switching on mid-conversation charges the fast-mode uncached input price for the entire conversation so far, and by minute forty that conversation was not small.
That is the single most useful thing to know about this feature, and it is a one-line fix: turn it on at the start of a session, not in the middle. This post covers what fast mode actually is, how to toggle and pin it, that cost mechanism, how it differs from lowering effort, the requirements that block it, the availability check that fails behind a gateway, and what happens at a rate limit.
Fast mode uses Claude Opus with an API configuration that trades cost efficiency for latency. You get identical quality and capabilities with faster responses — it is not a smaller model, and it is not a quality trade. It is supported on Opus 5 and Opus 4.8, and on no other model: Sonnet, Haiku and the rest simply do not offer it.
It is also a research preview, which is worth stating plainly: the feature, the pricing and the availability may change based on feedback. Build a habit around it if it helps you, but do not build a process that assumes today's price is permanent.
The command toggles it and, run again, tells you the current state. Enabling it switches you to Opus if you were on something else, and disabling it leaves you on Opus rather than switching back. By default the preference persists across sessions, which is a sensible default for an individual and a poor one for an organisation paying for several concurrent sessions per person.
/fast # toggle on or off; run again to check state
# a small lightning icon sits by the prompt
# while it is on
{ "fastMode": true } # user settings
{ "fastModePerSessionOptIn": true } # every session starts OFF
# Non-interactive: /fast only works in a session launched with
# fast mode already in its settings, and applies to that session
# only — it is not saved as your default.
claude -p --settings '{"fastMode": true}' "…"
# It follows your model switches in BOTH directions:
# switch to a model without fast mode -> fast mode OFF
# switch back to a supported Opus -> ON again, if your
# saved preference is on
CLAUDE_CODE_DISABLE_FAST_MODE=1 # turn it off entirelyThe first time you enable fast mode in a conversation, you pay the full fast-mode uncached input price for the entire context that already exists. The deeper into the conversation you are, the more that costs. It applies once per conversation, so toggling off and on again later does not repeat it — but the first toggle is the expensive one, and it gets more expensive the longer you wait.
On a subscription plan, fast mode is billed from usage credits and is not included in your plan's rate limits — and it draws from those credits even when you still have plan usage remaining. Until usage credits are turned on, the command refuses with a message telling you so. On Team and Enterprise it is off entirely until an Owner enables it, and a Console organisation needs access provisioned first.
These are often confused because both make responses arrive sooner. They are not alternatives — they change different things, and the difference matters because one of them can cost you quality and the other cannot.
What each lever actually changes:
| Lever | Effect |
|---|---|
| Fast mode | Same model quality, lower latency, higher cost per token. Nothing about the reasoning changes |
| A lower effort level | Less thinking time, faster responses, potentially lower quality on complex tasks. This is a real trade |
| Both together | Maximum speed on straightforward work — the combination to reach for on mechanical tasks, and to avoid on hard ones |
The decision is simpler than it looks. Fast mode is for interactive work where you are waiting: rapid iteration, live debugging, a deadline. Standard speed is for long autonomous tasks, batch processing and CI pipelines, where nobody is watching the cursor and the latency costs nothing. If you would not notice the response arriving two seconds sooner, you are paying for nothing.
Fast mode needs every one of these, and each has its own refusal message so you can tell which one is blocking you:
This one is worth knowing because the message points at the network and the cause is often somewhere else. Claude Code checks fast-mode availability with a request straight to the Anthropic API, and that check does not follow your configured base URL — so a network that routes model traffic through a gateway and blocks direct egress fails the check while inference keeps working perfectly.
# Before offering fast mode, Claude Code checks availability with
# a request DIRECTLY to api.anthropic.com. That check does not
# follow ANTHROPIC_BASE_URL — so on a network that routes model
# traffic through a gateway and blocks direct egress, the check
# fails even though inference works fine.
#
# "Fast mode unavailable due to network connectivity issues"
# It DOES use a configured HTTP proxy, so a block only bites where
# api.anthropic.com is unreachable even through the proxy. A check
# that succeeded once keeps working from its cached result, which
# is why this mostly hits new installations.
CLAUDE_CODE_SKIP_FAST_MODE_NETWORK_ERRORS=1
# treat a FAILED check as available; still honours a real
# "disabled by your organization" answer
CLAUDE_CODE_SKIP_FAST_MODE_ORG_CHECK=1
# skip the check entirely — for a proxy that INTERCEPTS the
# request and answers with its own page, and for a session
# authenticating with a bearer token aloneThere are two escape hatches and they are not interchangeable. One treats a failed check as available, and is right when your network refuses the connection or when a gateway credential is rejected. The other skips the check entirely, and is the one you need when a proxy intercepts the request and answers with its own page, or when the session authenticates with a bearer token alone. Both affect only the client-side check — if your organisation really has fast mode disabled, the API refuses the requests regardless.
Fast mode has its own rate limit pool, shared across every supported Opus model. Hitting it does not stop your work: fast mode falls back to standard speed, the indicator greys out to show the cooldown, and it re-enables itself when the cooldown expires. You can also turn it off manually rather than waiting.
Running out of usage credits mid-session behaves differently and more gently. Each rejected request is retried at standard speed and pricing, so you keep working with no cooldown. In an interactive session you get a notification and fast mode turns off for the rest of the session, without changing your saved preference; in a streaming non-interactive run the same text arrives as a system notification once per turn.
Turn fast mode on at the start of a session or not at all, because the mid-conversation toggle is where the money goes. Use it when you are sitting there waiting and standard speed when you are not. And if you run an organisation where people keep several sessions open, set the per-session opt-in so each one starts off — a persistent preference multiplied by four concurrent sessions is a bill nobody decided to sign off on.
Sources & further reading