Claude Opus 4.8 fast mode ends November 30: Opus 5.5 is cheaper per token, not always per request

On October 30, Anthropic deprecated fast mode on Claude Opus 4.8. From November 30, 2026, a request to claude-opus-4-8 with speed: "fast" returns an error. The Claude Code v2.1.316 release notes spell out the part that matters for anyone counting on a graceful downgrade: the request does not fall back to standard Opus 4.8. It fails.

The model itself is not going anywhere. claude-opus-4-8 is listed as active, with retirement not sooner than May 28, 2027. What ends is one setting on it, and the official exit is Opus 5.5, whose fast mode is cheaper per token. Cheaper per token and cheaper per request are different claims, and on this move they can point in opposite directions.

What exactly stops working for Claude Opus 4.8 fast mode on November 30?

Only speed: "fast" on claude-opus-4-8. Standard-speed requests to the same model keep working, and so does fast mode on Opus 5.5 and, still in research preview, on Opus 5.

Fast mode on 4.8 was always a research preview behind the fast-mode-2026-02-01 beta header. Opus 5.5 left the preview on October 15: no header needed (sending it still works), and a default fast rate limit in the Start, Build and Scale usage tiers, so there is no access to request. Organizations on the Evaluation tier get it once they move up.

Opus 4.7 already went through this. Its fast mode was deprecated on June 25 and removed on July 24, and speed: "fast" on 4.7 now returns an error. Expect 4.8 to behave the same way on December 1.

How do you find the Claude Opus 4.8 fast mode calls you still make?

From three directions, because each one misses something. Your code shows where fast is requested, the response shows which speed you got, and the analytics API shows who is actually sending it, including the scripts you forgot about.

Start with the code. The setting is a literal or an SDK enum in most codebases, and the beta header is a good second marker, because Opus 5.5 no longer needs it. This catches the dict, YAML and JSON forms plus the Go, C# and Java enums:

grep -rnE "fast-mode-2026-02-01|speed[\"']?[[:space:]]*[:=][[:space:]]*[\"']?fast|Speed\.?(Fast|FAST)" \
  --include='*.py' --include='*.ts' --include='*.js' --include='*.go' --include='*.cs' \
  --include='*.java' --include='*.json' --include='*.yaml' --include='*.yml' --include='*.toml' .

That finds the requests that say “fast”. It does not find the model. A model ID that comes from an environment variable or a config service can turn a fast request on 4.8 into a fast request on 5.5 without a code change, and the other way round, so check where the model name is resolved too.

At runtime, every response carries usage.speed, either "fast" or "standard". Log it next to the model. A fast request that comes back as a 429 or 529 has hit the fast rate limit or capacity. The model is fine, and after November 30 the same request on 4.8 fails differently.

For the organization as a whole, the Usage and Cost Analytics API (beta since October 29, and separate from the older Usage and Cost API) has a speed dimension and a speeds[] filter. It needs admin-level credentials, so individual accounts can’t use it; this Console example uses an Admin API key. It returns the API keys and products that sent fast traffic to 4.8 over the 30 days before publication (move the dates to your own window, at most 31 days per request):

curl --globoff "https://api.anthropic.com/v1/organizations/analytics/usage?\
starting_at=2026-10-10T00:00:00Z&\
ending_at=2026-11-09T00:00:00Z&\
models[]=claude-opus-4-8&\
speeds[]=fast&\
group_by[]=api_key_id&\
group_by[]=product&\
limit=1000" \
  -H "anthropic-version: 2026-10-21" \
  -H "anthropic-beta: analytics-usage-cost-2026-08-24" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY"

That is the first page. If the response says has_more: true, pass its next_page back as page until it doesn’t.

Two traps in reading the answer. An empty result does not mean you are clean: in this API an unknown or misspelled models[] value matches nothing instead of returning an error, so a typo produces exactly the result you were hoping for. Run the same query once with group_by[]=model and no filters, and copy the model name from a row that comes back.

And the data is not live. It typically refreshes within 4 hours and can take up to 24, and everything after data_refreshed_at is missing or partial. So to confirm a migration worked, query the hours after your deploy only once data_refreshed_at has moved past them; an empty window that the data doesn’t cover yet proves nothing. In the Console, the Usage and Cost pages offer the same split under Group by, as “Speed (research preview)”.

