How Prompt Caching Reduces AI Cost (October 2026): OpenAI 12h TTL, Claude, Gemini and DeepSeek Compared

Updated 2026-10-26: Rebuilt around a cross-provider price table. New in this version: OpenAI's 12-hour cache option (October 20) and cache-write billing on GPT-5.6 and later, Claude Sonnet 5.5's 0.05x cache reads, the Claude Haiku 5.5 100K-token pricing threshold, implicit-only caching on Gemini 4 Argon, and DeepSeek's peak/off-peak cache-hit prices.

Most LLM-backed products send the same large block of text on almost every request: a long system prompt, a set of tool schemas, a style guide, a codebase summary, or the earlier turns of a conversation. Without caching, you pay full input price for that block every single time. Prompt caching lets the provider keep the model's internal state for that prefix and reuse it, which cuts both cost and time-to-first-token.

The economics have changed a lot since this post was first written. Caching used to be a simple "free discount" on OpenAI and a manual opt-in on Anthropic. In 2026 every major provider prices it differently: some charge to write the cache, some only discount reads, TTLs range from five minutes to twelve hours, and at least one model (Claude Haiku 5.5) has a pricing threshold that cached tokens can push you over. This guide covers how prompt caching works, current prompt caching cost per provider, worked cost examples with the arithmetic shown, and the cases where caching costs you more instead of less.

What prompt caching is (and what it is not)

When an LLM processes a prompt, it computes internal attention state (the key/value or "KV" cache) for every input token. That prefill work is the main thing you pay for in input tokens. Provider-side prompt caching stores that computed state for a prefix of your prompt. If the next request starts with exactly the same tokens, the model skips recomputing them and only processes what comes after.

Two points that are often confused:

• It is not response caching. The model still generates a fresh answer every time, and you still pay full output price. If you want to return a stored answer to an identical question ("What is your refund policy?"), that is an application-level response cache (Redis, a semantic cache, and so on), which you build and run yourself. The two techniques stack well, but they are different things.
• It matches prefixes, not similar text. A cache hit requires the cached portion to be token-for-token identical from the start of the prompt. Change one character early in the prompt (a timestamp, a user ID, a reordered tool list) and everything after that point is a miss.

How prompt caching works

Cache writes, hits and misses

• Cache write (miss): The first request with a given prefix is processed in full, and the provider stores the prefix state. On OpenAI (GPT-5.6 and later) and Anthropic, written tokens are billed at a premium over normal input. Google and DeepSeek do not list a separate write price for the models covered here.
• Cache hit (read): A later request with the same prefix, sent before the entry expires, is billed at the discounted cache-read rate for the cached portion. Only the new suffix is billed at normal input price.
• Expiry: Entries expire after a time-to-live (TTL). On Anthropic, each hit resets the timer at no extra cost. Pick a TTL that matches how often the prefix really repeats.

Structure the prompt: static first, dynamic last

Because caching works on prefixes, order matters more than anything else. Put content that never changes first, content that changes rarely next, and per-request content last:

1. Tool definitions
2. System prompt and instructions
3. Reference material (docs, examples, codebase context)
4. Conversation history
5. The current user message, timestamps, request IDs

Anthropic's docs list the things that invalidate its cache, and they make a good checklist for any provider. Changing tool definitions invalidates everything. Changing the system prompt invalidates the system and message caches. Toggling web search or citations, switching the speed setting, adding or removing images, and changing thinking or effort settings can also break the cache. Their docs also call out timestamps or other per-request content placed before a breakpoint as causing a miss on every request.

Prompt caching cost by provider (as of October 2026)

All prices are USD per 1M tokens on standard, short-context tiers from each provider's official pricing page, as of October 2026. "Base input" is the uncached input price.

If you call Claude or Gemini through Amazon Bedrock, Google Vertex AI or another cloud platform, check that platform's caching prices and TTLs. They can differ from the first-party APIs listed here.

Long-context note: OpenAI doubles input, cached input and cache-write prices for requests over 272K input tokens on these models (for example, gpt-6.1-sol goes to $4.00 input and $0.20 cached). Anthropic bills Claude 4.6 and later models (except Haiku 5.5) at standard rates across the full 1M context window.

