Claude Opus 4.8 Fast Mode Ends Nov 30: What to Switch To

On October 30, 2026 Anthropic deprecated fast mode for Claude Opus 4.8 and set its removal for November 30, 2026. The consequence is specific: after removal, a request to claude-opus-4-8 that sets speed to fast returns an error. There is no fallback to standard speed, and the Claude Code changelog says the same for sessions that use fast mode on that model. Anthropic's named replacement is Claude Opus 5.5, where fast mode is generally available with no waitlist and priced at $8 per million input tokens and $40 per million output, against $10 and $50 on Opus 4.8.

One month is enough time if the callers are found in the first week. This post keeps to Anthropic's own wording on the deprecation, the pricing page's figures, and the migration guide's list of what else changes when a request moves from Opus 4.8 to Opus 5.5, because fast mode is not the only difference between the two. The Opus 5.5 launch itself, including standard pricing and benchmarks, is covered in our Opus 5.5 pricing and benchmarks post.

Three documents carry the notice, and they agree. The platform release notes entry dated October 30, 2026 reads: "We've deprecated fast mode for Claude Opus 4.8, with removal on November 30, 2026. After removal, requests to claude-opus-4-8 with speed: 'fast' will return an error. To continue using fast mode, migrate to Claude Opus 5.5." The fast-mode documentation page carries the same sentences as a warning in its availability section, with a link to the Opus 5.5 migration guide's section for Opus 4.8.

The third source is the Claude Code changelog for version 2.1.316, which adds the sentence a platform team most needs: "Deprecated fast mode for Opus 4.8 as of October 30, 2026; it will be removed on November 30, 2026. After removal, fast mode requests on Opus 4.8 return an error and do not fall back to standard Opus 4.8. Migrate to Opus 5.5 to keep the speedup." The no-fallback behaviour is the part to plan around. A request will not quietly slow down; it will fail.

For context, the fast-mode page describes the feature as delivering up to 2.5 times higher output tokens per second at premium pricing, opted into with speed set to fast on the request. On Opus 4.8 it has been in research preview behind the fast-mode-2026-02-01 beta header, which is why many integrations carry that header string somewhere in their configuration and why the header is a useful thing to search for.

The fast-mode page already documents what an error looks like for an unsupported model, because it is the existing behaviour for any model outside the supported list: requesting speed fast on a model that does not support fast mode returns an error, and so does exceeding fast mode's rate limits or capacity, with a 429 or 529. When a fast request succeeds, the response usage object carries a speed field reading fast. The page notes one historical exception: Claude Opus 4.6 accepts the header and runs at standard speed, reporting standard in usage.speed. The changelog is explicit that Opus 4.8 will not behave that way after November 30. It will error.

So the failure case is concrete. An agent loop that sets speed fast on claude-opus-4-8 and handles only rate-limit errors with a retry will, on December 1, retry an error that never clears. A pipeline with the SDK's default two retries will fail three times per request. Anthropic's own fallback pattern on the fast-mode page is to catch the rate-limit error and reissue without the speed field; that pattern, extended to the unsupported-model error, is the safety net to add before the date, and the model change is the fix.

It is worth being precise about scope, because a deprecation notice tends to be read as a model retirement. The release note, the fast-mode warning and the changelog all concern fast mode on Opus 4.8. None of the pages read on October 30, 2026 announces a retirement date for Claude Opus 4.8 itself. The pricing page still lists Opus 4.8 at $5 per million input tokens and $25 output at standard speed, with batch rates of $2.50 and $12.50, and the migration guide still describes it as a model that keeps Priority Tier, which Opus 5.5 does not support.

Fast mode on Claude Opus 5 is also unaffected by this notice. It remains in research preview behind the same beta header, with access through an account manager or a waitlist. The supported list on the fast-mode page after November 30 is therefore Opus 5.5 as generally available, and Opus 5 in research preview. A team that reads this notice as "Opus 4.8 is going away" and re-platforms everything is doing more than the notice asks; a team that reads it as "nothing changes until the model retires" will hit errors on December 1.

Anthropic's replacement is one model: Claude Opus 5.5. On the fast-mode page it is the only model where fast mode is listed as available rather than in research preview, it needs no beta header, and it has a default fast-mode rate limit in the Start, Build and Scale usage tiers, so no access request is needed. Organisations in the Evaluation tier can use it once they move to one of those tiers. It is also the only model whose fast mode is available beyond the first-party API, on Claude Models on Google Cloud under Anthropic management and on Claude in Microsoft Foundry for deployments hosted on Azure.