Once you have the list of callers, the question for each one is not whether 5.5 fast is cheaper per token. It is, on every line. The question is what each request writes.

What does Claude Opus 5.5 fast mode cost compared with Opus 4.8 fast mode?

Less, on every row of the price list. Fast mode is priced at twice the standard rate on both models, and Opus 5.5’s standard rate is lower, so the fast price drops from $10 input and $50 output per million tokens to $8 and $40.

The cache lines move more than that. Prompt caching multipliers apply on top of fast pricing, and Opus 5.5 reads its cache at 0.05x the input price where 4.8 reads at 0.1x. Applying the published multipliers, per million tokens:

So a 4.8 fast workload moved to 5.5 fast saves 20% on input and output and 60% on cache reads, token for token. Look at the third row too. Apart from cache reads, Opus 5.5 fast charges more per token than Opus 4.8 at standard speed, which matters for the choice further down.

Why can the same request cost more on Claude Opus 5.5 fast mode?

Because it is no longer the same request. On Opus 4.8, a request without a thinking field runs without thinking. On Opus 5.5, thinking is always on, thinking: {"type": "disabled"} returns a 400, and thinking tokens are billed as output tokens even when the thinking text is not returned to you. A fast 4.8 call that produced only its answer now produces the answer plus whatever the model spent thinking, all at $40 per million.

Output got 20% cheaper per token, so a request can produce up to 25% more output tokens ($50 / $40) before its output line costs more than it did on 4.8 fast. That is the output line only. The whole request also carries input, cache writes and cache reads, and all three got cheaper. My read: answer-heavy calls with short prompts that ran without thinking are the ones most likely to cross the line, and long cached agent sessions have the most discount to absorb it. Neither is a guarantee. Anthropic’s own checklist says to re-baseline cost at the effort level you pick, and the number to compare is total cost per request or per task, from your logs.

Two controls decide it. output_config.effort is now the only lever on thinking depth, and the Opus 5.5 default is medium; where you used to turn thinking off to save tokens, the migration guide says to pick a lower level, and its example uses low. And max_tokens now covers thinking plus text, so a limit tuned for no-thinking answers can start ending in stop_reason: "max_tokens". Both come back as a 200, the same family of quiet breaks the Opus 5.5 upgrade brought from Opus 5, and that post covers the rest of the move: forced tool_choice and disabled thinking now return 400s, and thinking blocks have to go back unmodified in tool loops.

Is Claude Opus 5.5 fast mode actually faster for your request?

Faster at writing, not necessarily faster to start. Fast mode raises output tokens per second, up to 2.5x, and the docs say the gain is focused there, not on time to first token.

On 4.8 without thinking, the first token was answer text. On 5.5 the response can start with thinking blocks, which arrive with an empty thinking field at the default display: "omitted". For a user watching a stream, that is a pause before any visible text. Faster generation may shorten the thinking phase too, but nothing in the docs promises it, so 5.5 fast can be faster per token and slower to the first visible word, both at once.

Measure the time to the first non-empty text delta in the stream before and after. Tokens per second will have gone up either way; it is not the number your user waits on. If the first visible word got slower, lower the effort first. If the work needs the thinking but users need to see progress, set display: "summarized" so the pause has something in it. Claude Code’s docs suggest the same pairing from the other side: fast mode plus a lower effort level for maximum speed on simple tasks.

When Claude fast mode hits its rate limit, should you fall back to standard speed or wait?

For long cached contexts, wait. This is the other place the per-request bill goes up, and it sits in your error handler, not in the model. Fast mode has its own rate limit, separate from standard Opus, reported in anthropic-fast-input-tokens-* and anthropic-fast-output-tokens-* response headers. When you exceed it, the API returns a 429 with a retry-after header, and the SDKs retry twice by default. The docs describe the delay as typically short, because fast capacity replenishes continuously.

The docs also show a fallback: catch the 429, drop speed, resend at standard speed. It works. The note next to it is the whole cost story: requests at different speeds do not share cached prefixes, so the fallback is a prompt cache miss. Per the caching docs, a speed change invalidates the system and message caches; only the tool definitions stay cached.

