Claude Sonnet 5.5 is faster than Sonnet 5, but migration requires more than changing the model ID

What changed in Sonnet 5.5

Anthropic describes Sonnet 5.5 as a faster and more efficient replacement for Sonnet 5. The company reports 30% faster execution and up to 30% less cost for most work because the model generally uses fewer tokens at the same per-token price. It recommends Sonnet for well-scoped tasks such as fixing bugs and iterating on features, while reserving Opus 5.5 for work that needs more careful judgment.

The model keeps a 1-million-token context window, a 128,000-token standard output limit, text and image input, and adaptive thinking. Claude Code 2.1.284 and later resolves the sonnet alias to 5.5 on Anthropic's API, where Claude Code uses medium effort by default. The direct API defaults to high effort.

The efficiency evidence is promising but early

Anthropic's speed and cost figures come from its own launch evaluation. GitHub separately reports that Sonnet 5.5 matched Sonnet 5 on coding tasks in its early Copilot tests while using fewer steps, tokens, and tool calls and finishing faster. GitHub does not publish the task set, raw results, or a percentage improvement in that announcement.

BenchLM recorded 61 benchmark rows on launch day, including coding and agentic results, but labels its partial benchmark coverage and leaves the model unranked. Those rows are useful leads for evaluation, not proof that Sonnet 5.5 is better on a private repository, tool harness, or production traffic mix.

Migration changes to check before switching

• Change the model ID to claude-sonnet-5-5 and pin it explicitly while testing instead of relying on an alias.
• Expect adaptive thinking by default. If Sonnet 5 ran with thinking disabled, review Anthropic's between_tools mode and its effect on tool loops.
• Parse response content by block type. A thinking block can appear before text, so code that assumes content[0].text can fail.
• Replace forced named tool_choice with auto selection and strict tool schemas where your integration depends on a required tool call.
• Keep conversations append-only and preserve compatible thinking blocks when moving an active Sonnet 5 conversation to 5.5.
• Review computer-use tool versions, effort settings, cache thresholds, rate-limit pools, and platform-specific model IDs.

Run a matched migration evaluation

• Replay representative completed tasks against pinned Sonnet 5 and Sonnet 5.5 model IDs with the same prompts, tools, permissions, timeouts, and retry policy.
• Measure accepted-task success, regression rate, wall time, input and output tokens, cache reads, tool calls, retries, and cost per accepted result.
• Include multi-turn and tool-heavy cases that exercise thinking blocks, forced-tool replacements, conversation continuation, and malformed tool arguments.
• Inspect failures manually for skipped checks, premature completion, unnecessary tool calls, prompt-injection behavior, and changes in writing or code-review judgment.
• Roll out by bounded workload after the migration checks pass, and keep the previous pinned model available until production traces confirm the result.

Limits and open questions

A lower token count can reduce cost and latency, but it does not establish correctness. The launch evidence does not show how the model performs on every language, repository shape, long-running agent, or organization-specific policy. A fast successful demo is also different from a stable production trajectory with retries and external tools.

The Anthropic system card contains pre-deployment safety and capability evaluations. It remains vendor-produced evidence. Teams using sensitive data, computer use, or consequential tools should retain their own permission boundaries, deterministic checks, audit logs, and human approval points.