OpenAI: cache writes are now billed, and there is a 12-hour option

Caching is on by default for supported OpenAI models. For GPT-5.6 and later, two things changed that matter for cost:

• Cache writes cost extra. OpenAI's prompt caching guide says only GPT-5.6 and later charge for cache writes. For GPT-5.6 and later, a 30-minute write costs 1.25x the uncached input rate; in the Responses API you can also choose a 12-hour write at 2.5x. The guide describes these as "total write rates, not surcharges on top of ordinary input": written tokens are billed at the write rate instead of the normal input rate. Earlier models (GPT-5.5 and before) have no write charge.
• A 12-hour TTL. OpenAI's API changelog entry for October 20, 2026 reads: "You can now choose 12-hour prompt caching in the API" and "12-hour cache writes cost 2.5x the input token price." You set it with prompt_cache_options.ttl, which takes "30m" (the default) or "12h". OpenAI's guide documents this parameter for the Responses API and does not mention Chat Completions. The older prompt_cache_retention parameter applies only to models before GPT-5.6.

{
  "model": "gpt-6.1-sol",
  "input": "...",
  "prompt_cache_options": { "ttl": "12h" }
}

Usage is reported under usage.input_tokens_details: cached_tokens (billed reads), cache_write_tokens, and a cache_write_tokens_details breakdown into ttl_30m_tokens and ttl_12h_tokens. Ordinary input equals input_tokens - cached_tokens - cache_write_tokens. GPT-6.1 Sol stands out because its cached input is $0.10, or 5% of base, where the rest of the GPT-6 family reads at 10%. See our GPT-6.1 Sol guide and GPT-6 Luna guide for the models themselves.

Anthropic Claude: 5-minute vs 1-hour writes, cheaper reads on 5.5 models

Claude caching uses cache_control. You can put a single top-level cache_control on the request (automatic caching, where the breakpoint moves forward as the conversation grows), or place up to four explicit breakpoints on individual content blocks. The pricing multipliers on the official pricing page are:

• 5-minute cache write: 1.25x base input
• 1-hour cache write: 2x base input
• Cache read: 0.1x base input by default, 0.05x on Claude Opus 5.5 and Sonnet 5.5, and 0.025x on Claude Fable 5.1 and Mythos 5.1

The 0.05x multiplier is why Sonnet 5.5 reads cost $0.10 per 1M tokens. The standard 0.1x rate would put them at $0.20, which is what Claude Sonnet 5 still charges at the same $2 base input. Opus 5.5 reads are $0.20, and Fable 5.1 reads are $0.25 against a $10 base. These multipliers stack with the Batch API discount and the 1.1x US-only inference multiplier. The minimum cacheable prefix on all the 5.x models in the table is 512 tokens (Claude Sonnet 5, not in the table, is 1,024). Shorter prompts are silently processed without caching, so check the usage fields.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are an AI assistant tasked with analyzing legal documents.",
        },
        {
            "type": "text",
            "text": "Here is the full text of a complex legal agreement: [...]",
            # 1-hour TTL; omit "ttl" for the default 5-minute cache
            "cache_control": {"type": "ephemeral", "ttl": "1h"},
        },
    ],
    messages=[
        {"role": "user", "content": "What are the key terms and conditions in this agreement?"}
    ],
)

u = response.usage
print(u.cache_creation_input_tokens, u.cache_read_input_tokens, u.input_tokens)

Total input is cache_read_input_tokens + cache_creation_input_tokens + input_tokens. The cache_creation object splits writes into ephemeral_5m_input_tokens and ephemeral_1h_input_tokens. More model detail is in our Claude Sonnet 5.5 guide.

Google Gemini 4 Argon: implicit caching only

Google's pricing page says Gemini 4 Argon supports "Implicit caching only (explicit caching is not supported)." You cannot create or manage cache objects for Argon. Google applies the discount automatically when a request shares a prefix with a recent one. Cached input costs $0.10 per 1M tokens through November 30, 2026, then $0.20 from December 1, alongside the move from $2.00 to $4.00 base input. No write fee or storage fee is listed for Argon.

