LLM cost · prompt caching · multi-turn · July 2026
Does prompt caching actually save money?
Yes. Prompt caching cuts the cost of a multi-turn LLM conversation by roughly 48–60% total (64–88% on input alone) as of July 2026 — and the savings grow with conversation length, because the stable prefix that gets reused keeps getting bigger. It pays off most for chatbots and agents with a large fixed system + tool prefix.
Every provider advertises caching. The question is whether it moves your bill in the real world, where a conversation resends its entire history on every turn. It does — but not evenly, and not always. Below is the verified math, the per-provider cache read/write rates, a worked example, and the two cases where caching costs you more. Model your own numbers in the Conversation Cost Simulator.
10-turn conversation
output never cached
grows with length
caching can cost more
How it works
Why there is anything to save
An LLM API is stateless. To continue a conversation, your client resends the whole thing — system prompt, tool definitions, and every prior message — as input on every turn. In a 10-turn chat with a 2,000-token system prompt and a 1,000-token tool block, you pay to process 63,500 input tokens even though a single turn is only ~3,200. The same prefix is billed again and again.
Prompt caching stores that repeated prefix on the provider's side. The first time it is sent you pay a one-time cache write; every later turn reads it back at a small fraction of the normal input price — typically about one-tenth. You still pay full price for the new user message, and full price for the model's output, which is never cached. So the more turns share the same prefix, the more reads you get per write, and the bigger the discount.
Per provider
Cache rates and what they save
Every provider prices a cache read and a cache write as a multiplier of its normal input token price. Read is always cheap; the write premium is what varies. Google's near-free writes make it the biggest saver; OpenAI charges no write premium but a higher read; Anthropic sits between. Savings below are for the standard 10-turn conversation.
| Provider | Cache read × input price |
Cache write × input price |
Input cost cut (10 turns) |
Total bill cut (10 turns) |
|---|---|---|---|---|
| Anthropic Claude | 0.10× | 1.25× | 72.8% | ~52% |
| OpenAI GPT | 0.25× | 1.00× | 63.8% | ~48–49% |
| Google Gemini | 0.10× | 0.25× | 87.8% | ~60% |
Multipliers apply to each model's own input price. Total-bill cut is smaller than input cut because output tokens are billed in full. OpenAI caching is automatic (no write premium; higher read rate). Snapshot of published rates, July 13, 2026.
The math
One worked example, verified
Take Claude Opus 4.8 — input $5 / 1M, output $25 / 1M, Anthropic caching (read 0.1×, write 1.25×) — on the standard 10-turn conversation. The input grows every turn as history piles up; total input is 63,500 tokens, total output 5,000.
Without caching Total input 63,500 tok x $5 /1M = $0.3175 Total output 5,000 tok x $25 /1M = $0.1250 Per conversation = $0.4425 -> $442.50 / 1,000 With prompt caching Cache reads 54,000 tok x 0.10 = 5,400 tok-equiv Cache writes 9,500 tok x 1.25 = 11,875 tok-equiv Cached input 17,275 x $5 /1M = $0.0864 (input down 73%) Output (never cached) = $0.1250 Per conversation = $0.2114 -> $211.37 / 1,000 Saved by caching = 52% of the total bill
Input cost dropped 73% ($0.3175 → $0.0864), but because the $0.125 of output can't be cached, the total bill dropped 52%. That gap — input savings always larger than total savings — holds on every provider. The same shape on Gemini 3.1 Pro cuts input 88% and the total 60%; on GPT-5.6 it cuts input ~64% and the total ~48%.
The key insight
Savings grow with conversation length
This is the part single-prompt price pages miss. The longer a conversation runs, the more times the cached prefix is read per write — so the discount compounds. Here is the same model (Claude Sonnet 5, $2 / $10) at different lengths. Note the top row: on a one-shot, caching actually costs more.
| Turns | No caching $ / 1,000 conv |
With caching $ / 1,000 conv |
Total bill saved |
Input cost saved |
|---|---|---|---|---|
| 1 (one-shot) | $11.40 | $13.00 | −14.0% | −25.0% |
| 3 | $38.40 | $27.92 | +27.3% | +44.8% |
| 5 | $71.00 | $43.40 | +38.9% | +60.0% |
| 10 | $177.00 | $84.55 | +52.2% | +72.8% |
| 20 | $494.00 | $177.35 | +64.1% | +80.4% |
| 40 | $1,548.00 | $404.95 | +73.8% | +84.8% |
Claude Sonnet 5, standard token sizes (2,000 system + 1,000 tools, 200 user + 500 assistant per turn), Anthropic caching. Break-even is between turn 1 and turn 2. Snapshot July 13, 2026.
Two things fall out of this table. First, caching is a long-conversation optimization: near-worthless (even negative) for a single call, and worth more than a 70% total cut once a chat runs dozens of turns. Second, the bigger your fixed prefix — a long system prompt, a fat tool/function block, retrieved context — the more you have sitting in cache being re-read, so the curve climbs faster. Agents and RAG chatbots with a large stable preamble are the sweet spot.
Decision
When it pays, and when it doesn't
CACHE IT Worth it
- Chatbots & agents. Multi-turn sessions reuse the prefix many times — the deeper the chat, the bigger the cut.
- Large fixed system + tool block. A 2k–10k token preamble sent every turn is exactly what caching is built to discount.
- RAG with a stable context head. Cache the retrieved documents or instructions that don't change between questions.
- High-traffic, back-to-back requests. Frequent hits keep the entry warm inside the TTL, so every turn reads instead of re-writes.
- Few-shot prompts. A long block of static examples reused across calls caches cleanly.
SKIP IT Not worth it
- One-shot calls. Write once, never read back = you pay a write premium for nothing (−14% on our one-turn model for Anthropic/OpenAI).
- Requests spaced beyond the TTL. Anthropic's cache lives ~5 min by default (extendable to 1 hr); OpenAI's automatic cache ~5–10 min. Bigger gaps expire the entry and every turn re-pays the write.
- Output-heavy, input-light work. Caching never touches output tokens, so long generations from short prompts see little benefit.
- Constantly-changing prefixes. If the front of your prompt mutates each call, there's no stable prefix to reuse.
- Tiny prompts. If there's little repeated input, there's little to discount.
Go to source
Official caching docs
Rates and TTLs change without notice. Confirm the current numbers and the exact caching mechanics against each provider before you budget:
- Anthropic — explicit cache breakpoints, 5-minute and 1-hour TTLs, read 0.1× / write 1.25×: docs.anthropic.com · prompt caching
- OpenAI — automatic prompt caching, cached-input discount, no write premium: platform.openai.com · prompt caching
- Google — Gemini context caching (implicit + explicit), read 0.1× / write 0.25× plus storage fee: ai.google.dev · context caching
Caveats. These figures use a fixed synthetic conversation and published list prices, and assume a cache hit on every turn after the first (requests inside the TTL). They exclude Google's per-hour cache storage fee, batch discounts and context-length premiums. Real conversations vary in length and token mix — treat this as a planning model, then verify against your provider's usage dashboard.
Put it to work
Three ways to use these numbers
Should you cache at all?
If your prefix is large and reused within the TTL, yes. If you're firing one-shots or requests are minutes apart, the write premium can erase the benefit — check the length table first.
Estimate the saving
Halve your input bill as a rough first pass (~48–60% off the total). For a precise figure, model your real turn count, prefix size and provider in the simulator.
Place the breakpoint right
Cache the stable head — system prompt, tools, retrieved context — not the volatile tail. A cache that misses because the prefix shifted saves nothing.
FAQ
Common questions
Does prompt caching actually save money?+
Yes. On a standard 10-turn conversation, caching cuts total cost by ~48–60% depending on provider, and input tokens by ~64–88%, at July 2026 list prices. The saving is real because the same system prompt and history are resent every turn, and caching reads that repeated prefix at roughly a tenth of the normal price. Output tokens are never cached, which is why the total cut is smaller than the input cut.
How much does prompt caching save?+
For a standard 10-turn conversation: about 48% on OpenAI, 52% on Anthropic, 60% on Google of the total bill; on input alone, ~64% / 73% / 88%. Concretely: 1,000 ten-turn conversations on Claude Opus 4.8 cost ~$442 without caching and ~$211 with it — a 52% saving.
Is prompt caching worth it?+
Worth it whenever a large, stable prefix is reused within the cache TTL — chatbots, coding agents and tool-using assistants are the clearest wins. The saving grows with length: ~27% at 3 turns, 52% at 10, 74% at 40 on the same model. Not worth it for one-shot calls with no reuse, or when requests arrive far apart, because you pay a write premium once and never read it back.
Why do caching savings grow with conversation length?+
Because APIs are stateless: the client resends the whole history every turn, so the repeated prefix gets bigger and is read more times the longer the chat runs. You pay the write premium once per chunk but read it back on every later turn at ~10% of the price. On a Sonnet-class model the total-cost saving climbs from ~27% at 3 turns to 52% at 10 and 64% at 20.
When does prompt caching NOT save money?+
On a single one-shot request. On Anthropic and OpenAI a cache write costs more than a normal input token, so writing a prefix you never read back costs a premium — ~14% more on a one-turn call in our model. It also fails when gaps between requests exceed the TTL (Anthropic ~5 min default, extendable to 1 hr; OpenAI ~5–10 min), since the entry expires and every turn re-pays the write. And it never discounts output.
Does caching reduce the cost of output tokens?+
No. Caching only discounts the repeated input prefix. Generated output is always billed at the full output rate, and on reasoning models the internal thinking tokens are billed as output too. That's why a conversation's total-cost saving (48–60%) is always smaller than its input-only saving (64–88%): the un-cacheable output dilutes the discount on the total bill.
Run your own numbers