The prices come from Anthropic's pricing page (retrieved November 5, 2026) and are the same on the fast-mode page. Fast mode on Opus 5.5 is $8 per million input tokens and $40 per million output; on Opus 5 and Opus 4.8 it is $10 and $50. Fast-mode pricing applies across the full context window, including requests over 200,000 input tokens, and stacks with prompt-caching and data-residency multipliers. It is not available with the Batch API or with a Priority Tier commitment. For a workload that was paying Opus 4.8's fast rate, the move is a 20% reduction on both input and output at the fast tier, before any behavioural differences between the models are accounted for.

Read the standard rows as well as the fast ones. If the reason for fast mode was latency on an interactive product, Opus 5.5 fast at $8 and $40 is the like-for-like move. If the reason was throughput on a batch job that could tolerate standard speed, the deprecation is a prompt to test whether Opus 5.5 at standard speed, $4 and $20, meets the need at less than half the fast rate. The migration guide's note that Opus 5.5 does not support Priority Tier cuts the other way: a team on a Priority Tier commitment for Opus 4.8 cannot carry it to Opus 5.5 at all, and fast mode was never available with Priority Tier, so that team was not using fast mode on that commitment in the first place.

The release note's instruction to migrate links to the Opus 5.5 migration guide's section for Opus 4.8, and that section is short because it builds on the Opus 5 section. In the guide's own framing, Opus 4.8 behaves like Opus 5 in several respects, so the Opus 5 changes apply as written; then the Opus 4.8 section adds three. First, thinking runs on requests that omitted it: on Opus 4.8, thinking is off unless requested; on Opus 5.5, a request with no thinking field runs with adaptive thinking, and max_tokens becomes a hard limit on thinking plus response text, billed as output even when the thinking is not returned. Second, the prompt-caching minimum drops from 1,024 tokens on Opus 4.8 to 512 on Opus 5.5, so shorter prompts start creating cache entries with no code change. Third, Priority Tier is not supported on Opus 5.5, whereas Opus 4.8 keeps it.

The Opus 5 section the guide folds in carries the breaking changes: thinking cannot be disabled, so a thinking disabled request returns a 400; forced tool use is not supported; thinking blocks are tied to the model and the conversation; and some computer-use tool versions are not supported. For a fast-mode caller, the practical implication is that an agent loop tuned on Opus 4.8 with thinking off and a forced tool choice has two request-shape changes to make as well as the model string. We set out how to stage that kind of change in our guide to provider failover and safe retries; the same staging applies to a model swap within one vendor.

The notice is only hard to act on if the callers are unknown, and there are three places to look. In code, the strings to search for are the model ID claude-opus-4-8, the speed field, and the beta header value fast-mode-2026-02-01, which every Opus 4.8 fast request has had to send. In configuration, Claude Code settings and any gateway or router that sets a default model and speed. And in usage data, which is the only way to catch a caller that was not written by your team.

The usage data route is the one that became easier on October 29, the day before this notice. Anthropic's new Usage and Cost Analytics API groups by model and by speed, so a single request to the cost endpoint with group_by set to model and speed, over the last 31 days, lists every workspace, key or identity that has been billed at the fast tier on Opus 4.8. We walk through that API, its key types and its migration from the legacy reports in our post on the Usage and Cost Analytics API. For Claude Code specifically, the changelog's 2.1.316 entry is the signal that the client itself will surface the error; the fix there is the model setting, not the code.

Week one: inventory. Search the codebase and configuration for the three strings, query the cost endpoint grouped by model and speed for the last 31 days, and list every caller with its owner. Week two: safety net. Add the catch-and-reissue fallback around every fast request so that an unsupported-model error degrades to standard speed rather than failing the job. Week three: migrate. For each caller, change the model to Opus 5.5, remove the beta header, fix any thinking disabled or forced tool choice, re-tune max_tokens, and run the caller's own evaluation set at both speeds to decide whether fast is still needed. Week four: verify. Run the same cost query and confirm the Opus 4.8 fast row has gone to zero before November 30, then leave the fallback in place for the month after as insurance.

None of this needs a vendor conversation. Opus 5.5 fast mode is self-serve in the Start, Build and Scale tiers, the migration guide is public, and the error after November 30 is documented in advance. If you want help running the inventory and the evaluation across a larger estate, it is part of what our AI transformation engagements cover.