Sonnet 5 vs Sonnet 4.6: capability gains, new tokenizer and adaptive thinking

Modalis AI Editorial Team · 2026-08-30

Reviewed by Modalis AI Lab — Pricing and Model Governance · Verified 2026-08-30

Sonnet 5 changes more than capability: default thinking, tokenizer, parameter rules, context, and safeguards all affect how teams should test a migration.

Calling Sonnet 5 a drop-in upgrade is useful at the API-shape level, but incomplete for operations. The same application can often change the model ID without redesigning its entire request. The same budget, token expectation and generation controls cannot simply be assumed to behave as they did on Sonnet 4.6.

The official change list

Anthropic’s Sonnet 5 migration overview identifies three behavior changes: adaptive thinking is enabled by default, manual extended thinking is removed, and non-default values for temperature, top_p or top_k return an error. The model also introduces a tokenizer that can produce approximately 30% more tokens for the same text than Sonnet 4.6.

Why the tokenizer change matters to cost

Token price and request price are not the same. If identical text maps to more tokens, a lower price per million tokens does not translate proportionally into a lower invoice. Prompt language, code density and document structure can change the ratio. Existing dashboards that forecast from Sonnet 4.6 token counts need new measurements from Sonnet 5.

The same issue affects context capacity. A one-million-token window is large, but each Sonnet 5 token covers less text on average than a Sonnet 4.6 token. A corpus that fit near the old limit may need retrieval or compaction even if the headline context number looks larger. Output limits tuned tightly to the previous tokenizer can also truncate an equivalent answer.

Adaptive thinking changes the default cost shape

With adaptive thinking on, Sonnet decides when deeper reasoning is useful within the configured effort and output limits. Thinking tokens count toward the output budget. For difficult tasks that can improve quality; for simple tasks it can be unnecessary overhead. Modalis exposes the thinking capability according to model configuration so the choice is visible rather than hidden in an integration default.

• Keep thinking on for ambiguous analysis, coding, planning and multi-tool workflows where intermediate reasoning can improve completion.
• Test thinking off for classification, extraction and short transformations with deterministic acceptance checks.
• Control effort rather than trying to restore a manual token budget that Sonnet 5 no longer accepts.
• Raise output limits carefully because the limit covers both thinking and the answer returned to the user.

A refusal can arrive with HTTP 200

Anthropic documents real-time cybersecurity safeguards on Sonnet 5. A refused request can be a successful HTTP response with a refusal stop reason rather than a transport error. Integrations that only inspect HTTP status may incorrectly present an empty or incomplete answer as a normal completion.

A migration checklist for production

1. Inventory prompts, system instructions, tool definitions and sampling parameters used by the current Sonnet 4.6 integration.
2. Count representative prompts with Sonnet 5 instead of multiplying historical token counts by a single global factor.
3. Remove manual extended-thinking budgets and non-default sampling values that the new model rejects.
4. Test thinking on and off on the same acceptance suite; capture answer tokens, thinking-related usage, latency and final credits.
5. Add explicit handling for refusal stop reasons and test the customer-visible message.
6. Compare quality and reviewer time, then set the default only after the result is repeatable.

Where Sonnet 5 fits in Modalis

Sonnet 5 is available from the Premium plan with a six-credit minimum per request in the verified catalog. Actual consumption can exceed the floor when token or component cost requires it. Its strongest initial candidates are coding assistance, structured knowledge work, document synthesis and agentic flows that benefit from tool use but do not need the highest Claude tier.

The decision against Opus 5 should be empirical. Start with Sonnet 5, record the failure cases, then replay only those cases on Opus 5. This produces a routing policy grounded in the hard tail of the workload instead of paying the largest-model premium for every easy request.

What a successful migration should prove

A successful migration is not merely a request that returns HTTP 200. It should show that the new model preserves the required output contract, stays within a defensible latency range and produces a predictable balance between visible answer and thinking usage. If token counts rise while reviewer time falls, the change may still be economically positive; if the answer is longer but no more acceptable, the extra usage is waste.

Keep a small Sonnet 4.6 control group during the first production window. Compare the same workflow categories rather than random traffic, and attach the model version to every record. That makes it possible to distinguish a model regression from a changed prompt, a provider incident or a customer-data shift. The rollout can be immediate while the measurement remains disciplined.

Compare this migration with the Opus 5, Opus 4.8 and Sonnet 5 routing guide, then validate the commercial effect in the token and credit cost guide.