How do Cached tokens actually get costed?

Does Anthropic's (and others) input_tokens field include cached tokens?

This is one of those small accounting details that can make an LLM cost ledger very wrong. If you use Anthropic prompt caching, input_tokens is not exactly the total amount of prompt context Claude processed.

Anthropic reports uncached input, cache creation and cache reads separately. That means looking at input_tokens alone can dramatically understate the amount of input involved in a request. Take a simple example:

You have 200,000 tokens of conversation history already in cache and add a 50-token question. Anthropic’s own documentation says you can see input_tokens: 50, even though the request effectively contains 200,050 input tokens. The cached portion appears separately as cache_read_input_tokens.

That distinction matters because cached doesn’t mean free.

Anthropic prices ordinary input, cache writes and cache reads differently. So if you calculate cost as input_tokens × normal input price, you're missing a large part of the actual input cost. The correct calculation needs to price each bucket at its own rate (talking about buckets; you're also charged for cache storage/hour), then you add output cost.

In other words, the accurate accounting equation is:

Uncached input cost + cache creation cost + cache read cost + output cost = call cost.

There is another trap here. Two calls can process almost identical amounts of context and still have very different costs depending on how much of that context was read from cache, written to cache or processed as fresh input.

So, “total tokens” isn’t enough either. You need to know what kind of tokens they were.

Caching also changes how you want to think about cost debugging. If your bill rises while traffic and model mix stay broadly unchanged, you should check whether your cache behaviour changed. A prompt edit, reordered tool definition, changing system content or other modification to the cached prefix can turn what was previously a cheap cache read into more expensive fresh input or a new cache write.

Your application continues to behave exactly the same from the customer’s perspective BUT the economics underneath it change. This is why you shouldn’t track only input tokens and output tokens for Anthropic.

You want to preserve input_tokens, cache_creation_input_tokens and cache_read_input_tokens separately for every call, along with the price that applied when the call happened.

Then you can answer the questions about:

• How much did caching save?

• Which workflows stopped hitting cache?

• Where are expensive cache writes happening?

• Did the bill move because usage increased, or;

• because the same usage became more expensive?

Or you could just let Culpa do it. Culpa prices the different token buckets separately and keeps that cost attached to the conversation, feature, customer and workflow that created it.

If you use Anthropic in production, do you currently include cache reads when you calculate your actual cost per conversation? Or are you using input_tokens as the whole input number?

Tomorrow we'll look at OpenAI and see how they handle the exact same field completely differently.