Prompt caching takes up to ninety percent off repeated input on Claude, but only on the part of the prompt that stays identical. Every time something near the top of the prompt changes, the cache invalidates and you pay full rate again. Understanding what triggers that is the difference between a caching strategy that holds and one that quietly leaks.
Prompt caching is one of the largest cost levers on Claude, and also one of the easiest to undermine without noticing. The promise is simple: when a large block of input appears at the start of many requests, a long system prompt, a document, a set of instructions, the model can reuse the work it already did on that block and charge a small fraction of the full input rate on the repeats. The saving can reach ninety percent on the cached portion, which on a high volume workload is a very large number. But the saving depends entirely on the cached block staying byte for byte identical across requests. The moment it changes, the cache for that prefix is invalid and the next request pays full price to rebuild it. Most caching strategies that disappoint do not fail because caching does not work. They fail because something keeps invalidating the cache, and nobody is watching the hit rate to see it happen.
To see why invalidation matters, you have to see how the cost works. A cached prompt has two prices. The first time the model sees a block, it pays a write cost to store it, which is slightly more than a normal input token. On every subsequent request that reuses the identical block, it pays a read cost, which is a small fraction of the normal rate. The economics are excellent as long as you get many cheap reads for each expensive write. The break even is quick: after a handful of reads the write cost is repaid and everything after is near pure saving. Invalidation breaks this by forcing a new write where you expected a read. If your cache invalidates often, you are paying write costs repeatedly and collecting few reads, which can end up costing more than not caching at all. The hit rate, reads divided by total cacheable requests, is the number that tells you which world you are in.
Caching works on a prefix, the run of content from the start of the prompt up to the first thing that changes. Anything that alters that prefix, or anything before the cached block, invalidates it. The common culprits are predictable once you know to look. A timestamp or a request id injected near the top of the system prompt changes every call and destroys the cache on every call. A personalized greeting or a user name placed before the shared instructions means no two users share a cache. Reordering sections of a prompt between deployments invalidates the lot. Even a trailing whitespace change or a reworded sentence in the middle of an otherwise stable block breaks the cache from that point onward. The pattern is always the same: variable content placed inside or above what should be the stable, cached region.
The damage from invalidation is rarely dramatic, which is why it survives. You do not get an error or an alert. You get a bill that is higher than your caching design promised, and a hit rate quietly sitting at thirty percent when it should be near ninety. The effect compounds on exactly the workloads where caching should help most: the high volume ones with large stable prefixes, like retrieval pipelines with a big shared instruction block, or document analysis that re sends the same reference material. On those, a broken cache means you are paying full input rate on enormous prompts thousands of times a day, which is precisely the spend caching was meant to eliminate. The gap between a designed saving and a realized one is almost always an invalidation problem hiding behind a hit rate nobody measured.
The fix is structural, and it is the same idea every time: put the stable content first and the variable content last. Build the prompt so the large, shared, unchanging block, the system instructions, the reference documents, the examples, sits at the top as a clean cacheable prefix, and push everything that varies per request, the user input, the timestamps, the ids, the personalization, to the end where it cannot disturb the cache above it. Freeze the wording of the cached block and change it only on deliberate, batched deployments rather than continuously, because every edit is a fleet wide invalidation. Strip incidental variation like injected metadata and inconsistent whitespace out of the prefix entirely. The goal is a prompt whose first several thousand tokens are identical across every request that should share a cache, with all the difference concentrated at the bottom.
Because invalidation is silent, the only defense is to measure. Treat cache hit rate as a first class cost metric, monitored per workload, not a diagnostic you check once at launch. A hit rate that drops after a deployment is a signal that a change touched the cached prefix, and catching it the day it happens saves the weeks of inflated bills that would otherwise accrue before someone investigated the cost. The teams that hold their caching savings are the ones that put the hit rate on a dashboard next to spend and react when it moves, the same way they would react to a latency regression. Caching is not set and forget, it is set and watch, because the prompt evolves and every change is a chance to break the prefix.
A caching strategy that actually holds does more than lower the monthly bill. It lowers the baseline you commit to Anthropic against, because your real input cost is a fraction of what an uncached workload would imply. A buyer who commits against a high, leaking baseline locks waste into a multi year deal. A buyer who has the cache working, the hit rate high and the prefix stable, commits to a smaller, truer number and negotiates from demonstrated efficiency. The caching work and the contract work belong together, which is why we do both. The full set of caching patterns, the prompt architecture that keeps the prefix stable, and the monitoring approach that catches invalidation early sit in our token optimization playbook. Download it below and start by measuring your current hit rate, because you cannot fix a leak you are not watching.
Download the token optimization playbook for the prompt architecture and monitoring that keep your Claude cache hit rate high.
Download the playbookWeekly intelligence on Anthropic pricing moves and the buyer side counters that work.