According to Google's caching docs, implicit caching on Argon needs at least 4,096 input tokens. In multi-turn use on Gemini 4, the full previous request is cached only if the new request adds at least 2,050 tokens. Cache hits show up in usage.total_cached_tokens. Google's own tips: put large, common content at the beginning of the prompt, and send requests with similar prefixes close together in time. The trade-off is predictability. You get no write premium, but you also get no guarantee that a given request will hit. Google's caching docs say explicit caching remains available on supported Gemini 3 and 2.5 models through the generateContent API. Its pricing page also lists a separate hourly cache-storage price for Gemini 3.8 Flash ($0.50 per 1M tokens per hour through December 31, 2026), which applies to explicit caches.

DeepSeek: automatic caching plus off-peak pricing

DeepSeek's context caching is "enabled by default for all users," with no code changes needed. A request hits only if it fully matches a stored prefix unit. Unused cache entries are typically cleared within a few hours to a few days, and hits are best-effort. The prompt_cache_hit_tokens and prompt_cache_miss_tokens usage fields tell you what you were billed for.

For deepseek-flash (DeepSeek-V4.1-Flash-1017), a cache hit costs $0.006 per 1M tokens at peak and $0.003 off-peak, against $0.30 and $0.15 for a miss. Output is $1.20 at peak and $0.60 off-peak. Peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC, Monday through Friday, excluding Chinese public holidays. All other hours, including weekends, bill at the off-peak rate, which is half of peak. For deepseek-v4-pro, cache hits are $0.044 peak and $0.022 off-peak. More in our DeepSeek V4.1 Flash guide.

Worked cost examples

The examples below use list prices from the table above (as of October 2026) and ignore taxes, regional uplifts and batch discounts.

Example 1: Support assistant on Claude Sonnet 5.5 (5-minute cache)

Setup: a 20,000-token static prefix (instructions plus product docs), 500 tokens of user input, and 400 output tokens per request. Traffic is 1,000 requests an hour, spread evenly, so the 5-minute cache stays warm after the first write.

• No caching, per request: input 20,500 × $2.00/1M = $0.041; output 400 × $10.00/1M = $0.004; total $0.045. Per hour: 1,000 × $0.045 = $45.00.
• First request (cache write): 20,000 × $2.50/1M = $0.050, plus 500 × $2.00/1M = $0.001, plus output $0.004 = $0.055.
• Each of the next 999 requests (cache read): 20,000 × $0.10/1M = $0.002, plus $0.001 input, plus $0.004 output = $0.007.
• With caching, per hour: $0.055 + (999 × $0.007) = $0.055 + $6.993 = $7.048.

That is an 84.3% reduction ($7.048 / $45.00 = 0.157). Once the prefix is cached, output tokens ($0.004 of the $0.007 per request) become the largest cost, so trimming verbose responses is the next lever.

Example 2: GPT-6.1 Sol, 30-minute vs 12-hour TTL

Setup: an internal tool with a 50,000-token prefix (codebase summary plus conventions). It gets 16 requests across a working day, roughly every 40 minutes. With the default 30-minute TTL, every request arrives after the previous entry has expired, so each one pays a fresh write. Prefix cost only; dynamic input and output are the same in both cases.

• 30m TTL: 16 writes × 50,000 × $2.50/1M = 16 × $0.125 = $2.00.
• 12h TTL: one write, 50,000 × $5.00/1M = $0.25, plus 15 reads × 50,000 × $0.10/1M = 15 × $0.005 = $0.075. Total $0.325.

The 12-hour option cuts the prefix bill by 83.75% here. The general break-even on GPT-6.1 Sol: a 12h write costs $2.50/1M more than a 30m write. Each request that would otherwise have rewritten the 30m cache instead reads at $0.10, saving $2.40/1M. One avoided rewrite does not quite cover the premium ($2.40 < $2.50), but two do ($4.80). So 12h pays off once at least two requests land after a 30m entry would have expired. On gpt-6-astra the numbers scale ($12.50 extra per write versus $11.50 saved per avoided rewrite), and the same two-request rule holds.

