Claude Code fast mode: what /fast actually switches (2026)

Quick answer

I turned on Claude Code's fast mode on 13 September 2026, expecting a speed dial. It is not a dial. It is a mode, and it has three behaviours worth knowing before you type /fast.

The expensive moment is the first toggle in a conversation, not the hour you spend in it. The toggle moves your model one way: turning fast mode on can switch you to Opus, and turning it off leaves you there. And asking for fast is not the same as getting fast, because there are at least four documented paths where the request comes back at standard speed. On the API the response tells you which one you got, in usage.speed. In the CLI you get a small ↯ icon and a confirmation line.

None of that is about the price. The price will change, because fast mode is a research preview and Anthropic says so. The mechanics below are what stay true.

The moment

Tuesday, mid-refactor, about ninety minutes into a session. I wanted the loop tighter, so I typed /fast and got on with it.

Then I went and read the reference, which is the wrong order and the reason this post exists.

Everything below is read from Anthropic's Claude Code fast mode reference and its API fast mode reference on 13 September 2026, with the version numbers those pages give. I have flagged what I checked on a running install and what I am repeating from the documentation.

Finding 1: the expensive moment is the first toggle, not the hour

This is the one I got wrong, and I got it wrong in the most expensive direction.

My model was "turn it on when I need speed, turn it off when I do not". That treats fast mode as a per-turn setting. It is not. Here is the sentence that matters, from the cost tradeoff section:

Anthropic's fast mode reference, verbatim: "The first time you enable fast mode in a conversation, you pay the full fast mode uncached input token price for the entire conversation context."

Your conversation context is an input. Switching speed means it is no longer a cached input. So the first fast request re-reads everything you have said so far, at fast mode rates, uncached. Ninety minutes in, that is ninety minutes of accumulated context.

The API reference gives the mechanism underneath: "Switching between fast and standard speed invalidates the prompt cache. Requests at different speeds do not share cached prefixes." Fast and standard keep separate cache lineages. Crossing between them is a miss by construction.

There is a genuine mercy in it, and it is the half nobody mentions. The charge applies once per conversation. Toggling off and back on later does not repeat it. So the instinct "I will flick it off to save money and flick it back when I need it" is not the disaster it sounds like, as long as the conversation is the same one.

The rule that falls out is simple and it is the opposite of what I did:

Decide at the start of the session, not in the middle of it.

Finding 2: the toggle moves your model one way

/fast is documented as a speed toggle. It is also, silently, a model switch, and the switch is asymmetric.

Turn it on from a model that does not support fast mode and Claude Code moves you to Opus. That part is announced. Turn it off again and, in the reference's own words, "you remain on Opus. To switch to a different model, use /model."

So a round trip through /fast is not a round trip. You leave on Sonnet and come back on Opus, still paying Opus rates, standard speed. Nothing is broken, nothing warns you, and unless you notice the model line in /status you will not catch it.

The stickiness runs the other way too. Fast mode you turn on in an interactive session persists across sessions by default, and switching back to a supported Opus model turns it on again if your saved preference is on. A preference that survives a restart plus a toggle that moves your model is a combination worth being deliberate about.

If you run several sessions at once, there is a setting for exactly this:

{
  "fastModePerSessionOptIn": true
}

That makes every session start with fast mode off, and it keeps your saved preference intact, so removing the setting restores the old behaviour. It goes in any settings file. I put it in mine after writing finding 1.

There is also a hard off switch, CLAUDE_CODE_DISABLE_FAST_MODE=1, which is a different tool for a different job.

Finding 3: two unsupported models, two opposite failures

Fast mode is supported on Opus 5 and Opus 4.8. It is not supported on Sonnet, on Haiku, or on the two Opus versions immediately behind. So far, so ordinary.

What is not ordinary is that the two unsupported Opus versions fail in opposite ways on the API:

Opus 4.7 is the loud failure. The API rejects it and, per the reference, the requests do not fall back. Opus 4.6 is the quiet one: the request goes through, you are billed standard rates rather than fast mode rates, and the only thing that tells you is the speed field on the response.

The quiet failure is the better outcome commercially, since you are not overcharged. It is the worse outcome operationally, because a batch job can run for a week at standard speed while you believe it is running fast.

This is also where the third-party write-ups have drifted. Fast mode for Opus 4.7 was deprecated on 25 June 2026 and removed on 24 July 2026, and the CLI default has moved twice: Opus 4.7 on v2.1.142 through v2.1.153, Opus 4.8 on v2.1.154 through v2.1.218, Opus 5 from v2.1.219. Several explainers still ranking on page one list 4.6 and 4.7 among the supported models. One of those two now errors and the other silently does nothing. If you took a model list from a blog post this summer, re-read it against the reference.

So on the API the verification is one field:

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    speed="fast",
    betas=["fast-mode-2026-02-01"],
    messages=[{"role": "user", "content": "Hello"}],
)

print(response.usage.speed)   # "fast" or "standard"

In the CLI the equivalent is less precise but it is there: the ↯ icon next to the prompt, and running /fast again to have it report the current state back at you.

Finding 4: the availability check does not go through your gateway

This is the finding I would not have guessed, and it is the one that will waste an afternoon.

Before offering fast mode, Claude Code checks whether your organization has it, with a request directly to api.anthropic.com. That check does not follow ANTHROPIC_BASE_URL. It does honour a configured HTTP proxy, but it does not route through your LLM gateway.

Sit with that for a second. If your network sends Claude traffic through a gateway and blocks direct egress, then inference works perfectly and the availability check fails. You get this, from the reference:

