Prompt Caching: How Much It Actually Saves

If your prompts share a large, stable prefix - a long system prompt, a knowledge base, a set of examples - prompt caching cost savings are some of the easiest money on the table. Cached input tokens bill at a steep discount, and for the right workload that can cut input cost by most of it.

How it works

When you mark part of your prompt as cacheable, the provider stores the processed prefix for a short window. Subsequent calls that reuse that exact prefix skip most of the compute and bill the cached portion at a fraction of the normal input rate - often around 10% - while a small write cost applies the first time.

Where it pays off - and where it doesn't

• Big win: a 10k-token system prompt or document reused across many requests. The fixed prefix gets cheap; only the per-request tail is full price.
• Modest win: multi-turn chat, where the growing history is partly cacheable turn to turn.
• No win: short prompts, or prompts that change at the top on every call - there's no stable prefix to cache.

The mistakes that bust the cache

1. 01Putting variable content first. A timestamp or user name at the top of the prompt invalidates everything after it. Keep the stable prefix stable and push the variable part to the end.
2. 02Editing the system prompt casually. A one-word tweak busts the cache for every request until it warms again.
3. 03Letting the window expire. Caches are short-lived; low-traffic features may never get a hit. Batch or keep-warm if it matters.

Measure it, don't assume it

The usage block reports cached vs. uncached input tokens. Track the cache-hit ratio so you can see the savings and get alerted when a prompt change silently drops it to zero - this is exactly the kind of regression cost monitoring is for. Caching stacks with picking the right tier in the Claude model cost guide and with the input trimming in token usage limits.