Example 3: Anthropic 5-minute vs 1-hour writes

On Sonnet 5.5, a 1-hour write costs $4.00/1M versus $2.50/1M for 5-minute, a $1.50 premium. An avoided 5-minute rewrite saves $2.50 − $0.10 = $2.40/1M. A single request arriving 6 to 60 minutes after the last one therefore covers the 1-hour premium. Compared with not caching at all, Anthropic's docs put the break-even at one read for 5-minute writes and two reads for 1-hour writes (at the standard 0.1x read rate). The same holds at Sonnet 5.5's 0.05x rate: the 1-hour write costs $2.00/1M over base input, and each read saves $1.90/1M, so the second read puts you ahead.

Example 4: DeepSeek deepseek-flash, peak vs off-peak

Setup: a 30,000-token cached prefix, 1,000 new input tokens and 500 output tokens per request.

• Peak, cache hit: 30,000 × $0.006/1M = $0.00018; 1,000 × $0.30/1M = $0.0003; 500 × $1.20/1M = $0.0006. Total $0.00108.
• Off-peak, cache hit: half of peak = $0.00054.
• Peak, full miss: 31,000 × $0.30/1M = $0.0093, plus $0.0006 output = $0.0099.

At this price level, the cache hit matters more than the time of day: a miss costs about 9x a hit at peak. Off-peak scheduling is a further 2x on top for batch-style jobs. For broader price comparisons, see cheapest fast LLM APIs compared.

When caching backfires

The Claude Haiku 5.5 100K cliff

Claude Haiku 5.5 is priced by prompt length. Anthropic's pricing page says a request's prompt length "counts all of its input tokens, including cache reads and cache writes." A request over 100,000 tokens pays the higher prices for everything, cached portion and output included. A cache hit does not shield you from the threshold.

Take a growing agent conversation with a 95,000-token cached prefix and 1,000 output tokens:

• 3,000 new tokens (98,000 total, under 100K): 95,000 × $0.01/1M = $0.00095; 3,000 × $0.10/1M = $0.0003; 1,000 × $0.50/1M = $0.0005. Total $0.00175.
• 6,000 new tokens (101,000 total, over 100K): 95,000 × $0.05/1M = $0.00475; 6,000 × $0.50/1M = $0.003; 1,000 × $2.50/1M = $0.0025. Total $0.01025.

About 3% more input tokens costs roughly 5.9x more per request ($0.01025 / $0.00175). On Haiku 5.5, cap or compact context below 100K (summarize old turns, drop stale tool results), and keep big cached reference documents from quietly pushing requests over the line.

Short-lived or one-off prompts

If a prefix is used once and never again before the TTL runs out, you pay the write premium for nothing. On Anthropic, an unused 5-minute write costs 25% more than plain input, and an unused 1-hour write costs 100% more. One-shot document analysis, low-traffic endpoints, and prompts that embed per-user data near the top are common examples. On OpenAI's GPT-5.6 and later models, writes are billed by default, so the same applies to prefixes that never get reused within 30 minutes.

12-hour writes that never get reused

A 12h write on OpenAI is 2.5x input, double the 30m write. If traffic is steady enough that the 30m cache never goes cold, 12h buys nothing and doubles every write. Use 12h for prefixes with gaps between requests longer than 30 minutes but shorter than 12 hours: internal tools, nightly-then-daytime workloads, or per-customer contexts revisited a few times a day. Do not set it as a global default.

Silent misses

• Prefixes under the minimum (512 tokens on Claude Fable 5.1, Opus 5.5, Sonnet 5.5 and Haiku 5.5, 1,024 on Claude Sonnet 5 and OpenAI GPT-5.6+, 4,096 on Gemini 4 Argon) are not cached, and no error is returned.
• Implicit and best-effort caches (Gemini 4 Argon, DeepSeek) give no hit guarantee, so budget with a realistic hit rate, not 100%.
• Timestamps, request IDs, or shuffled tool order early in the prompt turn every request into a miss.
• Changing reasoning effort or thinking settings can invalidate parts of the cache on Claude. On OpenAI, a September 3 changelog entry for GPT-6 Astra in the Responses API says you can change reasoning effort mid-conversation "while preserving the cached prompt prefix." The rule differs by provider and model, so check before you rely on it.

