Four reasons your Claude bill does not match the calculator

What happened

Four things separate a token estimate from an invoice on the Claude API. All four are documented by Anthropic. None of them are modelled by the character-count heuristics most teams use, and the first has a date on it.

The price rise, four weeks out

Claude Sonnet 5 has been running on introductory pricing of $2 per million input tokens and $10 per million output. That runs through 31 August 2026. From 1 September 2026 the standard rate applies: $3 and $15, a fifty per cent increase on both sides.

If Sonnet 5 is carrying your production traffic, next month's bill rises by half on the token line without anyone changing anything. Batch pricing moves with it, from $1/$5 to $1.50/$7.50.

Sonnet 5 pricing, as published

1. Now, to 31 Aug 2026

   Introductory pricing

   $2 per million input, $10 output. Batch $1 / $5.

2. 1 Sep 2026

   Standard pricing applies

   $3 per million input, $15 output. Batch $1.50 / $7.50. A 50% increase on both sides of the token line.

Cache writes cost more than input, at two different rates

Prompt caching is usually described as a saving, and it is, but only after it pays back. The multipliers relative to base input price:

Every modifier that moves the token line

Modifier	Effect	Applies to	Pays back after
5-minute cache write	1.25x base input	Tokens written to cache	One cache read
1-hour cache write	2x base input	Tokens written to cache	Two cache reads
Cache read (hit)	0.1x base input	Tokens served from cache	n/a
Batch API	50% discount	Input and output	n/a
Data residency, US-only	1.1x	Every category, including cache writes and reads	n/a
Fast mode, Opus 5 and 4.8	$10 / $50 per MTok	Full context window	n/a

So writing to the cache is more expensive than not caching at all. A 5-minute write pays for itself after a single read. A 1-hour write needs two. A workload that writes a large cached prefix and then does not reuse it enough, because sessions are short or traffic is spiky, spends more on caching than it saves. Estimates that model caching as a flat discount get this backwards precisely when it is going wrong.

What one cached request actually costs, against the calculator's assumption

Cache write, 1 hour200x

Cache write, 5 minutes125x

Plain input, what the calculator assumes100x

Cache read10x

The multipliers stack

Batch processing is a 50% discount. Data residency, pinning inference to the US on Claude 4.6 and later, is a 1.1x multiplier that applies to every token category including cache writes and cache reads. Fast mode on Opus 5 and Opus 4.8 is separate pricing again, at $10 and $50.

These compose rather than replace each other. A batched, cached, US-resident request is priced through three modifiers, and reasoning about it as a single headline rate will be wrong in both directions depending on which you forgot.

The tokenizer changed, and nothing tells you

This is the one that catches people, because it is genuinely invisible.

Claude 4.7 and later use a new tokenizer that produces approximately 30% more tokens for the same text. Claude Sonnet 4.6 and earlier use the previous one.

Nothing about your prompt changed. No price changed. The same string is simply more tokens now, so it costs more to send. Independent measurement suggests the effect is uneven: code and structured input are hit harder than prose, because the new vocabulary represents them in smaller pieces.

Every estimate built on "roughly four characters per token" is wrong across the entire Claude 4.7 and later line, and wrong by a different amount depending on whether you are sending English or TypeScript. So is every spreadsheet that multiplies last quarter's token counts by a new model's rate, because the token counts themselves move.

Why a calculator cannot be right about this

It is tempting to read all this as calculators being carelessly built. Most of the error is structural, and knowing which part is which tells you what to do instead.

A calculator sees a number of characters and a model name. From that it can know the published per-token rate, and nothing else. It cannot know how your text tokenises, because that depends on a tokeniser the vendor does not publish. It cannot know your cache hit rate, because that depends on the shape of your traffic. It cannot know whether a given request wrote the cache or read it, and those differ by a factor of twenty. And it cannot know about a price change that took effect after the page was last edited.

Four unknowns, each of which moves the answer by more than the precision the calculator is displaying. A figure quoted to two decimal places from inputs like that is a confidence signal, not an estimate.

So the useful substitute is not a better calculator. It is one real request, sent, with the usage block from the response read and multiplied. That takes about ten minutes, it accounts for all four unknowns automatically, and it is the only method that stays correct when the vendor changes something without announcing it.

What to do about it

• Diary the 1 September change now if you run Sonnet 5, and re-run whatever business case justified the model choice at $3/$15 rather than $2/$10.
• Measure your own tokenizer delta with the count_tokens endpoint rather than trusting a published average. Run your actual production prompts through it against an older and a newer model. Thirty per cent is the documented approximation; your content decides your number.
• Check whether caching is paying back. Compare cache write tokens against cache read tokens in your usage data. If reads are not comfortably exceeding writes, the cache is a cost rather than a saving, and the 1-hour duration needs twice the reuse the 5-minute one does.
• Price the composition, not the headline. If you use batch, caching or data residency, model them as multipliers applied together.
• Stop estimating from character counts. The heuristic was never accurate and is now wrong by a moving amount that differs per model generation.