Article

Claude Opus 4.8 fast mode ends November 30

Choose between Opus 4.8 at standard speed and a move to Opus 5.5 before the November 30, 2026 cutoff, with pricing and migration checks.

Editorial illustration for Claude Opus 4.8 fast mode ends November 30: an arrow connects an old service to its replacement. Not documentary evidence.

Anthropic announced on October 30, 2026 that Claude Opus 4.8 fast mode will be removed on November 30. The deadline affects applications such as customer-facing assistants and workplace agents that explicitly use the faster setting. Requests left unchanged will fail after removal, according to Anthropic’s release notes.

The affected combination is the model claude-opus-4-8 with speed: "fast". This is not a shutdown of the whole model: Anthropic still lists Opus 4.8 as active, with retirement no earlier than May 28, 2027. That is an earliest-retirement boundary, not a scheduled shutdown date.

Teams can keep Opus 4.8 at standard speed or move to Opus 5.5. The practical choice is whether to preserve an existing model’s behavior or evaluate a different model while retaining the fast option.

Choose the change your workflow needs

  • Keep Opus 4.8 at standard speed. Consider this when the existing model meets your needs and a longer wait is acceptable. Anthropic documents removing the fast-speed setting to return to standard operation. This separates the immediate deadline from a model upgrade.

  • Move to Opus 5.5 fast mode. Evaluate this if faster output remains important. Budget time for the request and response changes below, not just a new model name.

  • Consider Opus 5.5 at standard speed. If you want the newer model but do not need premium output speed, include its standard configuration in the comparison.

For affected Claude API users, Opus 5.5 fast mode has default capacity limits in the Start, Build and Scale tiers; Evaluation-tier organizations must move to an eligible tier. It no longer needs the fast-mode beta header. See Anthropic’s availability and rate-limit guidance.

Anthropic describes the speed benefit as faster output generation, not a shorter wait for the first token. For a customer waiting on an agent, assess time to the first useful update and time to a completed task separately.

Compare the cost of completed work

These are Anthropic’s published base prices in US dollars per million tokens—the units used to meter input and generated output:

Configuration

Input

Output

Opus 4.8 fast — ending November 30

$10

$50

Opus 4.8 standard

$5

$25

Opus 5.5 fast

$8

$40

Opus 5.5 standard

$4

$20

Illustrative calculation, not a bill forecast: across many requests, assume one million uncached input tokens and 200,000 total output tokens, including thinking. The four configurations above cost $20, $10, $16 and $8 respectively. This excludes tools, caching, discounts, residency adjustments and taxes.

The fast-to-fast saving is 20% only if token volumes stay the same. With input fixed, another 100,000 output tokens on Opus 5.5 fast raises the example from $16 to $20, erasing that saving. Thinking tokens are charged even when their text is hidden, so visible answer length is not a sufficient cost measure.

A speed change also invalidates system and message caches. Allow for cache rebuilding when comparing spending during the switch.

A model switch needs more than a price comparison

For Claude Managed Agents, Anthropic’s migration guide says the model-name update is the only required integration change. That does not promise identical results or spending.

For direct Messages API integrations—the connection your application manages itself—the same guide identifies these checks:

  • Reasoning settings. Opus 5.5 always uses adaptive thinking, where the model decides how much reasoning to do, and defaults to medium effort. Opus 4.8 defaults to high effort and runs without thinking when that setting is omitted. Choose effort deliberately.

  • Rejected inputs. Opus 5.5 rejects disabled thinking and forced tool selection through tool_choice types any or tool. Manual thinking budgets, sampling controls and assistant prefills are also invalid, though those restrictions already apply to Opus 4.8. Review shared request builders as well as individual calls.

  • Response handling. Select visible text by block type, not its position. Preserve thinking blocks unchanged when returning tool results. The max_tokens limit covers reasoning and answer output together. Thinking documentation explains those requirements.

There is a user-visible change too: Opus 5.5 puts progress text between tool calls in thinking blocks, whose text is empty by default. Review any progress display that depends on those messages. Computer-use integrations also need to review the replacement for the older computer tool on affected platforms. Both are covered in Anthropic’s Opus 5.5 change notes.

Keep this model decision separate from a library or API-version upgrade. RohitAI’s guide to Claude API and SDK compatibility covers those distinct changes.

Make the switch before November 30

Ask the application owner to locate the effective model and speed settings in live services, shared wrappers, scheduled workers and managed-agent definitions. A setting added by a shared component matters just as much as one written directly into a request.

Before routing production traffic to a replacement, compare representative tasks in a development environment. Check whether each task finishes correctly, how long useful output takes, total duration, billed tokens and errors. Include tool-using conversations and the progress display, not just a single successful answer.

Fast mode has separate capacity limits and can return 429 or 529 errors. Build an explicit standard-speed fallback where appropriate. Do not assume a rate-limit handler will catch the retirement error: the removal notice does not specify its status code.

The November 30 notice gives no cutoff time or time zone, so complete the rollout beforehand. If your rollback uses Opus 4.8, prepare it at standard speed; restoring the withdrawn fast setting would not provide a working fallback after removal.