You merge a one-line diff: the model ID in your registry flips to the new release. No HTTP errors. No failed health checks. Three days later, acceptance rates on a subset of tool-calling workflows have drifted, and you are tracing the problem back to a config change nobody flagged as risky.
The model is fast. Anthropic released Claude Sonnet 5.5 on September 28, 2026, the second model in the Claude 5.5 family and a faster, lower-cost complement to Opus 5.5. Its list price matches Sonnet 5: $2 per million input tokens and $10 per million output tokens, per-token pricing that Reuters independently confirms is unchanged. In Anthropic's own testing, the model generates outputs more than 30% faster than Sonnet 5 and typically needs fewer tokens per task, cutting cost per task by up to 30%. The failure mode is not the model. It is the assumption that a model bump is a config edit. [1] [2]
What changed for your integration
Two things changed on the integration surface, and one is easy to miss.
The first is the thinking-mode migration. Thinking mode is the model's optional step-by-step reasoning before it answers. If your integration runs Sonnet with thinking off, Anthropic requires a new setting, between_tools, before the move: it keeps up-front reasoning off but allows brief thinking between tool calls. The switch is a prerequisite, not an afterthought, and Anthropic publishes a migration guide for exactly this transition. [1]
The second is quieter. Because the new model's cybersecurity capabilities rose to the level of Anthropic's most capable models, it is the first Sonnet release to ship with cyber safeguards and fallbacks: higher-risk cybersecurity tasks will visibly fall back to the previous Sonnet, which means the request is served by an older model than the one you called. [1] Routine software development, including finding and fixing bugs in your own code, is unaffected. But if your pipeline ever submits security-testing prompts, your logging needs to record which model actually answered.
What did not change matters just as much: routine development behavior, zero data retention, and availability across AWS, Google Cloud, and Microsoft Azure, with the new model answering to claude-sonnet-5-5 on the Claude Platform. [1]
Run it as a migration
Start with an inventory. Search for every call site that passes a model ID, disables thinking, or reads the responding model's name out of the API response. Those are your three risk surfaces, because the fallback breaks the assumption that the responding model is the model you called.
Pin the current model behind your registry or config before touching production. This is ordinary dependency hygiene: one source of truth for the model version means rollback is a registry flip, not a redeploy.
Run a shadow deployment. Replay your regression suite against the new model in parallel with the pinned one, and compare acceptance rates, tokens per task, and the behavioral flags your suite already surfaces. Watch tool-calling flows closely, because that is where the thinking-setting change shows up. Watch security-adjacent prompts, because that is where the fallback shows up. The shadow run gives you the signal before your users do.
Cut over only when the new model matches or beats the pinned one on your own suite, not on the vendor's benchmarks. When it does, the cutover is a registry flip. When it does not, the rollback is the same flip in reverse.
The decision rule
The new Sonnet is a well-scoped release: faster, cheaper per task, the same price per token, and no disruption to routine development. It also carries two migration prerequisites that a config edit silently skips.
Inventory, pin, shadow, cut over. That sequence applies to this model and to every model that follows, because a model version is not a library patch. It is a dependency with its own behavior profile, and it earns production the way every dependency does: by passing your tests, not by trusting the changelog.
Stop treating model upgrades as config edits. Schedule them as migrations with a regression gate, a staged cutover, and a defined rollback. Adopt the rule before the next release arrives, not after the pipeline drifts.