Claude Opus 4.8 Fast Mode Ends Nov 30: Migrate to Opus 5.5

Claude Opus 4.8 fast mode is deprecated. Migrate requests combining claude-opus-4-8 and speed: "fast" to claude-opus-5-5 before November 30, 2026. After removal, the old combination will return an error without automatically falling back to standard speed.

Anthropic announced the deadline in its October 30 release notes. The Claude Code v2.1.316 release explicitly confirms the absence of automatic fallback.

This change removes a speed option. As of 2026-11-02, the model lifecycle table still lists claude-opus-4-8 as Active. Its tentative retirement is no sooner than May 28, 2027. If you must retain that model, remove the fast setting and validate standard-speed requests.

The migration below targets the first-party Messages API. It also covers the settings that Claude Code users should check.

1. Find affected requests in code and deployed configuration

Find the model and speed settings separately, then trace where your application combines them. They may come from different files, environment variables, or gateway rules.

Run this candidate search from your repository root in Bash, with ripgrep installed:

rg -l --hidden --no-ignore \
  -g '!.git' \
  -g '!node_modules' \
  -g '!.venv' \
  -e 'claude-opus-4-8' \
  -e 'fast-mode-2026-02-01' \
  -e 'fastMode' \
  -e 'speed' .

The command lists filenames rather than configuration contents. It includes hidden and ignored files, which can contain local overrides. Each match needs inspection; a generic speed setting may have another purpose.

Also inspect configuration outside the repository:

• Deployment variables and CI job settings.
• Agent model defaults and fallback model lists.
• Gateway model mappings and request transformations.
• Claude Code user, project, and managed settings.

Confirm the final outbound request contains both the old model ID and speed: "fast". A model-only usage report cannot establish whether a request used fast mode.

For each affected service, record its owner, configuration source, requested model, requested speed, and rollback choice. Keep credentials and prompt contents out of that audit.

2. Change the model and review incompatible settings

For Opus 5.5, retain speed: "fast" and remove the beta token used solely for fast mode. Anthropic’s Opus 5.5 feature documentation explicitly says this model does not need that beta header.

If anthropic-beta contains several feature tokens, remove only fast-mode-2026-02-01. Preserve tokens required by other features.

Review these settings before sending an existing workload to the new model:

Setting or behavior	Opus 5.5 action
model	Set claude-opus-5-5.
speed	Keep "fast" when fast mode is required.
thinking	Omit it or use {"type":"adaptive"}. Disabled thinking and manual enabled budgets are rejected.
tool_choice	Use {"type":"auto"} or {"type":"none"}. Forced any and named tool choices are rejected.
temperature, top_p, top_k	Omit them.
Assistant prefill	Remove a partial assistant message used to start the next answer.
Response parsing	Select text blocks by type; do not assume content[0].text contains the answer.

These are request checks from the Opus 5.5 migration guide. Some restrictions already apply to earlier models. Shared request builders can still reintroduce them during migration.

If your application requires a particular tool call, changing forced tool choice to auto changes that contract. Update the application’s validation and test that path before rollout.

Opus 5.5 always enables adaptive thinking. Revisit max_tokens, because thinking and visible text share that allowance. Use output_config.effort to control thinking depth.

For tool loops, preserve complete assistant messages, including thinking blocks, when returning tool results. Filtering text for display must not alter the conversation you send back. Applications that rewrite conversation history or use computer tools should also review the migration guide’s dedicated checks.

3. Send one request and verify the returned speed

Verify usage.speed in a successful response before moving production traffic. The request field records what you asked for; the response field records what ran.

You need Bash, jq, and a curl version supporting --fail-with-body. Use a first-party Claude API key with access to fast mode. As of 2026-11-02, Opus 5.5 has default fast-mode limits in the Start, Build, and Scale tiers. Evaluation organizations must move to an eligible tier.

This example uses the current Messages API request format. It sends a non-streaming request, saves the response, checks it, and prints the text:

read -rs ANTHROPIC_API_KEY && export ANTHROPIC_API_KEY

curl --silent --show-error --fail-with-body \
  --max-time 600 \
  --dump-header fast-headers.txt \
  --output fast-response.json \
  https://api.anthropic.com/v1/messages \
  -H "Authorization: Bearer $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2026-10-21" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "claude-opus-5-5",
    "max_tokens": 4096,
    "speed": "fast",
    "stream": false,
    "output_config": {"effort": "low"},
    "messages": [
      {
        "role": "user",
        "content": "Explain a cache hit in one sentence."
      }
    ]
  }' &&
jq -e '
  .type == "message"
  and .model == "claude-opus-5-5"
  and .usage.speed == "fast"
  and .stop_reason == "end_turn"
  and any(
    .content[]?;
    .type == "text" and (.text | length > 0)
  )
' fast-response.json &&
jq -r '.content[] | select(.type == "text") | .text' fast-response.json

The expected check prints true, followed by the model’s answer. This is an acceptance condition, not a recorded execution result.

The && operators prevent a failed request from reaching the success checks. The example’s 4096 allowance and low effort are choices for this small test. They are not fast-mode requirements.

The example uses anthropic-version: 2026-10-21. Review the separate API-version migration before changing that header in an existing integration.

