Does Anthropic input_tokens include cached tokens?
Not all of them. Anthropic reports ordinary input, cache creation and cache reads in separate usage fields. Culpa preserves these separate buckets before pricing them, so the cost attached to your conversation, feature and customer doesn’t quietly leave cached usage out.
Anthropic’s pricing documentation tells you to calculate total input by adding input_tokens, cache_creation_input_tokens and cache_read_input_tokens. It also prices ordinary input, cache writes and cache reads differently.
🧾 not so fast though; that creates an easy spreadsheet mistake. If you take input_tokens and treat it as the whole request, you'll see that cached context can disappear from your calculation even though Anthropic still reports and prices that usage separately.
Let't take an illustrative request with 200,000 tokens already available through cache and 50 new ordinary input tokens. The ordinary input field can represent the new 50 tokens while the cached portion appears separately as cache-read input. If you price only those 50 ordinary tokens, your number doesn’t represent the whole request.
The correct approach is to keep the buckets separate. Price ordinary input at its applicable rate, price cache reads at the cache-read rate, price cache writes where they occur, then add the output cost.
💡 This also explains why two requests with similar context sizes can have very different economics. One may reuse almost everything from cache, while another may need to write or process much more of the same context again.
So when your Anthropic bill changes while traffic looks normal, check cache behaviour before assuming customers suddenly became more expensive.
Use your own data to inspect your expensive conversations with the free Cost Leak Scan. No card and no account:
If you calculate Anthropic cost yourself today, are you pricing all three input buckets or only input_tokens?
Replies