Prompt Caching Cost Savings in 2026: Cut LLM Costs 41–80%

TL;DR

Prompt caching cost savings come from LLM providers storing processed key-value tensors for repeated prompt prefixes, so subsequent requests skip recomputation and bill at up to 90% off the standard input rate. Real-world savings range from 41% to 80% depending on provider, model, and cache hit rate. Caching only discounts input tokens from static prefixes, though, leaving dynamic content like RAG chunks and tool outputs at full price. For most production systems, combining caching with prompt compression covers both the static and dynamic portions of the bill.

Key Takeaways: Prompt Caching Cost Savings

Average Cost Savings: Organizations achieve 41% to 80% total input cost reduction by caching static prompt prefixes.
Cache Read Discount: Major LLM providers offer up to a 90% discount on input tokens that match stored key-value (KV) tensors.
Latency Reduction: Prompt caching decreases Time to First Token (TTFT) by 13% to 31%.
Output Tokens Are Excluded: Caching does not discount output tokens; savings apply strictly to input token recomputation.
Best Structural Strategy: Place static elements (system prompts, tool schemas) at the very top of the prompt and dynamic variables (user inputs, search results) at the end to prevent total cache invalidation.

What Are Prompt Caching Cost Savings?

Prompt caching cost savings are the reduction in LLM input-token spend achieved when a provider reuses stored key-value (KV) tensors for a prompt prefix it has already processed. Instead of running the full computation on every request, the model reads from the cache for the matching portion and only processes new tokens. The result: up to 90% off the input cost of those cached tokens, with byte-identical output.

Every major provider now supports some form of this. Anthropic, OpenAI, and Google all offer cache-read discounts, though the mechanics (write premiums, minimum token counts, TTL windows) differ enough to matter at scale.

Try Compresr’s demo to see how compression and caching work together on your own prompts.

How Prompt Caching Reduces Costs

The process works in two phases:

Cache write. The first request processes the prompt prefix normally and stores the resulting KV tensors. Some providers charge a write premium for this step (Anthropic charges 1.25x for a 5-minute cache, 2.0x for a 1-hour cache). Others, like OpenAI on older models, absorbed the write cost entirely.

Cache read. Subsequent requests with an identical prefix hit the stored tensors. The model skips the computation steps required to process those input tokens, charging a fraction of the normal rate. This also reduces time to first token by 13% to 31% depending on the provider.

Two things that trip people up:

Output tokens are unaffected. No provider’s caching scheme discounts output token costs. Any savings estimate that applies the discount to output spend is wrong.
Prefix matching is exact. Change one character in the cached portion, and the entire cache misses. Not just the changed field, everything after it.

How Much Can You Actually Save?

Provider Prompt Caching Comparison (2026 Rates)

Anthropic (Claude 3.5 / 4.x Series)

Cache Read Discount: 90% off base input rate
Cache Write Premium: 1.25x (5-minute TTL) or 2.0x (1-hour TTL)
Minimum Token Threshold: 1,024 to 4,096 tokens
Cache TTL (Time-To-Live): 5 minutes or 1 hour (refreshable on hit)

OpenAI (GPT-4.1 / GPT-5 Series)

Cache Read Discount: 75% to 90% off base input rate
Cache Write Premium: Free on standard tiers; 1.25x on select high-performance models
Minimum Token Threshold: 1,024 tokens (checked in 128-token increments)
Cache TTL (Time-To-Live): 5 to 10 minutes (up to 24 hours for persistent instances)

Google Gemini (Implicit & Explicit Caching)

Cache Read Discount: 90% off base input rate
Cache Write Premium: Free for Implicit Caching; $1.00 per 1M tokens/hour storage fee for Explicit Caching
Minimum Token Threshold: 1,024 tokens
Cache TTL (Time-To-Live): Automatic (Implicit) or Fully Configurable (Explicit)

Note: On providers that charge a write premium (like Anthropic), if your cache hit rate stays below ~30%, enabling caching can temporarily increase your total bill relative to standard requests.

The headline number is consistent: all three providers now offer a 90% discount on cached reads. The differences are in write premiums and TTL behavior.

Worked Example

Consider a 10,000-token system prompt sent 100 times per day on Anthropic’s Claude Sonnet 4.6 at $3.00/M input tokens:

Without caching: 10,000 × 100 = 1M tokens/day × $3.00 = $3.00/day
With caching (assuming 90% hit rate): First 10 requests write the cache (1.25x premium), remaining 90 hit it at $0.30/M. Daily cost drops to roughly $0.65/day.

That’s a 78% reduction on the input side, just from structuring the prompt so the static prefix stays consistent.

Real-World Benchmarks

The academic numbers hold up in production. ProjectDiscovery, a security intelligence company, restructured their agent prompts and raised their cache hit rate from 7% to 84% across 9.8 billion cached tokens. The key move was simple: they relocated a single dynamic identifier from the middle of the prompt to the end. That one structural change took their monthly cost savings to 59%, eventually climbing to 70%.

One practitioner documented an even starker transformation. Processing 81,251 tokens of video metadata per request without caching cost $0.24 per request, or $720/month. With caching enabled: $0.024 per request, $72/month. That’s $648 in monthly savings from a single configuration change.

A PwC academic study titled “Don’t Break the Cache” tested across multiple providers and found input cost savings ranging from 45% to 80%, with GPT-5 models reaching up to 79.3% and Claude models reaching 77.8% on full-context benchmarks.

For a deeper look at reducing Anthropic API costs or cutting OpenAI spend, see our provider-specific guides.

When Prompt Caching Saves the Most

Four conditions produce maximum prompt caching cost savings:

Long, stable system prompts reused across many requests. A completely static system prompt means every user of your application shares the same prefix. As one practitioner on Towards AI noted, the KV states get written once and reused across all users. The moment you personalize anything above the cache breakpoint, even a single field, you fragment one shared prefix into thousands of unique ones.

Multi-turn conversations where the prefix grows but stays static. Each turn appends to the history, but the earlier turns don’t change. The cache covers everything up to the new message.

RAG pipelines with a constant document corpus. If you query the same set of documents repeatedly within a session, the document prefix caches well.

Agent loops with fixed tool definitions. On a 40-step agentic task, the system prompt, tool definitions, and instructions repeat on every step. Without caching, that cost compounds quadratically with task complexity.

Limitations: When Caching Alone Isn’t Enough

This is where most discussions of prompt caching cost savings stop. But understanding the failure modes is what separates teams getting 80%+ hit rates from those stuck at 5%.

Short prompts get silently skipped. Prompt caching requires a minimum token volume before kicking in: typically 1,024 tokens for OpenAI and Gemini (evaluated in 128-token increments), and up to 4,096 tokens for larger Claude models. If your input falls below the threshold, caching is skipped automatically with no error returned.

Dynamic content defeats exact-match caching

RAG retrieved documents, tool outputs, search results, and user-specific context change on every request. These tokens sit at full price, always. And if any dynamic content appears before the cache boundary, it invalidates the entire prefix behind it, not just that field.

Short prompts get silently skipped

Prompt caching has minimum token thresholds: 1,024 tokens for OpenAI and Gemini, up to 4,096 for newer Claude models. If your input falls below the minimum, caching is silently skipped with no error returned. You have to check cache_creation_input_tokens in the usage response to confirm it’s actually working.

Low hit rates can cost more than no caching

On Anthropic, you break even after roughly 1.4 cache reads per cache write. Below a 30% hit rate on stable prompts, the write premium costs more than the reads save. A hit rate under 60% signals a structural problem in prompt design.

Bloated cached prompts are still expensive

Caching a 100K-token document is cheaper than reprocessing it every call. But you’re still paying the cached rate on all 100K tokens every time. If the model only needs 10K of those tokens to answer the query, you’re paying for 90K tokens of noise. This is where context rot becomes a real concern: accuracy can degrade with very long cached contexts that contain mostly irrelevant information.

Practitioners on Reddit’s r/AI_Agents have raised this exact concern for agent workloads. The core skepticism: agents have so much dynamic content (tool results, changing history) that the cacheable prefix is small relative to total input, making the headline “90% discount” misleading for their actual bills.

Agentic workloads are structurally hard to cache

Research on agentic plan caching notes that existing caching techniques, designed for chatbots at query-level rather than agents at task-level, have fundamental limitations. Naively enabling full-context caching can even increase latency when dynamic tool calls trigger cache writes for content that won’t be reused.

Prompt Caching vs. Prompt Compression

These two techniques reduce input token costs through different mechanisms. Understanding when to use each (and when to use both) is critical.

