Prompt caching across providers: when it pays

Prompt caching is usually described as a lower rate for repeated input. That is half of it. On the two largest providers the request that creates a cache entry is billed above the normal input rate, so a cache that is written often and read rarely raises the bill. Whether caching lowers your estimated provider cost is a question about reuse: how many requests read a prefix inside the time it stays cached.

This analysis states each provider's published rules, turns them into a break-even hit rate, and ends with how to check the result on real traffic.

What each provider charges

The mechanics are similar everywhere — the provider recognises that the start of a request matches one it processed recently and bills those tokens at a reduced rate — but the prices, minimums and lifetimes are not.

OpenAI. On GPT-5.6 and later, caching applies to prompts of at least 1,024 visible input tokens, a cache write is billed at 1.25x the uncached input rate, and an entry lives for 30 minutes after its most recent write or reuse¹. Earlier models charged no write premium. The pricing page lists the three rates side by side: GPT-6 Sol is $2.00 input, $0.20 cached input and $2.50 cache write per 1M tokens, and GPT-6 Astra is $10.00, $1.00 and $12.50². Usage reports cached_tokens and cache_write_tokens under the input token details¹.

Anthropic. Caching is requested with cache_control, either once at the top level of the request (the system moves the breakpoint forward as a conversation grows) or on up to four individual blocks. A five-minute write costs 1.25x base input and a one-hour write 2x; a read costs 0.1x on most models, 0.05x on Claude Opus 5.5 and 0.025x on Claude Fable 5.1³. Each hit refreshes the entry at no extra cost. The minimum cacheable prompt is 512 tokens on Fable 5.1, Opus 5.5 and Sonnet 5.5, 1,024 on Sonnet 5, and 4,096 on Haiku 4.5³. Anthropic's own pricing page states the consequence: caching pays off after one read at the five-minute duration and after two at the one-hour duration⁴.

Google Gemini. Implicit caching is on by default for Gemini 2.5 and newer, with a 4,096-token minimum on the 3.x Flash models and Gemini 3.1 Pro⁵. There is no write premium for an implicit hit. The cached rate is a tenth of input: Gemini 3.8 Flash lists $0.75 input and $0.075 context caching per 1M tokens through 2026-12-31. Explicit caches also bill storage, $0.50 per 1M tokens per hour on 3.8 Flash and $4.50 on 3.1 Pro⁶.

DeepSeek. Caching on disk is enabled by default, matches on prefix units, and entries are cleared within hours to days once unused⁷. There is no write charge; a hit on deepseek-flash is $0.006 against $0.30 for a miss at peak rates, roughly 0.02x⁸. Usage reports prompt_cache_hit_tokens and prompt_cache_miss_tokens⁷.

The break-even formula

Take a prefix of P tokens that repeats across requests, an input rate of in, a write multiplier W and a read multiplier R. Without caching, every request pays P × in for the prefix. With caching, a request that misses pays W × P × in and a request that hits pays R × P × in.

If a share h of requests hit, the expected prefix cost per request, relative to no caching, is:

relative_cost = h × R + (1 − h) × W
caching lowers cost when  h > (W − 1) / (W − R)

The same result expressed as reuse: one write followed by N reads costs less than N + 1 uncached requests when N > (W − 1) / (1 − R). For a five-minute Anthropic entry that is N > 0.28, one read. For a one-hour entry it is N > 1.11, two reads — the figures Anthropic publishes⁴.

Three things fall out of the numbers:

• The read rate barely moves break-even. Fable 5.1's 0.025x read lowers its five-minute break-even from 21.7% to 20.4%. The write premium dominates.
• The one-hour cache is a bet on sparse traffic. It doubles the write cost to keep an entry alive twelve times longer. It pays when requests arrive more than five minutes apart but still reuse the prefix, and loses when traffic is dense enough that a five-minute entry would have stayed warm anyway.
• With no write premium, any hit lowers cost. On Gemini implicit caching and DeepSeek, the only question is whether the prefix is long enough to be cached at all.

A request, three ways

Explicit caches add a clock

Gemini's explicit caches trade the per-request write premium for a storage charge per token-hour. The break-even is then about request rate, not hit share.

What breaks a cache in production

The published rules are the ceiling. Real hit rates depend on whether the prefix is byte-for-byte stable and whether requests land where the cache lives.

• A changing first line. A timestamp, request id or user name interpolated into the system prompt makes every prefix unique. Put volatile values in the last message.
• Reordered tools. Tool definitions are part of the prefix. Serialize them in a fixed order.
• Changing request parameters. On Anthropic, changing the thinking configuration or effort level between requests invalidates cache breakpoints; see reasoning tokens.
• Traffic spread across accounts. A cache belongs to the account and deployment that served the request. Load balancing across accounts, or a failover, starts cold.
• Gaps longer than the lifetime. A five-minute entry is gone after five quiet minutes. Low-volume, bursty workloads often never reach break-even.
• Batch jobs. Anthropic supports caching inside Message Batches and says the caching and batch rate reductions stack, but hits are best-effort because requests run concurrently; it reports typical hit rates of 30% to 98%⁹.

Measure the hit rate you actually get

Compute the cached share of prompt tokens per model and route, daily. It is a better leading indicator than cost, because cost also moves with volume and output length.

from collections import defaultdict

def cache_share(rows):
    """rows: dicts with model, prompt_tokens and cached_tokens per request."""
    totals = defaultdict(lambda: [0, 0])
    for r in rows:
        totals[r["model"]][0] += r.get("cached_tokens") or 0
        totals[r["model"]][1] += r["prompt_tokens"]
    return {m: (c / p if p else None) for m, (c, p) in totals.items()}

def breakeven(write_mult: float, read_mult: float) -> float:
    return (write_mult - 1) / (write_mult - read_mult) if write_mult > 1 else 0.0

print(round(breakeven(1.25, 0.1), 3))   # 0.217
print(round(breakeven(2.0, 0.1), 3))    # 0.526

Token share and request hit rate are not the same number, but when the cached prefix is most of each prompt they move together, and a sudden drop in either means the prefix changed.

Prompt caching through INFRO

INFRO does not cache prompts itself; caching happens at the provider, on your account, at your provider's rates. INFRO forwards requests unchanged, including Anthropic cache_control on text content parts and tool definitions, and reports the provider's cached-token count in usage.prompt_tokens_details.cached_tokens on streaming and non-streaming responses. The estimate in usage.cost prices cached tokens at the cached rate, and prices cache writes at the write rate where the catalog carries one for the model. See prompt caching.

Two INFRO features watch the hit rate for you. Traffic changes raises a finding when the cached share of prompt tokens on a model or route drops by at least 10 percentage points against its usual day, with the estimated weekly change in provider cost. And because caches do not follow a failover, a rising fallback share in the same place usually explains a falling cache share. If your contract carries its own cached-input rate, enter it as a negotiated rate so estimates use it; reconciliation flags cache-write pricing the estimate did not model.