Prompt Caching in 2026: The Cross-Provider Guide (With the Numbers Everyone Gets Wrong)
JUL 28, 2026 · 12 min read
Prompt caching bills the repeated part of your prompt at a fraction of the normal input rate, usually 90% off and in one case 98%. Every major provider supports it, but they work structurally differently, and three widely repeated facts about it are now wrong: the minimum prompt sizes are not what most guides publish, OpenAI cache writes are no longer free, and caching never touches your output bill no matter what a savings calculator tells you.
This guide covers what each provider actually does as of July 2026, what it saves on a real workload, and the one prompt rule that works everywhere.
What prompt caching actually is
When a model processes your prompt, it computes attention key and value tensors for every token. Prompt caching stores those computed tensors server side. If your next request starts with the same prefix, the model loads the cached state instead of recomputing it, and the provider bills those tokens at a steep discount.
Two consequences follow from that mechanism, and both matter more than the pricing.
It is a prefix match, not a fuzzy match. The cache works from the first token forward. A shared block in the middle of two different prompts does not hit. Change one character near the top and the whole thing misses.
It only touches input. Output is generated fresh every time and billed in full. Any estimate that applies the caching discount to your total bill is wrong, and this is the single most common error in caching math.
How the four major providers differ
They landed on caching at different times with structurally different designs. This is the table no vendor page will show you, because each one only documents itself.
| Provider | How you enable it | Cache read | Cache write | Minimum prompt |
|---|---|---|---|---|
| Anthropic | Explicit, cache_control breakpoints | 0.1x base input | 1.25x (5 min), 2x (1 hour) | 512 to 4,096, model-specific |
| OpenAI | Automatic, explicit breakpoints on newer models | 0.1x base input on GPT-5.6 | 1.25x on GPT-5.6, free on older models | 1,024 tokens |
| Google Gemini | Implicit by default, explicit optional | 0.1x base input | Implicit free, explicit charges storage | 1,024 Flash, 4,096 Pro |
| DeepSeek | Automatic, always on | $0.0028 vs $0.14 on V4 Flash, a 50x cut | None, storage free | Prefix from token 0 |
Rates verified against each provider’s own documentation in July 2026.
Three things stand out.
DeepSeek’s discount is in a different class. Everyone else lands at 10x off the input rate, including GPT-5.6 and Gemini 3.6 Flash. DeepSeek V4 Flash drops from $0.14 to $0.0028 per million tokens on a hit, which is 50x. It has been automatic since 2024, with no write premium and no storage fee, which makes it close to free money on any workload with a stable prefix.
Anthropic is the only one that requires you to ask. OpenAI, Google, and DeepSeek all cache automatically. Anthropic caches nothing unless you mark a breakpoint with cache_control. If you are on Claude and have never touched that field, you have never had a cache hit.
Google is the only one charging rent. Implicit caching is free and opportunistic. Explicit caching guarantees the discount but charges you to create the cache at standard input rates plus an hourly storage fee, so it only pays back if the content is read enough times inside the TTL.
What it actually saves
Take a concrete workload: 300,000 calls a month, a 5,000 token stable prefix, 500 tokens of variable input, and a 300 token response.
| Model | Monthly, uncached | Monthly, cached | Total saving |
|---|---|---|---|
| DeepSeek V4 Flash | $256 | $50 | 80% |
| Claude Haiku 4.5 | $2,100 | $750 | 64% |
| GPT-5.6 Luna | $2,190 | $840 | 62% |
| Gemini 3.6 Flash | $3,150 | $1,125 | 64% |
| GPT-5.6 Terra | $5,475 | $2,100 | 62% |
| Claude Sonnet 5 | $6,300 | $2,250 | 64% |
| GPT-5.6 Sol | $10,950 | $4,200 | 62% |
Methodology: published July 2026 list prices, assuming a warm cache with write costs amortized across high volume. On the input side alone the reduction is 5.5x for the 10x-discount providers and 9.2x for DeepSeek.
Now notice the gap between those two figures. Input cost falls 5.5x, but the total bill only falls about 62%. The difference is output, which caching does not touch. On the Sonnet 5 row, output alone is $1,350 a month and no amount of caching moves it.
That gap is the practical takeaway. If your workload is generation heavy, short prompts and long outputs, caching will barely register. Before you invest in it, sum a week of input tokens against output tokens. Caching is a lever on the input side only, and its value to you is proportional to how much of your bill lives there.
Correction one: the minimums are not what you have read
Almost every guide publishes some version of “1,024 tokens for Sonnet and Opus, 2,048 for Haiku.” That is wrong, and the real numbers are model-specific and higher than most people expect.
| Anthropic model | Minimum cacheable prompt |
|---|---|
| Claude Fable 5, Mythos 5 | 512 tokens |
| Claude Opus 4.8, Sonnet 5, Sonnet 4.6, Sonnet 4.5 | 1,024 tokens |
| Claude Opus 4.7 | 2,048 tokens |
| Claude Opus 4.6, Opus 4.5, Haiku 4.5 | 4,096 tokens |
Read the last row again. Haiku 4.5, the cheap high-volume model, has the highest threshold on the list. Google’s structure is the same shape: Gemini Flash needs 1,024 tokens while Gemini Pro needs 4,096.
This inverts the usual intuition. Teams reach for a cheap model precisely because they are running high volume with a modest prompt, which is exactly the configuration most likely to fall below the cache floor. A 2,000 token system prompt caches happily on Sonnet 5 and does not cache at all on Haiku 4.5.
And it fails silently. Anthropic’s documentation is explicit that shorter prompts are processed without caching and no error is returned. You will not find out from your logs. You will find out from your invoice, eventually, if you notice at all.
Correction two: OpenAI cache writes are not free anymore
The received wisdom is that OpenAI caching is automatic, free, and requires nothing from you. That was true, and it is now out of date in two ways.
Writes are billed on the current family. Models before GPT-5.6 charged nothing to write to the cache. GPT-5.6, which reached general availability on July 9, 2026 and is now the current lineup, bills cache writes at 1.25x the uncached input rate. On Sol that is $6.25 per million against a $5 base. This applies even though caching remains automatic and requires no opt-in, so if you migrated from GPT-5.5 you picked up a write premium you never enabled.
Retention changed too. OpenAI caches used to expire after 5 to 10 minutes of inactivity. GPT-5.6 carries a 30-minute minimum cache life, and retention on the recent families extends considerably further than the old window. That is a real economic shift: a longer-lived cache makes intermittent and low-traffic workloads cacheable in a way they simply were not before.
The practical upshot is that OpenAI and Anthropic have converged. Both now have a write premium and a read discount, and on both the question is the same: does this prefix get reused enough to earn back the write?
The breakeven is lower than you think
Run the Anthropic multipliers and the answer is almost absurd.
A 5-minute cache costs 1.25x to write and 0.1x to read. Write it once and read it once and you have spent 1.35x. Sending the same content uncached twice costs 2.0x. The 5-minute cache is profitable on the first hit.
The 1-hour cache costs 2x to write, so with two reads you are at 2.2x against 3.0x uncached. It breaks even on the second hit.
There is one more detail that makes this better: on Anthropic the default 5-minute cache refreshes at no additional cost each time it is used. Steady traffic keeps it warm indefinitely without repaying the write. The 1-hour TTL is only worth its higher write premium when your traffic is intermittent enough that a 5-minute window would lapse between requests.
The one rule that works everywhere
Every provider, every model, one rule: static content first, dynamic content last.
Instructions, tool definitions, few-shot examples, and long reference documents go at the top, byte identical on every call. The user message, timestamp, session ID, and retrieved chunk go at the bottom. If a piece of content changes between calls, it must never sit above something that does not.
This is where most caching failures actually live. A single timestamp or user name near the top of a system prompt means the prefix hash never matches, so you pay a fresh write on every request and never get a read. It costs you more than not caching at all, and nothing in your logs says so.
Beyond ordering, know what else resets a cache. Changing tools, images, or the reasoning effort setting invalidates cached blocks on Anthropic, which matters if you are tuning effort down for cost, because that saving comes with a cache reset attached. On DeepSeek, matching starts at token zero and partial matches in the middle never hit.
Verify it, do not assume it
Because caching fails silently on every provider, the only responsible approach is to check the usage fields on real responses.
| Provider | Fields to log |
|---|---|
| Anthropic | cache_creation_input_tokens, cache_read_input_tokens |
| OpenAI | cached_tokens, and cache_write_tokens on GPT-5.6+ |
cachedContentTokenCount | |
| DeepSeek | prompt_cache_hit_tokens, prompt_cache_miss_tokens |
If the read field is zero across a run of requests that share a prefix, nothing is caching. On a stable-prefix workload you want a 60 to 80% hit rate. Log this per task, not globally, because one broken prompt can hide inside a healthy average.
Two bonuses worth knowing. On Anthropic, cache hits are not deducted against your rate limits, so good caching buys you throughput headroom as well as savings. And caching improves time to first token, modestly on short prompts and substantially on long ones, which means it is a latency optimization as much as a cost one.
Caching when you route across providers
If you run more than one provider, which most teams now do, caching gets more complicated in one specific way: the discount structures differ, so the same prompt has different caching economics depending on where it lands.
The good news is that the fix is universal. A prompt ordered static-first is correctly structured for all four providers at once. You do not need a per-provider prompt layout, only per-provider verification.
The thing to actually watch is that a cache lives with the provider that holds it. Route the same request somewhere else and you start cold. This is worth knowing when you combine caching with per-task routing: the cheapest model on paper may not be cheapest in practice if switching to it abandons a warm cache you were about to hit. Measure cost per completed task rather than per token, because that is the number that captures this.
MixRoute gives you every major model behind one OpenAI compatible endpoint with zero markup on provider pricing, so you can compare cached and uncached economics across providers without maintaining four integrations to do it. The full list of cost levers puts caching in context: routing per task is the larger lever, and caching is the one that compounds on top of it.
FAQ
What is prompt caching? Storing the computed attention state for a repeated prompt prefix so the model does not recompute it, and billing those tokens at a steep discount. Most providers offer around 90% off cached input, and DeepSeek offers roughly 98%. It only applies to input tokens, never output.
How much does prompt caching save? On the input side, roughly 5.5x on the providers offering a 10x read discount, which is all of Anthropic, OpenAI, and Google, and around 9x on DeepSeek, for a workload with a large stable prefix. Total bill savings are lower, typically 60 to 80%, because output is billed in full regardless. If your prompts are short and your outputs long, caching will save you very little.
What is the minimum prompt size for caching? It is model-specific and higher than commonly published. On Anthropic it ranges from 512 tokens on Fable 5 and Mythos 5 up to 4,096 on Haiku 4.5, Opus 4.6, and Opus 4.5, with 1,024 for Opus 4.8 and the Sonnet 5 line. OpenAI requires 1,024. Gemini requires 1,024 on Flash and 4,096 on Pro. Prompts below the threshold are processed without caching and no error is raised.
Is OpenAI prompt caching free? Not entirely, not anymore. Caching is still automatic with no configuration, but the GPT-5.6 family, generally available since July 9 2026, bills cache writes at 1.25x the uncached input rate. On Sol that is $6.25 per million against a $5 base. Older models wrote to cache for free. Reads keep the 90% discount, and GPT-5.6 carries a 30-minute minimum cache life rather than the old 5 to 10 minute window.
Why is my prompt cache not working? The three usual causes: your prompt is below the model’s minimum cacheable length, something dynamic like a timestamp or session ID sits near the top of your prefix and breaks the byte-identical match, or your traffic is sparse enough that entries expire before reuse. Changing tools, images, or reasoning effort settings also invalidates a cache. Check the usage fields on your responses, because all of these fail silently.
Does prompt caching reduce output costs? No. Caching only discounts input tokens. Output is generated fresh on every request and billed at full rate on every provider. Any savings estimate that applies the caching discount to your whole bill is overstating it, sometimes by a lot.
The bottom line
Prompt caching is the second largest lever on an AI bill after routing, and it is close to free to implement. Order your prompt static first and dynamic last, mark a breakpoint if you are on Anthropic, and check the usage fields to confirm it actually happened.
Then correct for the three things most guides get wrong. The minimums are model-specific and the cheap models often have the highest ones. OpenAI writes are no longer free on newer models. And caching never touches output, so measure your input to output ratio before you expect much from it.
MixRoute puts every major model behind one OpenAI compatible endpoint with zero markup, so you can compare these economics across providers with one integration instead of four. Start building on MixRoute
Read Next
View More Articles
What Is an AI API Gateway? (And When You Actually Need One) 2026
How to Handle LLM API Failures: Rate Limits, Outages, and Failover (2026)