Reported message, verbatim: "Fast mode unavailable due to network connectivity issues"

and your requests quietly run at standard speed, even though your organization has fast mode enabled. A check that succeeded once keeps working from its cached result, so this mostly bites new installations, which is a nasty shape: it works for the team that set it up and fails for the person who joins in October.

The same message appears on a perfectly open network if the check reaches Anthropic but presents a credential Anthropic rejects, which is what happens when a gateway-issued key sits in ANTHROPIC_API_KEY or comes from an apiKeyHelper.

Now the part that actually costs the afternoon. There are two skip variables and they are not interchangeable:

# the check FAILED: connection refused, or Anthropic rejected a gateway credential
export CLAUDE_CODE_SKIP_FAST_MODE_NETWORK_ERRORS=1

# the check was INTERCEPTED and answered by something that is not Anthropic
export CLAUDE_CODE_SKIP_FAST_MODE_ORG_CHECK=1

The first one treats a failed check as available, and still honours a genuine "disabled by your organization" response. The second skips the check entirely.

Pick by reading the message, because two gateway setups report "Fast mode has been disabled by your organization" when your organization has done nothing of the sort. A session authenticating with ANTHROPIC_AUTH_TOKEN alone never sends the check at all. And a TLS-inspecting proxy that answers the check with its own HTTP 200 block page gets read as a response saying fast mode is off. Both of those need the org-check variable. The network-errors variable does nothing for either, because it only bypasses checks that failed, and both of these produced a successful-looking answer.

An error message naming the wrong cause is the most expensive kind, and this one names your organization when the culprit is your proxy.

Finding 5: rate limit and empty credits are not the same failure

They look identical from the chair. They are not.

Fast mode has its own rate limit pool, separate from standard Opus, and all supported Opus models draw from the same one. Hit it and fast mode falls back to standard speed, the ↯ icon turns gray to show cooldown, you keep working, and fast mode re-enables itself when the cooldown expires.

Run out of usage credits and there is no cooldown at all. Claude Code retries each rejected request at standard speed and you keep working, but what happens to the mode depends on where you are:

Same symptom, opposite recovery, and the split runs along session type. Your saved preference is untouched either way, so /fast brings it back in the interactive case. The non-interactive notification arrives as a system message with subtype notification on the stream, once per turn, and needs v2.1.221 or later.

Worth knowing alongside it: on a subscription plan, fast mode is billed from usage credits only and is not included in your plan's rate limits, and it draws from credits even when you have plan usage remaining. Usage credits have to be turned on at all, or /fast simply reports that it requires them.

Finding 6: fast mode is not low effort, and headless is a different contract

Two smaller things that stop a wrong mental model forming.

Fast mode and effort level both make responses arrive sooner and they are not the same lever. Fast mode keeps the model and its quality and buys latency with money. A lower effort level buys speed with thinking, which the reference is candid about: "potentially lower quality on complex tasks". They compose, if what you want is speed on something straightforward. I wrote about which model you actually end up on in a separate log on model precedence, and the same care applies here.

The second thing is that headless is not the CLI with a flag. In non-interactive mode, /fast only works in a session that was launched with fast mode already in its settings:

claude -p --settings '{"fastMode": true}' "refactor this module"

The toggle then applies to that session only and is not saved as your default. In any other non-interactive session, the command reports that fast mode is not available. Which is a sane design for CI, and a surprise if you assumed the interactive behaviour carried over.

While we are on CI: the API reference lists fast mode as unavailable with the Batch API and unavailable with a Priority Tier commitment, and unavailable on Amazon Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS. If your pipeline runs on any of those, this whole post is theoretical for you.

What I actually set

After all of that, three lines and one habit.

{
  "fastModePerSessionOptIn": true
}

Every session starts cold, so the first toggle is always a decision I made rather than one I inherited from Thursday.

The habit is to toggle at the start of a session or not at all. Interactive iteration and live debugging get it. Long autonomous runs and anything in a pipeline do not, which matches what the reference recommends and, more usefully, matches where the first-toggle reprice does the least damage.

And on the API side I now log usage.speed alongside token counts, next to the cost column I set up when I was reading ccusage. It is one field and it is the only thing that distinguishes "I asked for fast" from "I got fast".

On price, because it would be strange to omit it: fast mode is 10 dollars per million input tokens and 50 per million output on Opus 5 and Opus 4.8 as documented on 13 September 2026, flat across the full context window, with prompt caching and data residency multipliers stacking on top. That number is in a research preview and Anthropic states plainly that pricing and availability may change. Do not build a spreadsheet on it. Build the habit instead.

What I did not verify

This is a documentation read plus a single-machine check that /fast toggles, reports its state, and shows the icon. I did not measure output tokens per second before and after, so the 2.5x figure is Anthropic's claim and not my measurement. I did not reproduce the Opus 4.6 silent-standard behaviour, because I have no reason to send fast requests to a model that does not support it. I did not test the gateway cases at all, since I have no LLM gateway in front of this machine, and the two skip variables are the part of this post I am most repeating rather than reporting.

The version-gated claims carry their versions because the reference gives them: the Opus 5 default from v2.1.219, the Opus 4.7 switch fix at v2.1.221, and the non-interactive credit notification at v2.1.221 or later.

If you take one thing: decide about fast mode when you open the session, and check usage.speed rather than trusting that asking for fast means getting it.

Postscript: I have now read the cost tradeoff section more carefully than I read my own last invoice, which is a sentence about me and not about Anthropic.