Every major LLM API now knocks about 90% off the tokens you cache. The bill you don't see coming is the fee some providers charge just to put them there.

The read discount is a solved problem

A year ago this table would have had a wide spread. GPT-4o cached at half price, others cached at nothing, and picking a model for cache-heavy work meant real money on the line. That gap has closed. OpenAI, Anthropic, and Google now all bill a cache hit at roughly a tenth of the normal input rate. The number you should hold in your head is 10%: whatever a model charges to read a fresh token, it charges about a tenth of that to read the same token out of cache. On GPT-5.6 Sol that is $5 falling to $0.50. On Claude Opus 4.8 it is the same $5 to $0.50. On Gemini 3 Pro it is $2 to $0.20.

DeepSeek is the one provider that did not stop at 90%. Its V4-Pro cache hit lists at $0.003625 per million, against a $0.435 miss, so a repeated token comes back at under one percent of its first-read price. The V4-Flash tier is even more extreme in relative terms. DeepSeek treats its on-disk cache as close to free capacity and prices it that way, which is a different philosophy from the Western labs that keep cache reads at a fixed fraction of a premium base rate. If your workload is dominated by a large reused prefix, that difference compounds hard.

The write side is where they split

Reading from cache is cheap everywhere. Putting something into the cache is not, and this is the part that trips people up because it is invisible on the pricing page headline. There are three models in play. The first is free and automatic: DeepSeek, Gemini's implicit cache, and every OpenAI model up to GPT-5.5 watch your traffic, notice a repeated prefix, and start serving it from cache without a line of code or a cent of setup. You pay the first read at full price, and every read after that at the discount.

The second model charges an upfront premium to write. Anthropic has worked this way since it first shipped prompt caching. When you mark a block with a cache breakpoint, that first write costs 1.25x the base input rate for the 5-minute tier and 2x for the 1-hour tier. In exchange the reads drop to 0.1x and the window refreshes free on every hit. GPT-5.6 is the news here: it is the first OpenAI family to add a write fee at all, reported at 1.25x, quietly ending the era where OpenAI caching was pure upside. It is still automatic, you just no longer write for nothing.

The third model rents storage. Gemini's explicit context caching, the mode where you create a cache object and hold a handle to it, has no write multiplier but charges storage by the hour, around $4.50 per million tokens on the Pro tier. That flips the cost from a one-time fee into a meter running against wall-clock time, which matters if you cache a big document and then leave it sitting idle. Gemini's implicit cache avoids the meter entirely, so most teams never touch the explicit path unless they need the guaranteed hit.

The write premium amortizes almost immediately

A 1.25x or 2x write fee sounds like it could sink the math, so it is worth pinning down exactly how many times you have to reuse a prefix before caching beats not caching. The logic is simple. Writing costs some multiple of base once; every reuse after that costs 0.1x instead of the 1x you would have paid anyway. The savings per reuse is 0.9x, and the write premium is the hole you have to dig out of first.

Read that table and the write-fee panic evaporates. Even the most expensive case, Claude's 1-hour cache at 2x, pays for itself by the third time you touch the prefix. Any real caching workload, a chatbot with a fixed system prompt, an agent re-sending a tool schema, a RAG app reusing retrieved context, hits the same prefix dozens or hundreds of times. The write fee is a rounding error against that. The only place it bites is a prefix you cache and then use once, which is a mistake regardless of the price.

One document, a thousand questions

Put numbers on it. Say you have a fixed 50,000-token context, a long system prompt plus a reference document, and you send 1,000 requests against it inside an hour. That is a common shape: a support bot answering from a manual, an eval run scoring a rubric, a batch of users querying the same knowledge base. The prefix is identical every time, so the only question is whether you cache it. These figures cover the prefix input only, since caching does not touch your output tokens or the fresh part of each prompt.

The write fee is in these numbers and you cannot find it. On GPT-5.6 Sol the single cache write costs 31 cents against roughly $25 of discounted reads, so the 1.25x premium moves the total by pennies. The headline is the 90% cut, and it holds across every premium model because they all landed on the same 0.1x read. DeepSeek's deeper discount drops the same job to 20 cents, which is the kind of number that makes the on-disk-cache approach look less like a discount and more like a different pricing era.

The two things that quietly break caching

If caching is not saving you what the math promises, the culprit is almost never the price. It is one of two structural limits that never show up in a per-token comparison. The first is TTL. A cache is not permanent; it lives for a short idle window and then falls out, and the next call re-pays the full first-read price to write it again. The second is the minimum. Below a size threshold a provider will not cache a prefix at all, so short system prompts silently run uncached no matter how often you reuse them.

The minimum column is the one that catches people. If your reused prefix is a 400-token system prompt, OpenAI, Anthropic, and Gemini all decline to cache it, and you pay full price on every call while assuming caching has you covered. DeepSeek works in much smaller 64-token cache blocks, so short prefixes still stand a chance there, but the Western providers want at least a thousand tokens before they cache anything. The fix is often to make the cached block bigger on purpose, folding tool definitions and few-shot examples into the stable prefix so it clears the bar and the whole thing starts hitting.

What to actually do with this

Order your prompt so the stable part comes first. Caching keys on the prefix, so a system prompt, tool schema, and any fixed context have to sit at the very top, ahead of the user turn that changes every request. Teams that interleave a changing timestamp or a per-user field into the opening of the prompt break their own cache on every call and never understand why the discount is not showing up on the invoice.

Then stop worrying about the write fee and start worrying about the TTL. On Claude, if your traffic is steady, the default 5-minute tier is fine and its 1.25x write is trivially cheap; reach for the 1-hour tier only when requests arrive in slow, spaced-out bursts that would otherwise let the cache lapse between them, and accept the 2x write as the price of keeping it warm. On the automatic providers you have less to tune, so the job is just making sure your prefix is large enough and stable enough to qualify.

And pick the model with caching in mind, not just the sticker rate. A base price looks one way on the pricing page and another once 80% of your input is a cached prefix reading at a tenth of that, or a hundredth on DeepSeek. Model your real cached-versus-fresh split in the calculator before you commit, and check the current cache-hit rates on the pricing page.

Where this is heading

The convergence on a 90% read discount tells you caching has moved from a differentiator to an expectation. When every serious provider offers the same cut, it stops being a reason to pick one and becomes a floor everyone has to clear. The next round of competition is on the friction around it: how small a prompt qualifies, how long the cache survives, whether you have to think about it at all. DeepSeek is pushing the price of a hit toward zero; OpenAI just walked in the other direction by adding a write fee GPT-5.6 never used to charge.

For now the practical read is short. The cached-read price is nearly the same wherever you go, so do not agonize over it. Put your stable content first, make sure it clears the minimum, keep it hitting inside the TTL, and let the write fee be the rounding error it is. Do that and a large reused context, the most expensive-looking part of a modern prompt, becomes the cheapest part of the bill.

Sources

• - OpenAI prompt caching guide: developers.openai.com
• - Anthropic prompt caching docs (write multipliers, TTL, minimums): platform.claude.com
• - Google Gemini context caching: ai.google.dev
• - DeepSeek KV cache pricing: api-docs.deepseek.com
• - Related: Cut your LLM API costs
• - TokenCost pricing page: tokencost.app/pricing