| |

Prompt Caching

Prompt Compression

| | --- | --- | --- | |

What it does

Reuses processed KV state for identical prefixes

Reduces the number of tokens sent

| |

Savings source

Discounted rate on repeated tokens

Fewer tokens at full rate

| |

Works on

Static, repeated content

All content, including dynamic and unique

| |

Limitations

Requires exact-match prefixes; can’t help dynamic content

Adds a processing step; quality depends on method

| |

Best for

System prompts, tool definitions, static docs

RAG chunks, search results, tool outputs, chat history

A July 2026 paper (CAPC) ranked #1 for this search term makes the tension explicit: query-aware compression methods produce a different compressed prefix for every query, which mechanically invalidates prefix-strict caches on every call. The solution is to separate the two concerns. Compress the dynamic portions first, then cache the static prefix. The CAPC approach achieved 89.6% savings versus no optimization, compared to 48.5% for cache-only.

As one technical blog from NebulaBlock put it: “Optimize the prompt down to what’s actually necessary, then cache the parts of that optimized prompt that stay constant across calls. Skip optimization and you’re caching a bloated prompt, cheaper, but still bigger than it needs to be.”

For workloads with both static and dynamic content (which is most production LLM systems), the optimal approach is to compress dynamic content and cache the stable prefix. See our full caching vs. compression comparison for implementation details.

The Combined Strategy in Practice

The practical workflow looks like this:

Compress dynamic content (RAG documents, tool outputs, search results) to remove tokens the model doesn’t need for the current query. Compresr’s query-aware API handles this at $0.10 per 1M tokens.
Structure your prompt with all static content (system instructions, tool definitions) at the top, and compressed dynamic content at the end.
Cache the static prefix using your provider’s native caching.

This way, caching discounts the static tokens by 90%, and compression reduces the dynamic tokens before they’re billed at the full rate. The two techniques cover each other’s blind spots.

For teams running RAG pipelines specifically, the RAG compression guide walks through integrating compression before the retrieval context hits the LLM.

Frequently Asked Questions

How much do prompt caching cost savings actually amount to?

Real-world savings range from 41% to 80% depending on provider, model, cache hit rate, and how much of your prompt is static. The PwC “Don’t Break the Cache” study found 79.3% savings on GPT-5.2 and 77.8% on Claude Sonnet 4.5 under ideal conditions. Production teams like ProjectDiscovery report 59–70% savings after optimizing prompt structure.

Does prompt caching affect output quality?

No. The model reads from the same KV tensors it would have computed from scratch. Output is byte-identical. Caching changes how the provider bills you, not what the model sees.

Why is my cache hit rate so low?

The most common cause is dynamic content placed before the cache boundary. A timestamp, session ID, or user-specific field anywhere in the prefix invalidates the entire cache for that request. Move all dynamic content to the end of the prompt and check cache_creation_input_tokens in your API response to verify caching is active.

Does caching work on short prompts?

Not if they fall below the provider’s minimum token threshold. OpenAI and Gemini require at least 1,024 tokens; newer Claude models require up to 4,096. Below that, caching is silently skipped with no error.

Can I use prompt caching and prompt compression together?

Yes, and for most workloads you should. Compress the dynamic portions of your prompt (RAG results, tool outputs, chat history) to reduce their token count, then let caching handle the static prefix. The July 2026 CAPC paper found this combined approach saves 89.6% compared to sending unoptimized prompts without caching.

Does prompt caching reduce output token costs?

No. Caching only discounts input tokens. Output token pricing is completely unaffected across all providers. Any cost estimate that applies the caching discount to output spend is incorrect.

When does enabling caching actually cost more money?

On Anthropic, the write premium means you need roughly 1.4 cache reads per write just to break even. If your hit rate stays below 30% on prompts that should be stable, you’re paying extra for cache writes that rarely get reused. Fix your prompt ordering before enabling caching.

What’s the difference between Anthropic, OpenAI, and Google caching pricing?

All three offer a 90% cache-read discount in 2026. They differ on write costs (Anthropic charges 1.25–2.0x, OpenAI charges 1.25x on GPT-5.6+, Google charges hourly storage) and TTL (Anthropic offers 5-min and 1-hr windows, OpenAI goes up to 24 hours, Google is configurable). The right choice depends on your request frequency and how long your cached content stays relevant.