Claude Sonnet 5.5: Better Coding and Knowledge Work at Sonnet 5 Prices

For well-specified agentic coding, Anthropic recommends starting at medium effort. Claude apps and Claude Code default to medium effort, while the API defaults to high. If Sonnet produces the work you need at a lower effort, that's where it's significantly cheaper than Opus.

API Changes When Moving from Sonnet 5

The Claude API model ID is claude-sonnet-5-5. Changing that ID isn't enough, there are two things you should pay attention to, per Anthropic's migration guide:

1. Turning off up-front thinking: thinking: {"type":"disabled"} now returns HTTP 400. If you want to keep thinking disabled, use {"type":"between_tools"} at low, medium, or high effort instead. This keeps up-front thinking off but allows thinking between tool calls. Without tools, responses contain text only. The mode rejects xhigh/max and additional fields such as display, budget_tokens, or block_binding.
2. Forcing a tool call: tool_choice with a value of any or tool now returns 400. Use auto with instructions specifying when to call the tool. Where supported, strict schemas constrain tool arguments, but don't force a call: the model can still answer in text. Bedrock doesn't support structured outputs or strict tool use for Sonnet 5.5, so its documented path uses auto, instructions, and application-side argument validation.

Adaptive thinking remains the default, like in Sonnet 5. The other significant change concerns how thinking blocks are preserved across the conversation. Suppose your application edits an earlier system instruction, then sends the conversation back with a thinking block generated after that instruction. Sonnet 5.5 automatically ties a thinking block to the preceding system prompt, tools, and messages. Once you change that history, the block no longer matches. On the Claude API and Bedrock, this returns 400 by default for accounts created on or after August 31, 2026, at 00:00 UTC, while older accounts can opt into enforcement.

The solution is to keep history append-only, using supported mid-conversation instruction or tool changes when needed. The documentation also provides an adaptive-thinking beta control for dropping invalid blocks instead of rejecting the request.

Model and account switches behave differently. Sonnet 5.5 can read Sonnet 5's thinking blocks, but no other model can read Sonnet 5.5's. Its blocks also belong to the producing account or an account Anthropic identifies as linked. When you switch to an incompatible model or unrelated account, the API drops those blocks while the request succeeds. This only affects preserved thinking state, not the ability to transfer visible conversation text.

There's also a visible response change. Longer notes between tool calls now arrive in thinking blocks. Your interface can appear silent while requests continue successfully. With adaptive thinking, thinking.display: "summarized" returns displayable content, and between_tools returns progress notes without that setting.

What Changed in Safeguards and Permitted Use

Sonnet 5.5's greater cybersecurity capability comes with stronger cyber safeguards, similar to those on Opus 5.5. Routine software development remains an intended use. In practice, this means that authorized source-code vulnerability discovery is supported, while vulnerability discovery in compiled binaries is blocked. Some legitimate dual-use security work can also trigger a refusal. Anthropic describes the controls in the system card's cyber-safeguard assessment.

Biology safeguards remain at the Sonnet 5 level, rather than adopting Opus 5.5's broader dual-use biology controls. Most research, education, and clinical work is intended to remain unaffected, although some microbiology and virology requests can be flagged in error.

Sonnet 5.5 is also the first Sonnet with a classifier targeting extraction of hidden reasoning. Asking for an ordinary explanation of an answer is distinct from extracting that internal reasoning. A separate, narrow frontier_llm classifier covers advanced model-development capabilities, though ordinary AI and ML development is intended to remain unaffected.

For cyber and frontier-LLM refusals, first-party apps fall back to Sonnet 5. Claude API developers must opt into fallback, and server-side fallback isn't available on Bedrock. Biology and reasoning-extraction refusals have no fallback. A refusal can return HTTP 200 with stop_reason: "refusal", so it is different from the invalid requests described above.

A Stronger Default for Scoped Work

Sonnet 5.5 is a strong starting point for defined coding tasks and professional deliverables. It improves substantially over Sonnet 5 at the same token rates, and its clearest economic advantage over Opus comes when lower effort produces the work you need. At higher effort, you should compare the cost per completed task with Opus rather than assuming Sonnet is immediately cheaper. Opus is still the stronger recommendation for sustained, open-ended judgment.

For an existing Sonnet application, first address the API changes that affect your requests, then compare representative tasks for acceptable output, completed-task cost, and elapsed time. That establishes what your application actually stands to gain, which hopefully matches the reported capabilities.

How Caylent Can Help

As a Preferred Services Partner and Charter Member of the Claude Partner Network, Caylent helps you select and implement Claude models for your applications. Our Anthropic Consulting & Engineering practice supports adoption, enablement, and building agentic applications, including the workload evaluation and cost optimization needed to make a model upgrade useful in production. Whether you're upgrading an existing Sonnet integration or choosing a model for a new application, connect with us to connect the model's capabilities to the work you need it to do.