Cache economics and verification
The numbers, and how to prove caching is actually working.
4 min read · Lesson 2 of 9 in this domain
Caching is not free, and knowing the shape of the economics tells you when to bother. Reads are roughly a tenth of the base input price, which is the win. Writes cost more than base — about 1.25× on the five-minute TTL and 2× on the one-hour — which is the price of admission. So caching pays off only when enough reads follow a write: two requests break even on the short TTL, three on the long one. Verification matters as much as configuration, and the field to watch is cache_read_input_tokens: if it is zero across repeated identical prefixes, something is silently invalidating them.
- Cache reads cost roughly 0.1× base input price. Cache writes cost more than base — about 1.25× for the 5-minute TTL and 2× for the 1-hour TTL.
- That write premium is why break-even matters: with the 5-minute TTL two requests break even; with the 1-hour TTL you need at least three.
- Verify with
usage.cache_read_input_tokens. If it is zero across repeated identical-prefix requests, a silent invalidator is at work. - Total prompt =
input_tokens+cache_creation_input_tokens+cache_read_input_tokens. A smallinput_tokensafter a long session means caching is working, not that the conversation was truncated. - Concurrency trap: a cache entry becomes readable only once the first response begins streaming. Firing 20 identical-prefix requests at once means 20 misses and 20 full-price writes. Send one, wait for the first token, then fire the rest.
| usage field | Meaning | Relative cost |
|---|---|---|
| cache_creation_input_tokens | Written to cache this request | ~1.25× (5m) / 2× (1h) |
| cache_read_input_tokens | Served from cache | ~0.1× |
| input_tokens | Uncached remainder | 1× |
Why parallel fan-out misses the cache. You fire twenty requests at once, all sharing a large cached prefix, and every one of them is billed as a full-price write. A cache entry only becomes readable once the first response begins streaming, so twenty simultaneous requests all arrive before any entry exists. Send one, wait for its first streamed token — not the whole response — then release the other nineteen. They read what the first one just wrote.
Reading input_tokens alone and concluding the context was truncated.
What does a cache read cost relative to base input price?
Writes cost more than base — about 1.25x on the 5-minute TTL and 2x on the 1-hour.
input_tokens is small after a long session. What does that mean?
Total prompt = input_tokens + cache_creation + cache_read. Check the sum, not one field.
Practise this domain with 15%%-weighted questions in the study app.
Open in study appSource: Claude Docs — Prompt caching · Independent study aid, not affiliated with or endorsed by Anthropic.