Claude Sonnet 5.5 vs Opus and Haiku 5.5, and How to Migrate

Claude Sonnet 5.5 is the model most Claude API projects will end up on this quarter, and it is not a drop-in swap for Claude Sonnet 5. Anthropic released it on 28 September 2026 at the same $2 / $10 per million tokens as Sonnet 5, but it brings five breaking changes and one silent change to the response shape. In this guide I compare Claude Sonnet 5.5 with Opus 5.5 and Haiku 5.5 so you can pick the right tier, show what the pricing really looks like per request, and walk through a before-and-after migration of a real TypeScript request with a checklist you can copy.

Claude Sonnet 5.5 at a glance

From the model page:

• Model ID: claude-sonnet-5-5 on the Claude API (no date suffix), anthropic.claude-sonnet-5-5 on Amazon Bedrock.
• Limits: 1M token context window and 128K max output on the Messages API. The Message Batches API allows up to 300K output tokens with the output-300k-2026-03-24 beta header.
• Thinking: adaptive thinking is on by default, and the default effort on the Claude API is high.
• Caching: the minimum cacheable prompt is 512 tokens, down from 1,024 on Sonnet 5.
• Tokenizer: the same as Sonnet 5's, so your token counts don't change if you are coming from Sonnet 5.
• Lifecycle: retirement not sooner than 28 September 2027.

Anthropic's announcement says it generates output 30%+ faster than Sonnet 5 and costs up to 30% less per task because it needs fewer tokens. Measure that on your own prompts.

Sonnet vs Opus 5.5 vs Haiku 5.5

All three current 5.5 models share a 1M token context window, 128K max output, a June 2026 knowledge cutoff and a 50% Batch API discount. The differences are price, default effort and what Anthropic positions each one for:

Sources: the Haiku 5.5, Sonnet 5.5 and Opus 5.5 model pages and the pricing page.

Which one to use when

Anthropic's model selection guide offers two starting points: efficiency-first with Haiku 5.5, or capability-first with Opus 5.5, then tune down. It also says that tuning effort is often a better lever than switching models. In practice I split it like this:

• Haiku 5.5 for the high-volume edges of a system: intent classification in a chatbot, routing a ticket, pulling fields out of a document, or running as a subagent. Watch the 100K-token price step. A request whose prompt goes over 100,000 tokens pays the higher rate for the whole request, cache reads included.
• Sonnet 5.5 as the default for user-facing features: chat replies, code generation, tool-calling agents with a clear scope. You can turn off up-front thinking with between_tools when latency matters.
• Opus 5.5 for long, open-ended runs where a wrong decision is expensive: multi-hour coding agents, large refactors, computer use. Its thinking can't be turned off, so it's not the pick for quick replies.

Sonnet vs Opus 5.5 for coding

On Anthropic's own published numbers, Sonnet 5.5 is close to Opus 5.5 on coding benchmarks: 55.5% vs 57.8% on CursorBench 4.0, and 52.1% (at xhigh effort) vs 54.4% on FrontierCode 1.1. It even scores higher on Terminal-Bench 4.0 (70.6% vs 66.4%). Anthropic still says that Opus 5.5 "remains clearly stronger at complex, open-ended work requiring sustained judgment", and its Opus 5.5 page focuses on codebase-wide migrations and audits. My reading: Sonnet 5.5 for well-scoped tickets and bug fixes, Opus 5.5 when the agent has to plan across many files for hours.

Sonnet 5.5 in Claude Code

In Claude Code and the Claude apps the default effort is Medium, while the Claude Platform API defaults to High, per the announcement. So the same model can feel faster in Claude Code than in your own API calls. If you compare the two, set output_config.effort explicitly.

Claude API pricing for the 5.5 family

Sonnet 5.5 has the same input, output and cache-write prices as Sonnet 5. The one change is cache reads: on 7 October 2026 Anthropic lowered them from $0.20 to $0.10 per million tokens, which is 0.05x the input price instead of the usual 0.1x. For apps with a long, stable system prompt, that's where most of the saving comes from.

A quick per-request example at list prices: a chatbot turn with a 20,000-token cached system prompt, 2,000 new input tokens and 1,000 output tokens.

Thinking tokens are billed as output, so real output counts will be higher with adaptive thinking on. For a full method that turns token prices into cost per completed task across providers, see my LLM API pricing comparison.

Sonnet 5 vs 5.5: the five breaking changes

The What's new page lists five changes that make Sonnet 5 code fail on Sonnet 5.5.

1. thinking: disabled is replaced by between_tools

between_tools is the lowest thinking setting: no thinking before the answer, but short progress updates between tool calls still come back as thinking blocks. Without tools, the response is plain text, as with disabled on Sonnet 5. With between_tools, effort also can't change mid-conversation.

2. Forced tool use returns an error

tool_choice of {"type": "any"} or {"type": "tool", "name": ...} now returns a 400, including on the token counting endpoint. Use {"type": "auto"}, mark the tool strict: true so its input matches the schema, and say in the prompt when the tool should be used. A request can have at most 20 strict tools.

3. Thinking blocks are tied to the model and the conversation

