Last updated: November 14, 2026
Picture an app that sends a 20,000-token system prompt with every request: policies, product docs, tool definitions. Only the last 200 tokens change between calls. Without caching, you pay the full input price for all 20,000 tokens, every single time.
Prompt caching exists to end that waste. The headline claim, up to 90% off cached input, is real. It is also the most misquoted number in LLM pricing, because it applies to one slice of your bill and only under specific conditions.
This guide covers the actual multipliers from provider documentation as of November 2026, the break-even math, four priced-out workloads, and what independent benchmarks measured. To model your own workload as you read, use the free TokenMeter calculator.
Quick answer: Cached input tokens cost roughly 10% to 50% of the normal input price. Whole-bill savings land between about 18% and 80% in our worked examples, and 41% to 80% in a peer-reviewed-style benchmark of agent sessions. The deciding factors are how much of each request is a stable prefix and how much of your bill is output.
In this guide
What Is Prompt Caching and Why Does It Save Money?
Prompt caching lets an LLM provider store the processed form of a repeated prompt prefix, so later requests skip the expensive recomputation. You pay a reduced rate for those cached tokens, typically 10% to 50% of the normal input price, and responses start faster because the model has less to process before it begins generating.
How the cache works
Before generating a single word, a model runs a prefill pass over your entire prompt. It computes key-value (KV) tensors for every token, and for long prompts this is the most compute-heavy step.
Providers with caching keep those tensors in memory after the first request. When a later request begins with an identical prefix, the model loads the stored tensors and processes only the new tokens.
The provider saves GPU time, and the discount passes part of that saving to you.
The exact-prefix rule
Caching matches from the first token onward, and one changed token breaks everything after it.
- A changed token at the start of the prompt invalidates the whole cache.
- A changed token at the end leaves the earlier prefix intact.
- A timestamp, user ID or random string near the top silently destroys your hit rate.
The right order is: static instructions, then tool definitions, then reference documents, then conversation history, then the new user message. Our guide on how to cut LLM API costs treats prompt ordering as one of the three biggest levers.
What caching does not discount
Caching reduces the price of repeated input tokens and nothing else.
- Output tokens are billed at full price, and they cost several times more than input on most models.
- New input, such as the user's current message, is billed at the normal rate.
- Short prompts don't cache at all. Most providers require a minimum prefix, roughly 1,024 to 4,096 tokens depending on provider and model, and requests below it fail silently without an error.
Your real saving therefore depends on how much of your bill is repeated input. We quantify that below.
What Does Each Provider Actually Discount?
Every major provider discounts cached input, but the read price, the write fee and the activation method differ. Anthropic bills cache reads at 0.1× the input price, with deeper cuts on some newer models, plus a write premium. OpenAI caches automatically at a discount that varies by model. Gemini and DeepSeek fall in between.
Here is the comparison, based on provider documentation and gateway docs checked in November 2026:
| Provider | How it's enabled | Cache read price (× input) | Cache write fee | Notes |
|---|
| Anthropic (Claude) | Explicit breakpoints or automatic mode | 0.1× (0.05× on Opus 5.5; 0.025× on Fable 5.1 and Mythos 5.1) | 1.25× (5-min cache) or 2× (1-hour cache) | Each hit refreshes the timer |
| OpenAI | Automatic | 0.1× to 0.5×, by model | Free on older models; 1.25× on GPT-5.6 and later | 1,024-token minimum, 128-token steps |
| Google Gemini | Implicit (automatic) or explicit | Up to 0.1× on 2.5 models | Implicit: none. Explicit: input price plus storage fee | Implicit hits aren't guaranteed |
| DeepSeek | Automatic | Over 90% off | Billed at normal input price | Prefix matching |
| xAI (Grok) | Automatic | 0.25× | Free | Routing varies by gateway |
Treat this table as a snapshot. Multipliers change with each model generation, so confirm on the provider's pricing page before you budget.
You Like : How to Cut LLM API Costs
Anthropic: you control it, and you pay to write
Anthropic gives the most control and the most explicit economics. A 5-minute cache write costs 1.25× the base input price, a 1-hour write costs 2×, and a read costs 0.1×.
According to Anthropic's pricing documentation, a 5-minute cache pays for itself after one read, and a 1-hour cache after two. If the prefix is never reused inside its lifetime, caching costs you more than skipping it.
OpenAI: zero effort, but check the model
OpenAI's caching is automatic. Prompts of 1,024 tokens or more are eligible, and hits are reported in cached_tokens in the usage object.
Older models charge nothing to write. Per OpenRouter's documentation, GPT-5.6 and later charge 1.25× on cache writes, so a long prompt sent only once now costs slightly more with caching on. Our OpenAI API pricing guide tracks the per-model rates.
Gemini, DeepSeek and the rest
Gemini offers implicit caching, which applies the discount automatically but without a guarantee. Explicit caching guarantees the discount but adds an hourly storage fee. Gateway documentation lists discounts of up to 90% on Gemini 2.5 models and up to 75% on 2.0 models.
DeepSeek hits are among the cheapest available. If you route through an aggregator, read what actually hits on OpenRouter, because gateway format can decide whether you get the discount at all.
The Break-Even Math: When Do Savings Start?
Caching saves money only after a prefix is reused enough times to repay any write premium. With Anthropic's 5-minute cache, break-even is one reuse. With the 1-hour cache it takes two. Providers with free writes break even immediately, and every later hit is pure savings, approaching but never reaching the read discount.
The formula
Let N be the prefix size in tokens and base price = 1. Let k be the number of requests sharing that prefix within the cache lifetime (one write plus k−1 reads).
- Without cache: cost = k × N
- With cache: cost = (write multiplier × N) + ((k−1) × read multiplier × N)
Here is the saving on the cached prefix itself:
| Requests sharing the prefix (k) | Anthropic 5-min (1.25× / 0.1×) | Anthropic 1-hour (2× / 0.1×) | Free write, 90% off | Free write, 50% off |
|---|
| 1 | −25% | −100% | 0% | 0% |
| 2 | 32.5% | −5% | 45% | 25% |
| 3 | 51.7% | 26.7% | 60% | 33.3% |
| 5 | 67% | 52% | 72% | 40% |
| 10 | 78.5% | 71% | 81% | 45% |
| 20 | 84.3% | 80.5% | 85.5% | 47.5% |
| 100 | 88.9% | 88.1% | 89.1% | 49.5% |
Two patterns stand out. First, a one-off prompt loses money wherever a write premium exists. Second, the first 5 to 10 reuses deliver most of the gain, and the curve flattens after that.
Worked example 1: a document Q&A app
These prices are illustrative, chosen to keep the arithmetic clean: $3 per million input tokens and $15 per million output tokens, using Anthropic-style multipliers on a cache hit.
Each request carries a 20,000-token cached prefix, 1,000 new input tokens and 500 output tokens.
- No cache: (21,000 × $3 ÷ 1M) + (500 × $15 ÷ 1M) = $0.063 + $0.0075 = $0.0705
- Cache hit: (20,000 × $0.30 ÷ 1M) + (1,000 × $3 ÷ 1M) + $0.0075 = $0.006 + $0.003 + $0.0075 = $0.0165
That is a 76.6% saving per request. At 100,000 requests the bill drops from about $7,050 to $1,650, before the small one-time write cost.
Worked example 2: an output-heavy reasoning task
Now flip the profile: a 5,000-token cached prefix, 500 new input tokens and 4,000 output tokens, at the same prices.
- No cache: (5,500 × $3 ÷ 1M) + (4,000 × $15 ÷ 1M) = $0.0165 + $0.06 = $0.0765
- Cache hit: (5,000 × $0.30 ÷ 1M) + (500 × $3 ÷ 1M) + $0.06 = $0.0015 + $0.0015 + $0.06 = $0.063
The saving is only 17.6%, even with the identical 90% read discount. The rule of thumb is:
Real saving ≈ (cached tokens' share of your total bill) × (read discount)
Input-heavy apps such as RAG, support bots and coding agents benefit most. Output-heavy apps benefit least. Run your own mix through TokenMeter to find your share.
What Do Independent Benchmarks Show?
Independent testing agrees on direction but not on magnitude. The most rigorous public study, run by PwC researchers across OpenAI, Anthropic and Google models, found API cost reductions of 41% to 80% and time-to-first-token improvements of 13% to 31% in long agentic sessions. Savings were consistent; speed gains were not.
How the study was built
The paper, "Don't Break the Cache" (arXiv 2601.06007, January 2026), tested four flagship models from three providers. It ran more than 500 agent sessions on DeepResearch Bench, where agents make real web-search tool calls, using 10,000-token system prompts.
The authors compared three strategies against a no-cache baseline: caching the full context, caching only the system prompt, and caching everything except dynamic tool results. A separate ablation varied prompt size from 500 to 50,000 tokens and tool calls from 3 to 50.
What the results mean for you
- Cost savings were robust. All three strategies cut costs by a similar 41% to 80% range, so almost any sensible caching setup helps your wallet.
- Caching only the system prompt was the most consistent choice across both cost and latency.
- Naive full-context caching could increase latency. A plausible reason is that volatile tool results get written to the cache but never reused, though check your own traces before assuming that.
- Latency gains were much smaller than cost gains. Caching removes prefill work, but generating the answer token by token takes the same time as before.
- Benefits scaled roughly linearly with prompt size and tool-call count once the provider's minimum was met.
A practitioner caveat on Gemini
One API gateway's documentation advises that Gemini's implicit cache hit rate is visibly lower than Claude's or OpenAI's, and recommends budgeting at the uncached price. That is operational guidance, not a controlled benchmark, but it matches the "not guaranteed" label on implicit caching.
Two limits apply to every number here. The study used 10,000-token prompts and agent-style workloads, and provider prices and models change quickly, so treat the percentages as a range, not a promise.
Four Real Workloads, Priced Out
Savings range from roughly 30% to 80% depending on how much of each request is stable. These four profiles use the same illustrative prices as above ($3 input and $15 output per million tokens, 5-minute cache write at 1.25×, read at 0.1×) so the only variable is the shape of the workload.
1. Customer-support chatbot
Each request has a 6,000-token stable prefix (system prompt, policies, tools), 600 uncached tokens (history plus the new message) and 300 output tokens.
- No cache: 6,600 × $3 ÷ 1M = $0.0198, plus $0.0045 output = $0.0243
- Cache hit: $0.0018 (cached) + $0.0018 (new) + $0.0045 = $0.0081
That is a 66.7% saving. At 50,000 requests a month the bill falls from about $1,215 to $405. Steady traffic keeps the 5-minute cache warm.
2. RAG with changing retrieved chunks
Only the 3,000-token instruction block is stable. The 4,000 retrieved tokens change every query, followed by a 100-token question and 400 output tokens.
- No cache: 7,100 × $3 ÷ 1M = $0.0213, plus $0.006 output = $0.0273
- Cache hit: $0.0009 (cached) + $0.0123 (4,100 new) + $0.006 = $0.0192
The saving is just 29.7%. Worse, if your model's minimum cacheable prefix is above 3,000 tokens, you get nothing. Dynamic retrieval caps the benefit, so put stable material first and keep retrieved text last.
3. Coding agent with a 30-step session
The system prompt and tools take 12,000 tokens, each tool step adds about 1,500 tokens of context, and each step emits 300 output tokens. Every step re-sends the growing conversation.
- No cache: about 1,012,500 input tokens × $3 ÷ 1M = $3.04, plus $0.135 output = about $3.17 per session
- With incremental caching: about 957,000 tokens read at $0.30 = $0.29, plus 55,500 tokens written at $3.75 = $0.21, plus $0.135 output = about $0.63 per session
That is an 80% saving. At 1,000 sessions a month the bill drops from about $3,170 to $630. Long, append-only contexts are where caching shines.
4. Batch document processing
500 documents share an 8,000-token instruction and few-shot prefix. Each document adds 3,000 unique tokens and produces 600 output tokens, and the jobs run back to back inside the cache window.
- No cache: $0.033 input + $0.009 output = $0.042 per document, or $21.00 in total
- With cache: the first document costs $0.048 including the write, and the other 499 cost $0.0204 each, for about $10.23 in total
The saving is about 51%. Anthropic's documentation says caching multipliers stack with the Batch API discount. Batch jobs may not run in a tight sequence, so check whether the 1-hour cache suits your timing.
Summary of the four workloads
| Workload | Stable prefix | Output share of bill | Whole-bill saving |
|---|
| Support chatbot | 6,000 tokens | Low | 66.7% |
| RAG, changing chunks | 3,000 tokens | Medium | 29.7% |
| Coding agent, 30 steps | Grows each step | Low | about 80% |
| Batch document processing | 8,000 tokens | Medium | about 51% |
Prefix stability and output share explain almost all of the spread.
Mistakes That Silently Empty Your Cache
Most failed caching setups share a handful of causes: something in the prefix changes between requests, the prefix is too short, the cache expires before the next call, or concurrent requests arrive before the first write completes. None of these raises an error. They only show up as missing hits in your usage data.
The eight most common causes
- Dynamic values at the top. Timestamps, request IDs and user names inside the system prompt change the prefix on every call. Move them to the end.
- Unstable serialization. JSON keys or tool lists emitted in a different order produce a different prefix even when the content is identical. Sort them.
- Rewriting history. Trimming or summarizing earlier turns shifts everything after the edit. Keep conversation history append-only, and compact it deliberately and rarely.
- Prompts below the minimum. A 900-token prefix will never cache on a model that needs 1,024 or more. Check the model-specific minimum.
- Traffic gaps longer than the lifetime. With a 5-minute cache and sparse traffic, you pay the write premium again and again. Consider the 1-hour cache only if you expect at least three reuses.
- Parallel cold starts. If 50 requests with the same new prefix fire at once, many may be processed before the first write is available. Send one request, let it begin responding, then fan out.
- Wrong API surface. One gateway documents that calling Claude through an OpenAI-compatible format gets no cache discount. Use the native format where caching matters.
- Caching volatile tool results. As the benchmark showed, writing content that will never be reused adds cost without benefit. Place your cache breakpoint before dynamic results.
How to Measure Your Own Savings
Measure savings from the usage fields in each API response, not from the pricing page. Track cached input tokens, cache-write tokens and uncached tokens per request, then compare your actual bill with what the same traffic would cost uncached. A healthy setup shows the hit rate climbing after the first request in each session.
Where the numbers live
| API | Usage fields to log |
|---|
| OpenAI Chat Completions | usage.prompt_tokens_details.cached_tokens |
| OpenAI Responses | usage.input_tokens_details.cached_tokens |
| Anthropic Messages (native) | cache_creation_input_tokens and cache_read_input_tokens |
| OpenRouter (normalized) | cached_tokens and cache_write_tokens under prompt_tokens_details |
| DeepSeek | prompt_cache_hit_tokens and prompt_cache_miss_tokens |
Three metrics worth dashboarding
- Hit rate = cached tokens ÷ total input tokens
- Effective input price = actual input spend ÷ total input tokens
- Realized saving = 1 − (actual cost ÷ hypothetical uncached cost)
hit_rate = cache_read / total_input
uncached = total_input * base_price + output_cost
actual = new_tokens * base_price
+ cache_write * write_mult * base_price
+ cache_read * read_mult * base_price
+ output_cost
saving = 1 - actual / uncached
If the hit rate sits near zero, work through the mistakes list above. To forecast savings before you build, enter your token mix in TokenMeter. Browse all our prompt caching guides for provider-specific details.
When Is Prompt Caching Not Worth It?
Skip caching, or at least don't expect much, when prompts are used once, fall below the minimum length, change at the start on every request, or when output tokens dominate your bill. In those cases the write premium, added complexity or tiny cached share cancels the discount.
| Situation | Why it fails | What to do |
|---|
| One-off prompts | You pay a write premium and never read | Leave caching off |
| Prefix under the minimum | Provider silently skips caching | Check the model's threshold |
| Personalized prefix per user | No two requests share a prefix | Move personal data to the end |
| Sparse traffic with a 5-minute cache | Cache expires between calls | Batch calls or test the 1-hour cache |
| Output-dominated bill | Cached input is a small slice of spend | Optimize output length or model choice first |
The Bottom Line
Prompt caching is the largest single cost lever for apps that resend the same long prefix. Our four workloads saved between 30% and 80%, the PwC benchmark measured 41% to 80%, and an output-heavy task saved under 20%. The same feature can also cost you extra when a prefix is never reused.
A practical order of work:
- Reorder prompts so stable content comes first and dynamic content last.
- Enable caching and confirm the model's minimum prefix length.
- Log cache-read and cache-write tokens, and track your hit rate.
- Model the numbers in TokenMeter before scaling traffic.
Frequently Asked Questions
How much does prompt caching really save?
Cached input tokens are billed at roughly 10% to 50% of the normal input price, depending on the provider. Across a whole bill, input-heavy apps with stable prefixes typically see 30% to 80% savings, while output-heavy workloads may save under 20%.
Does prompt caching make responses faster?
Yes, but modestly. A 2026 benchmark of long agent sessions measured time-to-first-token improvements of 13% to 31%. Caching skips prefill work but does not speed up token-by-token generation.
How long does the cache last?
It depends on the provider. Anthropic offers 5-minute and 1-hour caches, and each hit refreshes the timer. OpenAI's explicit mode on GPT-5.6 and later has a 30-minute minimum lifetime, and Gemini's explicit caching lets you set a time to live.
What is the minimum prompt length for caching?
OpenAI requires at least 1,024 tokens. Anthropic and Google set minimums that range from about 1,024 to 4,096 tokens depending on the model. Prompts below the minimum are processed normally without any error.
Can prompt caching increase my bill?
Yes. Providers that charge a cache write premium, such as 1.25× or 2× the input price on Anthropic, cost more than uncached requests if the prefix is never reused within the cache lifetime.
Do I need to change my code to use prompt caching?
It depends on the provider. OpenAI, DeepSeek and Gemini's implicit caching are automatic. Anthropic requires cache breakpoints or its automatic caching setting, and Gemini's explicit caching requires you to create and reference a cache.
Sources
Prices and multipliers change often. All dollar figures in the worked examples are illustrative, not current list prices. Verify against each provider's pricing page before budgeting.
