Why your Claude bill doesn't match your token count

The mismatch that starts the investigation

You counted tokens before sending a request, the count looked reasonable, and the invoice at the end of the month is higher than that count times the advertised rate would predict. This is one of the more common support-style questions around Claude billing, and it's rarely a billing error — it's almost always one or more costs that a simple "input tokens times rate, output tokens times rate" calculation doesn't account for.

Thinking tokens are billed, and they're invisible in a plain token count

On a model where thinking runs by default, the tokens the model spends reasoning before it produces a visible answer are billed as part of the output, even though they never appear in the response text you actually see. A token count of your input plus a rough guess at output length, based only on what you can read in the response, misses this entirely — the model may have spent a substantial number of tokens thinking that simply aren't visible anywhere in what came back to you. This gap grows with effort level, since higher effort levels are specifically designed to think more before answering.

Cache writes cost more than a standard read, and that's easy to forget

If you've implemented prompt caching, the first request that establishes a new cache entry costs more than a standard read would have — not less, which is the opposite of what "caching saves money" intuitively suggests on a first glance. The savings come from every subsequent read against that cached prefix, not from the write itself. A workload with a lot of short-lived, rarely-reused prefixes can end up paying the cache-write premium repeatedly without ever earning back the savings a read would have provided, which shows up as a bill that's higher than a naive "caching always helps" assumption predicts.

Retries and errors you didn't see still cost tokens

A request that fails partway through, or gets retried automatically by your own error-handling code, can still have consumed tokens on the attempt that failed, depending on where in the pipeline the failure occurred. If your cost tracking only counts successful, completed requests, it's missing whatever was spent on attempts that didn't make it all the way through — and a retry loop triggered by a bug in your own error handling can inflate a bill in a way that's completely invisible if you're only ever looking at successful-response logs.

A model swap mid-month changes your baseline too

If your pipeline switched models partway through a billing period — for cost, capability, or availability reasons — a token count that assumed the old model's tokenizer and pricing no longer describes the second half of that period accurately. This is easy to miss because nothing about the swap itself looks like a billing event; it's a code change that happens to also change what identical input costs. Any reconciliation spanning a period that included a model change needs to split the calculation at the swap date rather than applying one rate across the whole period.

Reconciling the difference

Start from your actual usage block data rather than a pre-send estimate — the usage block Claude's API returns with every response is the authoritative record of what that specific request billed for, input, output, and cache activity all broken out separately. See reading a usage block correctly for how to interpret each field, and the usage tracker for turning a run of those usage blocks into a running picture of where spend is actually going, rather than trying to reconcile a single invoice against a single upfront estimate after the fact.