I would treat a move from Sonnet 4.6 to Sonnet 5 as a routing experiment, not a dependency bump. The advertised token price is only one input. Adaptive thinking, a different tokenizer, cache behavior, and rejected request parameters can all change the production result.
The question I care about is whether the new model finishes the same work reliably, with less total spend and acceptable latency. That means comparing Sonnet 4.6, Sonnet 5, and Opus 4.8 under the same evaluation criteria.
Establish the API Contract First
According to Anthropic's model overview and pricing documentation, Sonnet 5 uses claude-sonnet-5, supports a 1M-token context window, and has a 128k-token maximum output. The migration starts from claude-sonnet-4-6, but there are behavioral changes beyond the identifier.
| Contract | Sonnet 5 behavior |
|---|---|
| Thinking | Adaptive thinking enabled by default |
| Default effort |
high on Claude API and Claude Code |
| Manual extended thinking | Manual budget-token mode removed |
| Sampling | Non-default temperature, top_p, and top_k return HTTP 400 |
| Tokenization | Approximately 30% more tokens for the same text is possible; workload-dependent |
I would audit the request builder before running quality evaluations. Shared SDK wrappers often inject sampling settings into every request. Anthropic's API release notes say unsupported non-default values are rejected, not silently ignored. A good model cannot help a request that fails validation.
Search for hardcoded temperature, top_p, and top_k, add model-specific validation, and remove assumptions about manual thinking budgets. Retest max_tokens too. Keep a Sonnet 4.6 route available while checking compatibility, particularly where existing prompts depend on sampling controls or explicit thinking budgets.
Price the Work, Not Just the Tokens
Sonnet 5 has two pricing periods. I would include both in an evaluation report so an introductory discount does not become an accidental long-term budget assumption.
| Model or pricing period | Input per MTok | Output per MTok |
|---|---|---|
| Sonnet 5 through August 31, 2026 | $2 | $10 |
| Sonnet 5 after August 31, 2026 | $3 | $15 |
| Sonnet 4.6 standard pricing | $3 | $15 |
| Opus 4.8 standard pricing | $5 | $25 |
The Sonnet 5 documentation notes that its tokenizer can produce approximately 30% more tokens for the same text. That is a planning estimate, not a multiplier I would apply blindly. Recount actual production prompts, especially long documents and repository context.
My primary metric would be effective cost per solved task = (primary model cost + retry cost + fallback cost) / successful tasks. More tokens can still be economical if the model eliminates retries or Opus calls. Conversely, a lower per-token rate is not useful if task quality stays flat while token consumption rises.
Human review also belongs in the comparison, even when it is tracked separately from API spend. A workflow that needs fewer manual edits may be preferable to one with a smaller bill but substantially more review work.
Three Places I Would Expect Surprises
Thinking Spend Can Exceed What the Answer Suggests
Anthropic's extended thinking guide states that thinking tokens are billed as output tokens. A short final answer therefore does not imply a cheap request. Log usage.output_tokens; visible response length is not a substitute.
Sonnet 5 uses effort to control thinking depth, with high as the default on Claude API and Claude Code. For routing and deterministic classification, I would test low, medium, and disabled thinking against the same accuracy criteria. The documented configuration for disabling thinking is this request-body fragment:
{
"thinking": {
"type": "disabled"
}
}
When reasoning remains useful, keep adaptive thinking enabled and choose effort deliberately using the effort documentation. Record the actual setting on every evaluation run, then compare output-token usage and p50/p95 latency across all three models. Also inspect tasks where Sonnet 5 succeeds but spends enough on reasoning that Opus 4.8 becomes competitive.
Cache Economics Need a Fresh Baseline
Long-context research, support automation, and multi-step agents can depend heavily on prompt caching. A changed token count affects cached-input cost assumptions, but that alone does not establish how cache behavior will change. I would verify tokenization and cache usage independently.
Recount long prompts, inspect cache breakpoints and cache-control placement, and monitor cache_creation_input_tokens alongside cache_read_input_tokens. Alert on cache-read drops and cache-creation spikes during migration. Anthropic's prompt caching guide is the reference here; a strategy that worked economically on Sonnet 4.6 still needs measurement on Sonnet 5.
Request Errors Need Their Own Rollout Gate
I would separate request compatibility from answer quality. Track HTTP 400 rate in canary traffic, with error-rate alerts before expanding the rollout. Otherwise, unsupported parameters can look like a general model reliability regression.
Do not retire the Sonnet 4.6 fallback until parameter validation is clean. Keep that rollback mechanism distinct from the Opus fallback used when a valid request produces an insufficient result: those are different failure modes with different fixes.
Use Benchmarks to Choose Tests, Not Production Routes
Anthropic's published comparison reports 63.2% on SWE-bench Pro for Sonnet 5 versus 58.1% for Sonnet 4.6, and 80.4% on Terminal-Bench 2.1 versus 67.0%. Humanity's Last Exam with tools rises from 46.8% to 57.4%. Those results make coding, tool use, and agentic workflows sensible first evaluation targets.
The gap to Opus still matters. Sonnet 5 trails Opus 4.8 by 6.0 points on SWE-bench Pro and 2.3 points on Terminal-Bench 2.1, while improving over Sonnet 4.6 by 5.1 and 13.4 points, respectively. That supports testing whether Sonnet can handle more of a workload; it does not establish that Opus is unnecessary.
I would also keep effort attached to any benchmark cost claim. Chubby's published comparison shows Sonnet 5 moving from roughly $2+ per task at low effort toward $5–$7 at higher effort. Those chart observations are not universal workload prices, but they explain why an evaluation without an effort setting is incomplete.
Public discussion is useful as a source of test hypotheses. TestingCatalog's launch thread surfaced benchmark comparisons, and Kilo Code's availability note reflected early developer-tool adoption. The Hacker News discussion, r/singularity thread, and early r/ClaudeAI reports raise questions about token usage and Opus comparisons. I would use official documentation for the API contract and those reports to identify what to retest.
Run a Small Evaluation That Includes Failure Costs
I would start with 20 real tasks covering repository bug fixes, tool-calling workflows, long-context synthesis, support-ticket triage, code review, SQL or data analysis, and multi-step agent work. Run the same tasks on Sonnet 4.6, Sonnet 5, and Opus 4.8 with consistent prompts and review criteria.
For each run, capture the model, effort, input tokens, output tokens, cache creation and read tokens, retries, latency, HTTP 400 errors, manual edits, and final pass/fail result. Identify reasoning-heavy requests through output-token deltas and any available usage breakdown. Aggregate solved-task rate, average input/output tokens, retries and latency per successful task, human review time saved, and Opus fallback rate.
A unified multi-model API such as CometAPI can be useful for running those comparisons through one integration; its cookbook includes setup patterns for Claude Code, Codex, LiteLLM, LangChain, Langfuse, and Promptfoo. Regardless of the transport, keep model settings and usage telemetry explicit.
Before expanding traffic, verify that cache hit behavior remains stable, unsupported parameters are gone, token counts fit the intended budgets, and p95 latency remains acceptable. I would evaluate the results at both introductory and standard prices, then decide by workload class rather than selecting one winner for everything.
Keep Opus Where Failure Is Expensive
My starting policy would put medium-complexity, latency-sensitive, or cost-sensitive workflows on Sonnet 5, especially repetitive tasks where retries and review effort are measurable. High-effort planning, multi-file coding, and consequential enterprise decisions would keep an Opus 4.8 route until the evaluation demonstrates otherwise.
Sonnet 4.6 remains a temporary compatibility option where unsupported sampling parameters or manual thinking budgets block migration. That is an integration constraint, not evidence about Sonnet 5's task quality.
The next evidence I would watch is independent coding and agent benchmarks, real tokenizer usage, adaptive-thinking spend, long-context cache behavior, and pricing or availability changes around August 31, 2026. The introductory window is useful for testing. The production decision should survive its end: fewer failed tasks, controlled latency, and a better total cost under standard pricing.
Originally published at cometapi.com
Top comments (0)