Prompt caching is how most Claude bills actually come down

Prompt caching reuses the stable prefix of a Claude prompt so you do not pay full price to re-read the same system instructions, tool schemas and retrieval boilerplate on every turn. It is the highest-leverage cost control we install on inherited agents.

The typical overspend we measure is about 3.4x, usually from context that did not need to be there. Teams notice the invoice before they notice the architecture. Caching without a context budget just makes a bloated prompt cheaper. Do both.

What belongs in the cache

Put the parts that change rarely in the cached prefix:

• System prompt and policy
• Tool schemas
• Static few-shot examples
• The retrieval instructions, not the retrieved documents

Leave user turns, live records and per-request retrieval outside the cache. If those land in the prefix, you invalidate the cache constantly and pay twice.

Measure the right unit

Cost per token is a vendor metric. Cost per successful task is an operating metric. Pair caching with eval gates so a cheaper prompt is not a worse prompt.

Also watch latency. A huge uncached prefix is slow and expensive. Caching helps both, which is why it belongs in week one of a production agent build, not after finance escalates.

A simple sequence

1. Trace ten real tasks and list every token source.
2. Split stable versus per-request context.
3. Enable caching on the stable prefix.
4. Cap retrieved chunks and conversation history.
5. Re-run the golden set and compare spend and pass rate.

If the bill is the reason the pilot cannot go live, start with this sequence, then read context engineering for Claude. The two problems are usually the same problem.