Best practices

1. Measure first. Log the cache usage fields on every request (cached_tokens/cache_write_tokens on OpenAI, cache_read_input_tokens/cache_creation_input_tokens on Anthropic, total_cached_tokens on Gemini, prompt_cache_hit_tokens on DeepSeek). Hit rate and write-to-read ratio are the two numbers that decide whether caching is saving money.
2. Freeze the prefix. Make tool definitions, system prompts and reference docs deterministic: stable ordering, no timestamps, consistent whitespace and serialization.
3. Match TTL to traffic. Steady traffic: default TTL. Bursty traffic with gaps under an hour: Anthropic 1h. Gaps of 30 minutes to 12 hours on OpenAI GPT-5.6+: 12h, if at least two requests per window would otherwise miss.
4. Place breakpoints deliberately on Claude. Put stable layers (tools, system, docs) behind separate breakpoints so a change to one layer does not invalidate the others. Remember the four-breakpoint limit.
5. Watch pricing thresholds. On Haiku 5.5 (100K) and OpenAI long context (272K), count cached tokens when you estimate cost.
6. Combine with other levers. Caching stacks with batch discounts (Anthropic multipliers stack with Batch API pricing), off-peak pricing (DeepSeek), model routing, and output-length limits.

Benefits beyond cost

• Lower latency. Skipping prefill on a long cached prefix reduces time-to-first-token, which matters for chat and coding assistants with large contexts.
• Cheaper long-context designs. Agents that resend a large codebase summary or document set every turn become affordable when most of that context bills at 2% to 10% of input.
• Room for richer prompts. With reads this cheap, putting more examples and documentation into a cached system prompt can cost less than retrieving them per request.

FAQ

How much does prompt caching save?

On the cached portion, a hit costs 2.5% to 10% of base input on OpenAI and Anthropic, 5% on Gemini 4 Argon, and about 2% on DeepSeek deepseek-flash (as of October 2026). Total savings depend on what share of each request is cacheable, your hit rate, and how much of your bill is output. In the Sonnet 5.5 example above, a 20K-token prefix with a warm cache cut hourly cost by about 84%.

Does OpenAI charge for prompt cache writes now?

Yes, for GPT-5.6 and later. A 30-minute write is billed at 1.25x input; in the Responses API you can also choose a 12-hour write at 2.5x. Both rates replace the normal input rate rather than adding to it. Earlier models have no write charge.

Is the 12-hour cache available in the Chat Completions API?

OpenAI's prompt caching guide documents the "12h" TTL (set with prompt_cache_options.ttl) for the Responses API and does not mention Chat Completions support. The October 20 changelog entry is also tagged for the Responses API. Test it before you depend on it in Chat Completions.

Do cached tokens count toward Claude Haiku 5.5's 100K threshold?

Yes. Anthropic counts cache reads and cache writes in a request's prompt length. A request over 100,000 tokens pays the higher rates for all of its tokens, including the cached ones.

Can I control caching on Gemini 4 Argon?

No. Argon supports implicit caching only. You can raise hit rates by putting shared content first and keeping prompts above the 4,096-token minimum, but you cannot create explicit cache objects.

Is prompt caching the same as caching LLM responses?

No. Prompt caching reuses the processed input prefix, and the model still generates and bills a new response. Response caching returns a stored answer without calling the model, and you implement it in your own application.

If you are building LLM features and want someone who already thinks in cache hit rates and token budgets, Codersera can help you hire vetted remote AI developers who fit your stack.

Sources

• OpenAI API pricing
• OpenAI API changelog (12-hour prompt caching, October 20, 2026)
• OpenAI prompt caching guide
• Anthropic Claude pricing
• Anthropic prompt caching docs
• Gemini API pricing
• Gemini API context caching docs
• DeepSeek API pricing
• DeepSeek context caching guide