Sonnet 5.5 thinking blocks are signed over everything before them. For accounts created on or after 31 August 2026, replaying a block after you edited the system prompt, the tools or an earlier message returns a 400.

Sonnet 5.5 reads Sonnet 5 blocks but not Opus 5 or Opus 5.5 blocks; unreadable blocks are dropped and not billed. Its blocks also only work in the account that produced them or a linked one.

4. computer_20251124 is rejected on the Claude API

On the Claude API and Google-managed Google Cloud, computer use needs the computer_toolset_20260801 toolset. Amazon Bedrock still accepts computer_20251124.

5. The advisor tool rejects four advisors

With a Sonnet 5.5 executor, Claude Opus 4.8, Opus 4.7, Sonnet 5 and Haiku 5.5 advisors return a 400. Accepted advisors include Opus 5, Opus 5.5 and Sonnet 5.5 itself, and the advice comes back encrypted as an advisor_redacted_result block.

The silent change: text between tool calls

Before and after: migrating a Sonnet 5 request

Here is a typical support-bot request written for Sonnet 5. It turns thinking off for speed and forces a ticket tool. On Sonnet 5.5, both settings return a 400:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

// Claude Sonnet 5: worked, but returns 400 errors on Claude Sonnet 5.5
const response = await client.messages.create({
  model: "claude-sonnet-5",
  max_tokens: 2048,
  thinking: { type: "disabled" },
  tool_choice: { type: "tool", name: "create_ticket" },
  tools, // create_ticket with summary + priority
  messages: [{ role: "user", content: "My invoice PDF is blank since yesterday." }],
});

const call = response.content[0]; // assumes the first block is the tool call

The Sonnet 5.5 version swaps disabled for between_tools, sets effort explicitly, replaces forced tool use with auto plus a strict tool, and reads the response by block type:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const tools: Anthropic.Tool[] = [
  {
    name: "create_ticket",
    description: "Create a support ticket from a customer message",
    input_schema: {
      type: "object",
      properties: {
        summary: { type: "string" },
        priority: { type: "string", enum: ["low", "normal", "urgent"] },
      },
      required: ["summary", "priority"],
      additionalProperties: false,
    },
    strict: true, // input must match input_schema
  },
];

const response = await client.messages.create({
  model: "claude-sonnet-5-5",
  max_tokens: 2048,
  thinking: { type: "between_tools" }, // replaces { type: "disabled" }
  output_config: { effort: "medium" }, // between_tools needs low, medium or high
  tool_choice: { type: "auto" }, // "any" and "tool" return a 400 error
  system: "Always file the customer's problem with the create_ticket tool.",
  tools,
  messages: [{ role: "user", content: "My invoice PDF is blank since yesterday." }],
});

// Read blocks by type: thinking blocks can come before the tool call.
for (const block of response.content) {
  if (block.type === "tool_use" && block.name === "create_ticket") {
    console.log("ticket:", block.input);
  } else if (block.type === "thinking" && block.thinking) {
    console.log("progress:", block.thinking);
  } else if (block.type === "text") {
    console.log(block.text);
  }
}

I type-checked both snippets against @anthropic-ai/sdk 1.3.0, which includes the between_tools thinking type. With auto, the model can still answer in text, so keep a fallback path for a reply with no tool_use block. In a tool loop, pass every thinking block back unchanged with the rest of the assistant turn.

One more thing to keep separate: on 21 October 2026 Anthropic released API version 2026-10-21 along with TypeScript SDK 1.0.0 and Python SDK 2.0.0. Under that version, temperature, top_p and top_k return a 400 even at default values. Sonnet 5.5 already rejects them, but do the model migration and the SDK upgrade as two separate changes so you can tell which one broke a test.

Claude Sonnet 5.5 migration checklist

• Change the model ID to claude-sonnet-5-5 (or anthropic.claude-sonnet-5-5 on Bedrock).
• Replace thinking: {"type": "disabled"} with {"type": "between_tools"}, and keep effort at high or below for those requests.
• Replace tool_choice any and tool with auto, add strict: true and additionalProperties: false, and tell the model in the prompt when to call the tool. Check token counting calls too.
• Read content blocks by type, never content[0], and pass thinking blocks back unchanged.
• Make conversation history append-only, or strip thinking blocks from any turn you edit.
• If your UI shows progress text between tool calls, set thinking.display or use between_tools.
• Move computer use to computer_toolset_20260801 on the Claude API and Google-managed Google Cloud.
• Swap advisor models that Sonnet 5.5 rejects, and expect encrypted advice.
• Handle stop_reason: "refusal". Sonnet 5.5 declines in five stop_details categories, and server-side fallback retries only cyber and frontier_llm declines on Sonnet 5.
• Re-run your effort sweep. Effort levels are recalibrated, so high on Sonnet 5.5 doesn't produce the same amount of thinking as on Sonnet 5.
• Re-baseline cost with the new $0.10 cache read price and the 512-token caching minimum.

For a typical chatbot or agent, the first five items are most of the work. If your agent also talks to MCP servers, check my notes on the stateless MCP spec in the same pass, since both changes touch the tool loop.