Prompt caching is the most under-used line item in LLM pricing. It’s not a new model or a clever prompt trick — it’s a billing feature that, for a lot of real workloads, cuts the input half of your bill by around 90%. In our 2026-07-14 snapshot, 168 of 315 paid models publish a cache-read price, and across those the average discount versus fresh input is 79% — rising to a clean 90% on the major models. Most teams leave it on the table because the savings are invisible until you do the arithmetic. So let’s do it.
What caching actually charges for
Every call has some input you send fresh and, often, a large chunk you send again and again — a system prompt, tool/function definitions, a few-shot block, or retrieved documents that don’t change between calls. Caching lets the provider store that fixed chunk and charge you a reduced “cache-read” rate to reuse it, instead of the full input rate every time.
There are three prices in play:
- Fresh input — the normal input rate.
- Cache read — what you pay to reuse a cached chunk. On the majors, ~10% of the input rate.
- Cache write — a one-time premium to store the chunk, typically around 1.25× the input rate, charged when the cache is cold or has expired.
From our data, the read discounts on major models are strikingly uniform:
| Model | Fresh input / 1M | Cache read / 1M | Discount |
|---|---|---|---|
| Claude Opus 4.8 | $5.00 | $0.50 | 90% |
| Claude Sonnet 5 | $2.00 | $0.20 | 90% |
| GPT-5.6 Luna | $1.00 | $0.10 | 90% |
| GPT-5.6 Terra | $2.50 | $0.25 | 90% |
| Gemini 3.1 Pro Preview | $2.00 | $0.20 | 90% |
| DeepSeek V4 Pro | $0.435 | $0.0036 | 99% |
DeepSeek is the outlier — a 99% cache-read discount, which turns reused context into almost nothing.
The worked example
Take a retrieval-augmented app: a fixed 8,000-token context (system prompt + reference docs) sent on every call, 100,000 calls a month, running on Claude Opus 4.8.
Without caching, that repeated context alone is:
8,000 × 100,000 = 800M input tokens/month × $5 / 1M = $4,000/month
— just to re-send the same 8,000 tokens over and over.
With caching, the same 800M tokens are billed at the cache-read rate:
800M × $0.50 / 1M = $400/month
That’s $3,600 saved every month on one workload, from a feature you enable rather than build. Even after the one-time write premium (roughly 8,000 tokens × $6.25/1M ≈ $0.05 each time the cache is populated — negligible against steady traffic), the read savings dominate overwhelmingly.
On DeepSeek V4 Pro’s 99% discount, the same 800M reused tokens cost about $2.90/month instead of $348. Caching is often the difference between “this feature is too expensive to ship” and “this feature is free.”
When caching pays — and when it doesn’t
Caching wins when:
- A large chunk repeats across calls. Long system prompts, big tool schemas, few-shot examples, shared document context. The bigger and more repeated the prefix, the bigger the win.
- Traffic is steady. Caches have a short time-to-live (often minutes). You need enough call frequency to hit a warm cache before it expires; sparse, bursty traffic keeps paying the write premium.
- The cached content is a stable prefix. Most implementations cache from the start of the prompt up to the first thing that changes. Keep your fixed content at the front and your variable content (the user’s actual query) at the end.
Caching does little or nothing when:
- Every prompt is unique — a one-shot classifier with no shared preamble has nothing to cache.
- The repeated chunk is small — caching 200 tokens of system prompt saves 200 × 90% of a fraction of a cent. Not worth the complexity.
- You reorder or edit the prefix between calls — any change near the front invalidates the cache below it, forcing a re-write.
The one design rule
If you take one thing from this: put your fixed content first, your variable content last. Cache the stable prefix, and structure prompts so the expensive-to-recompute part never moves. That single ordering habit is what turns a 90% headline discount into an actual 90% cut on your input bill.
Cache rates track alongside input prices and change with them — the figures here are from 2026-07-14. Each model’s page on computetrail lists its cache-read price next to its fresh input price, so you can check the real discount on the model you’re actually running before you architect around it.
Figures from computetrail’s 2026-07-14 price snapshot. Cache availability, discount, and time-to-live vary by provider — verify against current provider docs. See our methodology.