Claude Sonnet 5.5: What Changed and How to Test a Migration

Anthropic released Claude Sonnet 5.5 on 28 September 2026, describing it as a faster and more efficient model for everyday coding, knowledge work and well-scoped agent tasks. The useful question is not whether the version number is newer. It is whether the new model improves a specific workflow without changing behaviour in ways your application is not ready to handle.

The short answer is: test it, but do not treat the migration as a model-name swap. Anthropic says Sonnet 5.5 produces output more than 30% faster than Sonnet 5 and can cost up to 30% less per task in its testing. Those are vendor-reported figures, not a promise about your end-to-end application. The API also changes several defaults and rejects some request patterns that older integrations may still send.

This guide separates the headline from the implementation work and gives you a small, reversible test plan.

What changed in Claude Sonnet 5.5?

According to Anthropic's 28 September announcement, Claude Sonnet 5.5 is available in Claude.ai and across Anthropic's platform, Amazon Web Services, Google Cloud and Microsoft Azure. The direct Anthropic API model identifier is claude-sonnet-5-5.

Standard input and output prices remain $2 and $10 per million tokens respectively. Prompt-cache reads cost $0.10 per million tokens, half the Sonnet 5 rate. Anthropic reports costs up to 30% lower per task in its testing. These are vendor-reported results, not a prediction for your workload. Check total cost per accepted result.

Anthropic positions Sonnet 5.5 as the default choice for well-defined professional work where speed and quality both matter. It still positions Claude Opus 5.5 for more complex, open-ended work that needs deeper judgment. In practice, the right comparison is not “which model is best?” but “which model clears the quality bar for this task at the lowest total cost and delay?”

If you need broader model-selection context, read our Claude Opus 5.5 pricing and migration guide. For a business control framework before any model change, start with how small businesses can use AI without losing control.

The five compatibility checks to run first

Anthropic's official Sonnet 5.5 migration guide lists request patterns that can return a 400 error or behave differently. Search your code, templates and gateway configuration for each of these before you send production traffic.

1. Thinking budgets: fixed thinking-budget parameters are no longer supported. Sonnet 5.5 uses adaptive thinking, and thinking is enabled by default.
2. Non-default sampling: custom temperature, top-p or top-k settings are not compatible with the new model. Remove them and establish a new baseline.
3. Assistant prefills: starting an assistant response with prefilled text is not supported. Put format requirements in the instruction and validate the result instead.
4. Forced tool choice: tool_choice values any and tool return a 400 error. Use auto with strict tool schemas. On Amazon Bedrock, strict tool use is unavailable for Sonnet 5.5; use auto and validate inputs in your application.
5. Thinking disabled: thinking: {"type": "disabled"} returns a 400 error. To disable up-front thinking, use thinking: {"type": "between_tools"} at low, medium or high effort. Use adaptive thinking for xhigh or max.

There are two quieter changes to inspect as well. First, applications should process response content blocks by type rather than assuming a fixed order. Second, any thinking blocks that form part of a multi-turn exchange should be passed back unchanged. If your message store flattens, rewrites or drops blocks, fix that before migrating.

Sonnet 5.5 supports five effort levels: low, medium, high, xhigh and max. Adaptive thinking supports all five; between_tools accepts only low, medium and high and turns off up-front thinking. The Claude API defaults to high effort. Re-test effort settings on representative tasks rather than treating a higher level as a universal improvement.

A five-step canary test for a safe migration

A canary is a deliberately small share of real, representative work sent to the new model while the old route remains available. The goal is to find integration and quality problems before they affect the full workflow.

1. Choose one narrow task

Pick a task with a clear input, a reviewable output and a known definition of success. Good candidates include classifying support requests, extracting fields from a fixed document type or drafting a response that a person approves. Avoid starting with a high-impact decision, a multi-system autonomous agent or a task whose quality cannot be checked consistently.

2. Freeze a representative evaluation set

Collect 30 to 100 examples that reflect normal work plus important edge cases. Remove secrets and personal data unless your approved data-handling arrangement explicitly permits them. Keep the same prompt, tools, documents and scoring rubric for both the current and candidate model.

3. Compare outcomes, not demonstrations

Score factual correctness, instruction following, required citations, tool-call validity, reviewer acceptance, time to accepted result and total tokens. A shorter answer is not automatically better, and a faster token stream does not help if a reviewer spends longer correcting it.

4. Set rollback rules before the test

Write down the thresholds that stop the rollout. Examples include any increase in unsupported claims, a tool failure rate above 1%, reviewer acceptance below the current baseline or a meaningful rise in cost per accepted result. An explicit stop rule prevents a promising average from hiding a harmful edge case.

5. Expand traffic in stages

Start with a small internal sample, then increase the share only after the results are reviewed. Preserve logs, model identifiers, prompt versions, effort settings and the decision for each stage. For higher-impact workflows, add the kinds of human approval checkpoints described in this guide.