If curl fails, inspect its error and the newly written response body. If validation fails after a successful request, inspect model, usage.speed, stop_reason, and content.

A response can use fast mode but still reach max_tokens. Follow the stop-reason guidance, then adjust the output allowance or effort. Missing or "standard" speed data does not pass this fast-mode check.

As of 2026-11-02, BetterToken lists both claude-opus-4-8 and claude-opus-5-5. Its Messages reference documents https://www.bettertoken.ai/v1/messages. For that route, confirm fast-mode forwarding, returned usage.speed, and billing before migration. Use its documented authentication; a model listing alone does not establish fast-mode support.

4. Handle capacity errors separately from migration errors

Use dedicated fast-mode limits to plan concurrency. Standard Opus capacity does not describe the fast-mode pool.

The rate-limit documentation directs you to your organization’s Console limits page for actual allowances. Do not assume an Opus 4.8 concurrency setting transfers unchanged to Opus 5.5.

Inspect the saved response headers for anthropic-fast-input-tokens-remaining and anthropic-fast-output-tokens-remaining. They help distinguish input-token pressure from output-token pressure.

Choose an explicit response to each failure:

• Fast-mode 429 with retry-after: wait for the indicated delay, or retry without speed: "fast" if standard speed is acceptable.
• A 429 caused by a spend cap: resolve the cap. Changing speed does not restore an exhausted budget.
• 529 overload: use bounded retries and backoff. Do not assume another speed will succeed.
• An invalid parameter or the removed Opus 4.8 fast configuration: fix the request. Repeatedly submitting it does not complete the migration.

Anthropic documents application-controlled standard-speed fallback for fast-mode rate-limit errors. When you choose that path, verify the fallback response reports "standard".

Keep retry limits in one layer where possible. A wrapper retry loop around an SDK’s own retries can multiply requests and delays. The guide to safe Retry-After handling and exponential backoff covers that implementation.

5. Compare the same token workload

Opus 5.5 has lower published fast-mode token rates than Opus 4.8. It still costs more per token than Opus 5.5 at standard speed.

These are first-party Claude API rates in USD, as of 2026-11-02. MTok means one million tokens.

Configuration	Input per MTok	Output per MTok
Opus 4.8 fast	$10	$50
Opus 5.5 fast	$8	$40
Opus 5.5 standard	$4	$20

The fast rates come from Anthropic’s pricing table. Standard rates are also listed on the Opus 5.5 model page.

For an estimated workload of 1 MTok input and 0.2 MTok total output, the token charges are:

Opus 4.8 fast:     1 × $10 + 0.2 × $50 = $20
Opus 5.5 fast:     1 ×  $8 + 0.2 × $40 = $16
Opus 5.5 standard: 1 ×  $4 + 0.2 × $20 =  $8

Fast-to-fast reduction at fixed token usage:
($20 - $16) / $20 = 20%

This estimate assumes uncached input, no paid server tools, and no data-residency premium. It excludes taxes, credits, and account-specific discounts. Caching and residency modifiers need their own calculation.

The 20% result applies to fixed token usage. It does not establish a 20% reduction in the cost of completing your task. Opus 5.5’s thinking tokens are billed as output, including thinking that is not displayed. A workload previously run without thinking can therefore produce a different output-token total.

Measure accepted results, token charges, retries, and elapsed time on representative tasks. Keep fast mode where faster generation materially improves the user experience. Test standard speed first for background jobs whose completion time is dominated by tools or external services.

6. Update Claude Code’s model selection and fast setting

Select Opus 5.5 explicitly, then check the fast toggle. Updating Claude Code alone does not prove that a saved model override has changed.

The model configuration documentation requires Claude Code v2.1.280 or later for Opus 5.5.

For a native installation, run this in Bash:

claude update
claude --version
claude

If you installed through a package manager, use its update command from the setup documentation.

Inside the interactive Claude Code session, run:

/model claude-opus-5-5
/fast
/status

At /fast, press Space if you need to change the toggle, then Enter to confirm. The documented enabled state shows Fast mode ON and the ↯ icon. Use /status to inspect the selected model.

Check model overrides in ~/.claude/settings.json, .claude/settings.json, and .claude/settings.local.json. Also inspect ANTHROPIC_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL, launch flags, and managed settings. Change existing keys without replacing the entire settings file.

Restart once and verify the model again. A resumed session or higher-priority configuration can retain an earlier selection.

Claude Code’s fast-mode behavior includes automatic standard-speed fallback during fast-mode rate-limit cooldowns. That behavior does not override the removal notice for Opus 4.8 fast requests.

If an account limit blocks the change, first distinguish Claude Code subscription limits from API 429 errors.

7. Roll out with a usable rollback

Move a small portion of traffic only after the request check and your application’s acceptance checks pass.

Include a normal text request, a representative tool interaction if your app uses tools, and a task near your usual output allowance. Compare the new model’s usable results with the current configuration. Watch speed verification, error counts, token charges, and total completion time.

Keep a previously validated standard-speed configuration available for rollback. After November 30, restoring claude-opus-4-8 with speed: "fast" is not a usable recovery path.

Complete the migration by checking deployed requests again. The final condition is that no production route can still assemble the removed model-and-speed combination.