Claude Opus 5.5: Four Breaking API Changes and What They Mean for Your Routing Setup

Anthropic released Claude Opus 5.5 on September 22, 2026. The headline numbers — Fable 5.1-level performance, 40% lower total cost than Opus 5 — are real. But the migration guide is where the operator story lives, and it's denser than any recent Claude release: four breaking parameter changes, any one of which silently breaks an existing integration the moment you flip the model ID.

This piece goes through each change, what error it throws, what the fix looks like, and — where relevant — what it means for fallback routing and cross-provider behavior.

The cost math: 40% is a workload number, not a token price

Before the technical changes: let's make the pricing claim precise, because it's easy to misread.

The token prices dropped 20% versus Opus 5:

The 40% cost reduction Anthropic cites is for typical workloads, not token prices in isolation. The reason the number lands at 40% is that agentic and coding workloads are cache-read heavy — most tokens in a long coding session are prompt-cache reads, and those dropped 60%. If your workload has a high cache read ratio, 40% is plausible. If you're running short-context, low-cache calls, you'll see closer to 20%.

For routing policy: if you're on a cost-based fallback rule (route to Opus 5 when spend/hour exceeds a threshold), you'll want to recalibrate that threshold for Opus 5.5. The effective cost per task on agentic workloads shifted more than the per-token numbers suggest.

Breaking change 1: thinking cannot be disabled

On Opus 5.5, the thinking field is gone. Sending thinking: {type: "disabled"} or thinking: {type: "enabled", budget_tokens: N} returns a 400:

"thinking.type.disabled" is not supported for this model.
"thinking.type.enabled" is not supported for this model.

Thinking is always on and always adaptive. The control surface is the effort parameter, not thinking.

Before (Opus 5):

client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "disabled"},
    messages=[{"role": "user", "content": "..."}],
)

After (Opus 5.5):

client.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    output_config={"effort": "low"},   # low effort replaces disabled thinking
    messages=[{"role": "user", "content": "..."}],
)

The effort levels are low, medium (default), high, and max. Where you previously disabled thinking to save tokens on simpler prompts, use low. The thinking blocks will appear in responses; you need to select content by type and pass thinking blocks back unmodified when appending to multi-turn conversations.

Routing implication: if you have a gateway rule that injects thinking: {type: "disabled"} for cost control, that rule will 400 on Opus 5.5. The equivalent is output_config: {effort: "low"}. These are not the same parameter — you can't set one and have the other work.

Breaking change 2: forced tool_choice returns 400

tool_choice types any and tool are not supported:

tool_choice: type "tool" and "any" are not supported for this model.

This fires on both the inference endpoint and the token counting endpoint. If you force a specific tool to run by name, or use any to ensure at least one tool call, both patterns are broken.

Before (Opus 5):

client.messages.create(
    model="claude-opus-5",
    tools=tools,
    tool_choice={"type": "tool", "name": "get_weather"},
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
)

After (Opus 5.5):

client.messages.create(
    model="claude-opus-5-5",
    tools=[{**tool, "strict": True} for tool in tools],
    tool_choice={"type": "auto"},
    messages=[{
        "role": "user",
        "content": "What's the weather in Paris? Use the get_weather tool.",
    }],
)

The strict: True flag on each tool definition activates strict tool use: the model guarantees its input matches the tool's input_schema. Combined with explicit instruction in the prompt, this replaces most type: "tool" use cases. For cases where you used any to guarantee a structured response, structured outputs is the alternative.

Routing implication: any gateway middleware that normalizes tool_choice to any or tool for reliability — a common pattern for providers that previously required it — will need a model-aware branch for Opus 5.5.

Breaking change 3: thinking blocks don't cross model boundaries freely

This is the most subtle change for teams running multi-model fallback.

On the Claude API, thinking blocks produced by Opus 5.5 are readable by Claude Fable 5.1 and Claude Mythos 5.1. No other model reads them. Specifically: if a failover or fallback routes a conversation mid-session from Opus 5.5 to Opus 5, Sonnet 5, Haiku 4.5, or any non-Fable/Mythos model, those turns proceed without thinking context — there's no error, the blocks are silently dropped.

The reverse also has specific rules: Opus 5.5 reads thinking blocks from Opus 5 and earlier Opus, Sonnet, and Haiku models, but not from Fable or Mythos.

The compatibility matrix:

There's also an enforcement rule for append-only conversations: for accounts created on or after August 31, 2026, replaying a thinking block after an edit to system, tools, or earlier messages returns a 400. Claude Code, claude.ai, Claude Managed Agents, and the Claude Agent SDK already enforce this; direct API callers need to audit.

Routing implication: If your fallback chain is claude-opus-5-5 → claude-opus-5 → claude-sonnet-5, a mid-conversation failover drops thinking context starting at the second hop. Whether that's acceptable depends on your use case. For coding agents and document-analysis sessions, dropped thinking context typically degrades quality on the next turn. For simpler question-answer fallback, it may be fine.

If you need thinking-block continuity across failover, your fallback chain should be claude-opus-5-5 → claude-fable-5-1 or claude-opus-5-5 → claude-mythos-5-1. Both can consume Opus 5.5 blocks. The cost profile changes substantially — Fable 5.1 is $10/$50 input/output vs. Opus 5.5's $4/$20 — so this is a quality-vs-cost decision you should make explicitly rather than inherit from a generic fallback rule.

Breaking change 4: computer_20251124 tool type removed

On the Claude API and Google Cloud, a tools entry with type: "computer_20251124" returns a 400. The replacement is the computer_toolset_20260801 toolset.

Before:

tools = [{
    "type": "computer_20251124",
    "name": "computer",
    "display_width_px": 1280,
    "display_height_px": 800,
    "display_number": 1,
}]
# Plus beta header: "computer-use-2024-10-22"

After:

tools = [{"type": "computer_toolset_20260801"}]
# No beta header needed. No name or display dimensions in the tool entry.

The toolset form doesn't take display dimensions inline — those are set via the system prompt or environment configuration. Amazon Bedrock retains computer_20251124 support on existing models; the removal applies to the Claude API and Google Cloud only.

The model ID and what it looks like on each platform

claude-opus-5-5 is a fixed snapshot ID with no date suffix. The same dateless scheme applies across platforms:

The /claude-api migrate skill in Claude Code (/claude-api migrate this project to claude-opus-5-5) handles the ID swap and all four breaking changes automatically. It detects Bedrock and Vertex clients and adjusts the ID format accordingly.

What to audit before flipping the model ID

1. Search for thinking field usage. Any {type: "disabled"} or {type: "enabled", budget_tokens: N} call breaks. Replace with output_config: {effort: "..."}.
2. Search for tool_choice.type values of any or tool. Replace with auto + strict tool definitions + prompt instruction.
3. Audit your fallback chain. If you fall back to a non-Fable/Mythos model mid-conversation, thinking context will be dropped. Decide if that's acceptable and document it explicitly.
4. Check computer use tool type. If you're on computer_20251124 on the Claude API or Google Cloud, switch to computer_toolset_20260801.
5. Recalibrate cost-based routing thresholds. The 60% cache read price drop changes the effective cost per task on agentic workloads significantly.
6. Check gateway middleware for thinking injection or tool_choice normalization. Rules that inject these parameters for all Claude calls will 400 on Opus 5.5 unless they're model-aware.