A copyable evaluation prompt

Use a bounded prompt like the one below to make review easier. Replace the bracketed fields with your approved rubric and do not paste customer secrets or personal data into an unapproved environment.

Task: [describe one narrow business task]
Input: [approved test input]

Return:
1. The requested output.
2. A short list of assumptions.
3. Any missing information that could change the answer.
4. A confidence label: high, medium or low.

Constraints:
- Use only the supplied input and approved tools.
- Do not invent facts, identifiers or results.
- If evidence is insufficient, say what is missing.
- Follow this output format: [schema or headings].

The prompt is only one layer. Validate the format in code, test tool calls against a schema and route low-confidence or high-impact cases to a person.

Worked example: a support-draft workflow

Imagine a small software company uses Sonnet 5 to draft replies to billing and account questions. A support agent reviews every draft before sending it. The company wants to know whether Sonnet 5.5 can reduce delay without increasing corrections.

The team selects 60 resolved tickets: 40 routine cases, 10 ambiguous cases and 10 cases containing a policy exception. It runs both models with the same approved help-centre excerpts and the same structured output. Reviewers do not see which model produced each draft.

For every draft, the team records whether the answer used only the supplied policy, whether the requested action was correct, whether the tone needed editing, how long the review took and whether the draft was accepted. It also checks that no message bypassed the human send step.

If Sonnet 5.5 produces fewer tokens but requires more policy corrections, the migration has not saved money. If it reaches the same acceptance rate with shorter review time and valid tool calls, the team can raise the canary share. Policy exceptions remain on the old route until the new model clears that separate edge-case test.

Measure cost per accepted result

Token cost is useful but incomplete. A practical unit is:

Cost per accepted result = (model cost + tool cost + review cost + rework cost) ÷ accepted outputs

This exposes trade-offs that a benchmark headline cannot. A 20% reduction in model spend can be erased by one extra minute of review. Conversely, the same list price can still be a good deal if the model needs fewer retries and produces more usable first drafts.

Track the distribution as well as the average. The slowest or most expensive 5% of cases may reveal a tool loop, an oversized context or an ambiguity that deserves its own route. Our value, risk and reversibility scoring method can help you decide which workflow should be tested first.

When not to switch yet

Delay the migration if you cannot reproduce your current quality baseline, if the integration depends on an unsupported request pattern, or if you have no reliable way to roll back. Also wait if the task makes consequential decisions without human review or if the required data handling has not been approved.

Choose Opus 5.5 rather than Sonnet 5.5 when your evidence shows that deeper, open-ended judgment materially improves the result. Choose neither model automatically when a deterministic rule, database query or conventional search is more reliable and cheaper.

The official Sonnet model page is the right place to confirm current availability and pricing before deployment, because platform details can change after an announcement.

Reader Q&A

Do I need to upgrade to Claude Sonnet 5.5 immediately?

No. Keep the current route until Sonnet 5.5 passes a representative quality, compatibility and cost test for your workflow.

Did the token price change?

Standard input and output rates remain $2 and $10 per million tokens respectively. Prompt-cache reads fell to $0.10 per million tokens, half the Sonnet 5 rate. Anthropic’s per-task savings are vendor-reported, so measure your own workload.

Is Sonnet 5.5 better than Opus 5.5?

Not for every task. Sonnet is positioned for faster, well-scoped work, while Opus remains the stronger choice for complex, open-ended judgment.

Can I reuse my existing prompts unchanged?

Start from the existing prompt, but re-test it. Remove unsupported API settings, verify output structure and measure quality rather than assuming identical behaviour.

What should I measure in a migration test?

Measure correctness, instruction following, tool validity, reviewer acceptance, time to accepted result, total tokens and the frequency of harmful edge cases.

How large should the first canary be?

Use the smallest sample that still represents normal work and critical edge cases. For many narrow workflows, 30 to 100 reviewed examples is a useful starting range.

The practical verdict

Claude Sonnet 5.5 is a meaningful candidate for well-scoped production work, especially where output speed and token efficiency matter. Its release also makes the migration discipline more important: defaults changed, several familiar parameters are rejected, and a successful response is not the same as a successful workflow.

Start with one reversible task. Remove incompatible settings, preserve message blocks correctly, choose an effort level, run a blinded comparison and expand only when the new route clears your prewritten thresholds. That produces a decision you can defend long after the launch headline has moved on.

Garry Knight

I'm Garry Knight, the person behind Prodify Digital. I write about email list building, email marketing, SEO, AI search and the tools that connect them. My aim is to make online marketing easier to understand, so creators and small business owners can make informed decisions about building an audience and keeping people engaged. Here you'll find straightforward guides and product reviews that explain what something does, where it fits and which limitations matter. The focus is on clear explanations and useful next steps—not hype, shortcuts or promises of easy earnings.

See Full Bio