Claude Opus 4.8 Fast Mode Ends Nov. 30; 5.5 Fast Costs Less

If your latency-sensitive paths send speed: "fast" to claude-opus-4-8, the clock is running. Claude Opus 4.8 fast mode is removed on November 30, 2026, and after that those requests return an error. The replacement, Opus 5.5 fast mode, costs 20% less per token, but the swap takes more than a model ID change.

Claude Opus 4.8 fast mode: what Anthropic announced

The October 30 release note deprecates fast mode for Claude Opus 4.8 and sets removal for November 30, 2026. After that date, claude-opus-4-8 with speed: "fast" returns an error. Anthropic's advice is to move to Claude Opus 5.5.

Watch the failure mode. When fast mode for Opus 4.6 was removed in June, requests kept working at standard speed. Opus 4.7 went the other way: its fast requests now error, and 4.8 follows that pattern. A quiet slowdown becomes an outage if nobody migrates.

Fast mode on Opus 5.5 left research preview on October 15. It needs no beta header, and the Start, Build and Scale usage tiers get a default fast mode rate limit, so there is no access request. Evaluation-tier organizations can use it once they move up a tier.

Claude Opus 5.5 fast mode pricing next to Opus 4.8

| Model | Standard input / output | Fast input / output | | --- | --- | --- | | Claude Opus 4.8 | $5 / $25 | $10 / $50 | | Claude Opus 5.5 | $4 / $20 | $8 / $40 |

Prices are per million tokens, from the fast mode docs and the standard rate card. Fast mode is 2x standard on both models, so the 20% saving carries over. A workload of 10M input and 2M output tokens a day drops from $200 to $160 at fast rates. Prompt caching multipliers stack on top of both.

A caveat: price per token is not price per request. Opus 5.5 runs adaptive thinking on every request, and thinking tokens bill as output. Opus 4.8 ran without thinking unless you asked for it. Replay real traffic before you promise finance a 20% cut.

Migrate Claude Opus 4.8 requests that use the speed fast parameter

A typical 4.8 fast request today:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: fast-mode-2026-02-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-8",
    "max_tokens": 4096,
    "speed": "fast",
    "messages": [{"role": "user", "content": "Summarize this incident report"}]
  }'

The same request on Opus 5.5:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 8192,
    "speed": "fast",
    "output_config": {"effort": "high"},
    "messages": [{"role": "user", "content": "Summarize this incident report"}]
  }'

The beta header is gone, max_tokens is higher because it now covers thinking plus text, and effort is explicit. Opus 5.5 defaults to medium where 4.8 defaulted to high, so pin it and run an effort sweep on your own evals. The migration guide also lists requests that now fail with a 400: thinking: {"type": "disabled"} and forced tool choice (any or a named tool).

Responses can start with thinking blocks, so stop reading content[0].text:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=8192,
    speed="fast",
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "Summarize this incident report"}],
)

# thinking blocks can come first, so pick the text block by type
text = next(b.text for b in response.content if b.type == "text")
print(response.usage.speed)  # "fast" or "standard"

Log usage.speed on every call. It is the only way to see whether you actually got fast mode. On Managed Agents, set speed on the agent's model object instead: {"id": "claude-opus-5-5", "speed": "fast"}.

The prompt-cache miss when fast falls back to standard

The docs' fallback pattern catches the rate limit error and retries without speed. Falling back from fast to standard is a prompt cache miss: requests at different speeds do not share cached prefixes. During a fast mode 429, a large system prompt is processed from scratch at standard speed.

A second catch: that sample handler catches only the rate limit error. The docs describe the post-removal failure on 4.8 as just "an error", so a 429-only handler may not catch it. Fix the model, not the handler.

A few more limits from the docs:

• Opus 5.5 fast mode is listed on the Claude API, Claude Models on Google Cloud (Anthropic managed) and Microsoft Foundry. It does not work with the Batch API.
• Opus 5.5 does not support Priority Tier, and fast mode is not available with a Priority Tier commitment. Plan capacity separately.
• The minimum cacheable prompt drops to 512 tokens on 5.5, from 1,024 on 4.8, so shorter prompts can start caching.

What to do on Monday morning

Find every caller first:

grep -rnE "claude-opus-4-8|fast-mode-2026-02-01" \
  --include="*.py" --include="*.ts" --include="*.json" --include="*.yaml" .

Move one caller to claude-opus-5-5 behind a flag, run your evals at a fixed effort, and compare cost per request rather than per token. Then alert on usage.speed and error rates, and cut over well before November 30.

Pinned model IDs and preview flags are production dependencies with expiry dates, and a release note is the only warning before they turn into errors.