Skip to content

anthropic

Four Opus 5.5 API changes make Opus 5 requests fail

Promtime

If you tell Claude Opus 5.5 not to think, it answers with a 400 error. The New Stack reports that this is the first of four breaking changes in Anthropic's migration guide, and each one can make a request built for Opus 5 fail once you swap the model ID.

The swap is still tempting, because Opus 5.5 costs less than its predecessor. Input drops from $5 to $4 per million tokens and output from $25 to $20. Some of the other changes throw no error at all, but they can still change how an existing agent behaves.

At a glance

  • Anthropic's migration guide for Opus 5.5 lists four breaking changes: always-on thinking, rejected forced tool calls, stricter rules for replaying thinking blocks, and a new computer-use toolset.
  • The 1 million-token context window and 128,000-token maximum output stay the same, while the default effort level drops from high on Opus 5 to medium on Opus 5.5.
  • The quietest trap throws no error at all: narration between tool calls now arrives as thinking blocks that are empty by default, so agent interfaces go silent mid-task.

If you have not followed the Opus line closely, this is the second migration in a row that reshapes thinking. The move to Opus 5 already turned thinking on by default and changed the shape of responses, and teams still on Opus 4.8 have to work through that guide first. Teams on anything older than Opus 4.7 also face rejected sampling parameters, rejected manual extended thinking, removed prefill and a newer tokenizer.

Opus 5.5 returns a 400 when thinking is disabled or given budget_tokens

Thinking controls are the first break. A request that sets thinking to disabled, or uses enabled with budget_tokens, now fails. Effort is the only way left to control how much reasoning Opus 5.5 does. Agents that turned thinking off for simple steps to save time and tokens will need to give those steps a lower effort level instead.

Because thinking is always on, every response opens with thinking blocks. Code that expects the first content block to be text needs fixing. The default effort also drops from high to medium, so requests that omit the parameter quietly run at a lower setting. Anthropic recommends setting effort explicitly and re-running effort evaluations, since the right level for each step may have shifted along with cost and latency.

Forced tool calls and the old computer_20251124 tool both fail on Opus 5.5

Setting tool_choice to any or tool returns a 400 error. That includes the token counting endpoint, so cost estimates built on those settings fail along with the requests they were meant to price. Many agent loops force a call when a step has to query a database, run code or reach another service. Anthropic's replacement is auto combined with strict tool use or structured outputs, with the prompt stating when the tool applies.

The fourth break hits computer-use agents on the Claude API and Google Cloud. Opus 5.5 rejects computer_20251124 and accepts computer use only through the computer_toolset_20260801 toolset. The request itself gets simpler, because the beta header goes away and the toolset entry takes no name or display dimensions.

The agent loop needs more work, though. Each action arrives as its own tool_use block, identified by the block's name rather than input.action. A single turn can contain several of these blocks, and every result has to echo toolset_name. The older tool still works on Amazon Bedrock, and developers on other platforms are pointed to the compatibility documentation.

Narration between tool calls arrives as empty thinking blocks by default

The change most likely to slip past testing throws no error. On Opus 5, the text Claude writes between tool calls comes back as text blocks. On Opus 5.5 it arrives as progress-update thinking blocks, and at the default thinking.display setting of omitted, those blocks are empty. Any interface that streams that narration to users goes silent between tool calls.

To fix it, set display to updates, a beta option that returns progress updates while keeping reasoning hidden, or to summarized, which returns both. Then render each non-empty thinking block ahead of the tool call it precedes.

Opus 5.5 also ships with broader safety classifiers. A stop_reason of refusal can now carry the stop_details categories bio and reasoning_extraction alongside cyber. Anthropic's server-side fallback will not retry requests declined under reasoning_extraction and hands the refusal back to the application instead. Agents that don't handle refusals will stop mid-task, a problem developers have already run into with OpenAI's safety system cutting off API responses.

Claude Managed Agents users only need to change the model name

How much work the migration takes depends on where your agent runs. Claude Managed Agents users only swap the model name. In Claude Code, /claude-api migrate applies the model ID swap, parameter changes, prefill replacement and effort calibration across a codebase. It then leaves you a checklist of items to verify by hand.

Anthropic recommends testing the migration in a development environment before switching production traffic. Teams that maintain their own integrations have to test the pieces around the model as well. Tool calls, model handoffs, conversation history and user-facing progress updates can all behave differently after the switch, because agent failures often start outside the model itself.

Opus 5.5 thinking blocks are readable only by Fable 5.1 and Mythos 5.1 on the Claude API

Thinking blocks are now tied to the model and the conversation that produced them. Think of a sealed envelope addressed to one reader: pass it to someone else, or edit the letter, and the seal stops counting. On the Claude API, Fable 5.1 and Mythos 5.1 are the only other models that can read Opus 5.5 blocks.

If a router or fallback hands the conversation to any other model, that model runs those turns without the earlier reasoning and returns no error. Opus 5.5 itself can read blocks from Opus 5 and earlier Opus, Sonnet and Haiku models, but not from Fable or Mythos.

Conversations also have to stay append-only. Trimming old messages, changing tool definitions, summarizing earlier context on the client or rewriting the system prompt mid-conversation all invalidate existing blocks. For accounts created on or after August 31, 2026, at midnight UTC, replaying such a block returns a 400 by default. Older accounts get no error, but the invalid blocks still reach the model.

Integrations that never edit earlier turns need no code change. Anthropic says Claude Code, claude.ai, Claude Managed Agents and the Claude Agent SDK already work this way. Agents that compact their own context should follow the preserved thinking documentation.

The guide gives no measure of how well auto plus strict tool use replaces a forced call, so teams will have to find out in their own evaluations. It also doesn't say whether always-on thinking eats into the $4 and $20 prices on steps that used to skip thinking. In our view, the riskiest choice is the router behaviour: a handoff to a model that cannot read the blocks drops the earlier reasoning silently instead of failing loudly.

When every account gets the 400

Anthropic says future models will enforce the thinking-block check for all accounts, not only those created on or after the August 31, 2026 cutoff. It has not said which model will start doing so, or when. Until then, older accounts can keep sending invalidated blocks without seeing an error. The guide also gives no end date for the older computer-use tool on Amazon Bedrock.

Related stories

  1. Anthropic tells Opus 5.5 users to delete "think hard" lines
  2. Opus 5.5 lands 40% cheaper to run than Opus 5
  3. Claude Directory opens a submission flow for plugins
  4. Commerce agent blueprint ships with every write staged
  5. Editing chat history now breaks Claude's thinking blocks
  6. Research preview opens for agent-to-machine control

Comments

No comments yet. Be the first.

Join the conversation

Sign in with Google to leave a comment. Your name and avatar come from your Google profile, and the comment appears after moderation.

We only use your name and avatar from Google. We never store your email address.