Put numbers on it for an agent session with a 200,000-token cached prefix on Opus 5.5, assuming the whole prefix sits in system and messages. A warm fast read of it costs about $0.08. Falling back writes it to the standard cache for $1.00. If the fast entry has expired by the time you return (five minutes by default), the next fast request writes it again, $2.00. One trip out and back costs between $1 and $3 in cache writes, where staying on fast would have cost $0.08 per warm read. For short prompts the fallback is cheap and fine. For long ones, wait out the retry-after unless a user-facing deadline can’t take the delay.

Model choice works the same way. Each model has its own cache, so the first 5.5 request in a long conversation reads the whole context uncached. Switch at a session boundary. Halfway through a 300k-token run, the first 5.5 request rewrites all of it. And if your cache reads collapse after a switch with no change to the prompt, remember that speed is one more parameter outside the prompt text, the kind of miss cache diagnostics won’t find by reading the prompt.

What do Claude Code users need to do before November 30?

One of two commands. To keep fast mode, switch to Opus 5.5 explicitly with /model; it needs Claude Code v2.1.280 or later, and fast mode stays on after the switch. Turning on /fast is not a migration: on a model that supports fast mode, it keeps your current model, and until November 30 that includes 4.8. To stay on 4.8, run /fast off. Fast mode on Opus 4.8 with nothing changed is the one combination that breaks.

Four more details from the docs. If fast mode has to switch your model, Opus 5.5 is the default it picks in v2.1.280 and later. On Pro, Max, Ultra, Team and Enterprise plans, fast mode is paid from usage credits only and never comes out of the plan’s included usage, even when usage is left. Claude Code offers fast mode only through the Anthropic API and subscriptions, not on Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry or Claude Platform on AWS. And when you hit the fast rate limit inside Claude Code, it falls back to standard speed on its own, grays out the ↯ icon and re-enables fast after a cooldown. The icon tells you the fallback happened. It doesn’t tell you that each switch re-reads the conversation uncached, the miss from the previous section, and on a subscription those standard-speed turns are plan usage, not credits.

Is staying on Claude Opus 4.8 at standard speed a reasonable choice?

Yes, if speed was never what you needed from it. Opus 4.8 at standard speed costs less per token than Opus 5.5 fast on everything except cache reads ($5 and $25 against $8 and $40), it is not scheduled for retirement before May 2027, and it keeps things 5.5 dropped: thinking off by default, forced tool_choice, the computer_20251124 tool on the Claude API, and Priority Tier, which Opus 5.5 does not support at all. And there is a third option the deprecation notice doesn’t mention: Opus 5.5 at standard speed, $4 and $20, for anything that works on 5.5 and doesn’t need the speed.

The question I would ask of each fast call is why it was fast. If a person waits on the output, the speed was the point and the move is to 5.5 fast, with the effort and max_tokens checks above. If it runs in a pipeline or a batch where nobody watches, fast mode may have been a premium on nothing. Claude Code’s own docs list long autonomous tasks and CI as standard-mode work. The deprecation is a cheap moment to find out which of your fast calls were on purpose.

What should you change before Claude Opus 4.8 fast mode is removed?

In order of how much each one costs if you skip it:

1. Find every caller: grep for fast and the fast-mode-2026-02-01 header, trace where each model ID is resolved, and page through the analytics query after checking that the model name returns rows.
2. Give each caller a destination: Opus 5.5 fast where a person waits on the output, Opus 5.5 or 4.8 at standard speed where nobody does.
3. Decide what a fast 429 does: retry for long cached prompts, fall back only where the prompt is short or a deadline demands it.
4. On 5.5, set effort explicitly, raise max_tokens for thinking, and work through the 400s and the thinking-block rules from the migration guide.
5. Re-baseline on 5.5: total cost per request against 4.8 fast, and the time to the first visible text.
6. Switch models at a session boundary, and expect one cold cache per conversation when you do.

The error on December 1 is the easy part, because it arrives announced. The thinking tokens and the fallback cache writes come back as 200s and show up on the invoice.