Claude Sonnet 5 launched on 30 June 2026 at $3 per million input tokens and $15 per million output tokens. Same rate card as Sonnet 4.6, 40% below Opus 4.8’s $5/$25. On price alone, it looks like the default choice.
But independent benchmarks from Artificial Analysis show Sonnet 5’s real cost at roughly $2.29 per completed task, about 15% more than Opus 4.8 and nearly double what teams pay on Sonnet 4.6. The per-token rate stayed the same while token volume increased, and that is what drives the cost gap.
Three things are behind it, and the first one kicks in before the model generates a single word.
How does Claude Sonnet 5’s new tokenizer work, and why does it inflate token counts by up to 35%?
Claude Sonnet 5 uses the same-generation tokenizer introduced with Opus 4.7, which segments text into finer-grained units than the tokenizer used by Sonnet 4.6 and every prior Claude model. Anthropic’s documentation puts the increase at approximately 30%. A prompt that cost 1,000 tokens under Sonnet 4.6 now registers as roughly 1,300 under Sonnet 5. It is an architectural trade-off: the finer tokenizer enables better reasoning fidelity at the cost of token efficiency.
That ~30% inflation is not uniform. Simon Willison’s testing pegged English prose at 1.33 to 1.42 times more tokens and Python code at 1.27 to 1.28 times. Code and structured data inflate differently to natural language, which means per-category ratios are more useful than a single average.
A concrete example: 100,000 tokens of codebase context under Sonnet 4.6 costs $0.30 in input. The same codebase under Sonnet 5 clocks in at about 130,000 tokens and costs $0.39. A seemingly identical API call is 30% more expensive before the model writes a single output token. Scale that across thousands of daily calls and the monthly difference adds up.
Anthropic tells developers to re-run token counting on actual prompts rather than reusing Sonnet 4.6 numbers. There is a second knock-on effect: the 1M-token context window holds less actual text than it did on Sonnet 4.6. A codebase that previously consumed 850,000 tokens might now register at roughly 1.1 million, overflowing the window. Token re-baselining is a migration prerequisite, not an optional step (see our full model comparison and production evaluation guide).
There is a temporal dimension too. During the introductory pricing window through 31 August 2026, Sonnet 5 bills at $2/$10. Anthropic describes the introductory rate as making the transition “roughly cost-neutral”, which is a roundabout way of saying the discount offsets the tokenizer inflation. From 1 September, standard pricing of $3/$15 applies. Teams benchmarking today against the introductory rate will see their per-token costs jump by 50% in September. Benchmark against standard pricing now, even if your current invoices show the lower rate.
The tokenizer change is permanent. Budget as though the inflation factor is here to stay. The tokenizer alone makes per-token comparisons unreliable; extended thinking and agentic compounding make them actively misleading.
Why does Claude Sonnet 5 cost more per completed task than Opus 4.8 despite having a lower per-token price?
The tokenizer is the silent cost multiplier, but it is not the only thing inflating your token count. Extended thinking tokens and agentic workflow compounding do the rest, and together they invert the cost ranking the rate card suggests.
Extended thinking tokens are reasoning tokens the model consumes internally before producing a visible response. They are billed at output rates but never appear in what you receive back. At high effort on a complex multi-step task, thinking tokens can add 40 to 60% to the total token count. None of it shows up in the response. All of it shows up on the invoice.
Agentic workflow compounding makes things worse. In an agentic loop, the model’s output at step one becomes part of the input context at step two. A 30% increase in verbosity at each step compounds multiplicatively across the full task. Artificial Analysis found that at max effort, Sonnet 5 used roughly 40% more output tokens per Intelligence Index task than Sonnet 4.6 and about three times the agentic turns on knowledge work evaluations (see also how agentic behaviour changes the cost equation).
Walk through a worked example. A debugging task that costs 15,000 tokens on Sonnet 4.6, about $0.27 total, might cost 25,000 tokens on Sonnet 5, about $0.54 at standard pricing. The input grows from roughly 10,000 to 13,000 tokens from tokenizer inflation (extra $0.09); thinking tokens add roughly 5,000 billed tokens that never appear in the response (another $0.09); and output verbosity adds roughly 4,000 extra tokens versus what Sonnet 4.6 would have produced ($0.09 more). The per-token rate stays flat while the three drivers nearly double the total token count.
The benchmark data bears out the tension. At low to medium effort on simple tasks, Sonnet 5 delivers better value than Opus 4.8. The per-token discount wins when thinking overhead is minimal. But at high effort on complex agentic work, the token volume swamps the per-token discount. Sonnet 5 scores 63.2% on SWE-Bench Pro to Opus 4.8’s 69.2%, and on Terminal-Bench 2.1 it trails 80.4% to 82.7%. On knowledge benchmarks, Sonnet 5 narrows or matches Opus 4.8 (discussed in the effort-level analysis below), but the thinking token overhead means you often pay more for near-parity. After the September pricing step-up, the gap widens further.
Cross-model comparisons get complicated because providers bill reasoning tokens differently. OpenAI charges reasoning tokens at output rates for GPT-5.5 ($1.25/$10 per million tokens), while Anthropic bills them as standard output tokens. GPT-5.5 looks cheaper on the rate card, but the cost-per-task winner depends on your specific workload, not the sticker price (see our full model comparison for benchmark-level detail).
Prompt caching and the batch API offer partial offsets. Cache reads bill at one-tenth of the base input price, so repetitive workloads can claw back some of the tokenizer inflation. Batch processing at a 50% discount makes Sonnet 5 cost-competitive for overnight classification and data extraction jobs. But the latency trade-off excludes real-time agentic use cases, and that is where most of the cost pressure lives (see our production evaluation guide for a practical adoption framework).
What are effort levels in Claude Sonnet 5, and how do they change the real cost of using the model?
Effort levels, low through medium, high, xhigh, and max, control how many internal reasoning tokens Sonnet 5 consumes before producing a visible response. Higher effort means more thinking tokens. More thinking tokens means a higher bill.
But here is what catches teams migrating from Sonnet 4.6: adaptive thinking is enabled by default on Sonnet 5. On Sonnet 4.6, extended thinking was opt-in. A request without an explicit thinking field now consumes reasoning tokens the developer may not have budgeted for. Manual thinking budgets, the budget_tokens parameter, return a 400 error on Sonnet 5. Teams must switch to effort-based control via the effort parameter. Non-default sampling parameters like temperature and top_p also return 400 errors; behaviour must be steered through system prompts instead. This is the moment your bill starts climbing without an obvious explanation.
The five tiers map to use cases. Low effort suits classification, extraction, and routing tasks where reasoning overhead is waste. Medium handles standard coding work. High targets complex multi-step agentic tasks. Xhigh and max are for accuracy-critical reasoning where marginal quality improvements justify the additional spend. On classification and extraction tasks, low effort rarely degrades quality because these tasks do not benefit from extended chain-of-thought reasoning. The model does not need to deliberate over whether an email is a refund request.
The counterintuitive finding is that at high effort, Sonnet 5 can cost more than Opus 4.8 while delivering marginally less capability. On Humanity’s Last Exam, Sonnet 5 at high effort scores 57.4% to Opus 4.8’s 57.9%, a near tie. But the thinking token overhead means you pay more for that near-parity. At low effort on simpler workloads the calculus flips: Sonnet 5 delivers strong performance at meaningful cost savings, making it the rational choice for high-volume classification and extraction. For the full benchmark breakdown, see our analysis of Sonnet 5’s benchmarks and safety evaluations.
Effort levels need governance. Without it, teams default to high effort for all tasks, maximising cost without measuring whether the extra thinking actually improves outcomes. The right approach classifies tasks by complexity and matches effort levels accordingly, then tracks a handful of monitoring signals to confirm the calibration is working. reasoning_token_ratio tells you what fraction of each call’s billed tokens went to internal reasoning rather than visible output. cost_per_successful_task measures total spend per completed request rather than the abstract per-token rate. p95_latency_by_effort surfaces how effort settings affect response times at the tail. Because effort level, not prompt length, is the dominant cost variable, a short prompt at xhigh effort can cost more than a long prompt at low effort. For guidance on building this into your migration, see our production evaluation guide and model comparison.
The per-token rate card tells you what Anthropic charges per unit of computation. It does not tell you how many units your workload will consume. The tokenizer, the thinking tokens, and agentic verbosity multiply the token count in ways the rate card was never designed to surface.
Sonnet 5 is not a bad model. At low to medium effort on classification and extraction workloads, it delivers strong value. The problem is that the rate card obscures the workload-specific calculus teams need to find those sweet spots. Re-baseline token counts on your actual prompts, classify your task types by complexity, match effort levels to task classes, and track cost_per_successful_task as your north-star metric. Start with the rate card, but measure against cost per successful task.
Frequently Asked Questions
What happens to my costs when the September 2026 introductory pricing ends?
Your per-token cost jumps by 50 percent overnight. During the introductory window, Sonnet 5 bills at $2/$10 per million tokens; from 1 September 2026, standard pricing of $3/$15 applies. For a team processing 10 million input tokens daily, that is roughly $300 per month in additional input costs alone, before accounting for output tokens and thinking overhead. Benchmark against standard pricing now, even if your current invoices show introductory rates.
Is the tokenizer inflation a bug, or is it here to stay?
It is neither a bug nor temporary. The finer-grained tokenizer is the same architecture that shipped with Opus 4.7, and it reflects an intentional trade-off: smaller token units improve reasoning fidelity on code and structured data at the expense of token efficiency. Anthropic has shown no indication of reverting to the older tokenizer, and doing so would likely degrade the model’s benchmark performance. Budget as though the inflation factor is permanent.
Should I just stick with Claude Sonnet 4.6 instead of migrating?
For high-volume classification and extraction workloads where Sonnet 4.6 already meets your quality bar, staying put may be the rational cost decision. Sonnet 4.6 uses the older, more token-efficient tokenizer and lacks extended thinking overhead, so your current spend per task stays predictable. The trade-off is missing Sonnet 5’s gains on complex reasoning tasks. A split architecture, routing simple tasks to 4.6 and complex tasks to 5, often delivers the best value.
How do I actually re-baseline my token counts for real prompts?
Take a representative sample of your production prompts, not synthetic test data, and run them through Sonnet 5’s token counting endpoint with zero output tokens. Compare the token counts against your Sonnet 4.6 baselines to establish a content-type-specific inflation factor. Code and structured data will inflate more than prose; your average across all prompt types is less actionable than per-category ratios. Automate this measurement and track it as a monitoring metric, not a one-off migration exercise.
Does prompt caching still work the same way on Sonnet 5?
Prompt caching still functions and is essential for offsetting tokenizer inflation on repetitive workloads. Cache reads bill at one-tenth of the base input price, so a 1,000-token cached prefix that now registers as 1,300 tokens costs $0.039 at standard pricing instead of $0.39 uncached. The catch: the effective context window is smaller due to tokenizer inflation, so the amount of content you can keep cached within the 1M-token limit has shrunk. Audit your cache hit rates after migration.
Does setting a low effort level reduce output quality on simple tasks?
On classification, extraction, and routing tasks, low effort rarely degrades quality because these tasks do not benefit from extended chain-of-thought reasoning. The model does not need to deliberate over whether an email is a refund request. Low effort simply tells Sonnet 5 not to burn thinking tokens it will not use productively. Reserve medium and high effort for multi-constraint judgment and complex coding tasks where the additional reasoning steps measurably improve outcomes.
How much do extended thinking tokens actually add to my bill?
At high effort on a complex multi-step agentic task, thinking tokens can add 40 to 60 percent to the total token count you are billed for, and none of those tokens appear in the visible response. At low effort on a simple task, the overhead is negligible. The key variable is effort level, not task length: a short prompt at xhigh effort can cost more than a long prompt at low effort. Track reasoning_token_ratio in your monitoring to surface the thinking overhead per task class.
Is Claude Sonnet 5 a bad model, or is it just priced deceptively?
Neither. Sonnet 5 is a strong model that narrows or matches Opus 4.8 on knowledge benchmarks and delivers genuine value at low to medium effort on classification and extraction workloads. The problem is not the model or the pricing: it is that the per-token rate card is the wrong unit of cost analysis. Teams that switch to cost-per-task measurement will find Sonnet 5 competitive on the right workloads. Teams that stay on per-token rate-card comparisons will systematically underestimate their bills.
How does Sonnet 5 compare to GPT-5.5 on real cost per task?
The comparison is not straightforward because the providers bill reasoning tokens differently; OpenAI charges reasoning tokens at output rates, while Anthropic bills them as standard output tokens. GPT-5.5 lists at $1.25/$10 per million tokens, which looks cheaper on the rate card, but its reasoning token volume and verbosity patterns differ. On Terminal-Bench 2.1, Sonnet 5 edges ahead at 80.4 percent versus 78.2 percent, so the cost-per-task winner depends on your specific workload, not the sticker price.
What happens if I do not set an effort level at all on Sonnet 5?
The model defaults to extended thinking being on, consuming reasoning tokens you may not have budgeted for. This is a breaking change from Sonnet 4.6, where extended thinking was opt-in. If you send a request without an explicit thinking or effort field, Sonnet 5 will use its default reasoning allocation, and those tokens will appear on your invoice. Set effort explicitly for every request class, or you are effectively approving an unbudgeted line item on every API call.
Can I use the batch API to offset Sonnet 5’s higher token volumes?
Yes, but only for async workloads. The batch API offers a 50 percent discount, which makes Sonnet 5 genuinely cost-competitive for overnight processing, bulk classification, and data extraction jobs where latency does not matter. The trade-off is turnaround time: batch requests are processed as capacity allows, not in real time. If your use case requires sub-second responses for agentic workflows, the batch discount is irrelevant, and you need prompt caching and effort-level discipline instead.
