A model upgrade can change what happens between tool calls, even when a business keeps the same prompts. Anthropic’s 28 September release of Claude Sonnet 5.5 introduces a migration detail that deserves its own entry in an application’s change log: the between_tools thinking setting.
The Sonnet 5.5 announcement says applications moving from thinking off need that setting, which keeps up-front thinking off. It also describes preserved thinking across accounts and safeguards that can send higher-risk cybersecurity requests to an older model. These are supplier descriptions; the practical consequence is to review the integration’s settings and exceptions before switching its model identifier.
Identify the configuration your application actually sends
Ask the maintainer to inspect the request configuration used by the application, rather than the settings someone sees in a separate chat account. Record the current model identifier and whether thinking is off. That establishes whether the announced migration requirement applies to your existing setup.
For a business owner, the useful handover is a short list of affected integrations. A website assistant, an internal report generator and a developer’s coding tool may use different configurations. Changing one doesn’t establish that the others have migrated.
Have the developer check the current migration documentation before editing the request. The release announcement identifies a required setting; it doesn’t provide a complete implementation recipe for every SDK. Keep the exact configuration change with the application’s deployment notes so a later maintainer can explain it.
Review any workflow that changes accounts mid-session
Anthropic says Sonnet 5.5 expands preserved thinking so that reasoning can’t be decoupled from the account that created it. The announcement directs developers who move conversations between accounts, including Claude Code account switching, to its documentation.
Map where your team hands a conversation from one account to another. If that never happens, note that the specific scenario is outside your current workflow. If it does, ask the integration owner to check how the existing handover behaves under the new version before depending on it during a deadline.
For example, an agency might start a development session under one account and expect another account to continue it. That is an illustrative scenario, not a claim that the new model blocks every handover. The point is to identify a documented migration concern and ask the maintainer to resolve it explicitly.
Make model fallbacks visible to the person reviewing the result
The release page describes a fallback to Sonnet 5 for higher-risk cybersecurity work while keeping routine development available. A maintainer should distinguish an integration error from a supplier safeguard when diagnosing an unexpected result.
Ask what information the application records about the model used and any visible fallback. Check the provider’s available response information before promising a particular log field. A customer-facing assistant shouldn’t invent an explanation for behaviour that its integration can’t observe.
This creates a concrete exception-handling task: name who investigates a fallback, what they can establish from the request and response, and when they escalate it. Keep that ownership alongside the migration configuration.
Keep migration readiness separate from performance tuning
Our earlier Sonnet 5 effort-level article covers task scoring and running costs. This upgrade adds a different decision: whether the application sends the required settings and handles account changes and fallbacks as intended.
Complete that configuration review before judging a new model’s speed. A written record of the thinking setting, account-handover behaviour and exception owner gives your team a way to diagnose the migration instead of attributing every change to model quality.
Author
