# Prompt caching pricing 101: what actually changes on your bill

*Three providers, three incompatible cost shapes, and three rules of thumb that will survive the next repricing. Plus the arithmetic, so you can check them against your own traffic.*

---

If you read one piece in this series, read this one. It's the version for people who approve invoices rather than write breakpoints.

The headline: prompt caching is not one discount. It's a set of trades, and each provider asks you to make a different one. Anthropic asks you to predict your request cadence. OpenAI asks you to place a boundary correctly. Google asks you to manage inventory. Get the trade wrong and caching costs you more than not caching — which is a sentence most teams don't believe until they see it on a bill.

For the vocabulary underneath this, start with [the glossary](/updates/llm-prompt-caching-what-it-is-and-key-terms-explained).

## First, the thing that caps your upside

> **Cost shape:** caching discounts input tokens only. Never output.

No provider's caching touches output cost. If half your spend is output tokens, the theoretical ceiling on caching savings is the other half — before any implementation reality. This is the single most common source of over-forecasting, and it takes ten seconds to check: pull the input/output split on your largest workload before you model anything else.

## Chart one: the pricing mechanics

All three providers converge on the same read discount — 90% off base input — and diverge on everything else.

| | **Anthropic** | **OpenAI (GPT-5.6+)** | **Google Gemini (explicit)** |
|---|---|---|---|
| Cache read | 0.1× base input | 0.1× base input | 0.1× base input |
| Cache write | 1.25× (5-min TTL)<br>2.0× (1-hour TTL) | 1.25× | 1.0× — no write premium |
| Idle storage fee | None | None | **Per token, per hour, while the cache exists** |
| Free refresh on read | Yes | Yes | No — wall-clock expiry |
| TTL choice | 5 min or 1 hour | 30 min only | Any duration you set; defaults to 1 hour |
| Who pays for a wasted write | You, at 1.25× or 2× | You, at 1.25× | Nobody — writes are at par |

Sources: [Anthropic prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching), [OpenAI prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching), [Gemini pricing](https://ai.google.dev/gemini-api/docs/pricing).

Two things jump out. First, **Anthropic and OpenAI have converged.** OpenAI shipped automatic caching in 2024 as explicitly the anti-Anthropic design — no code changes, no write fee. On GPT-5.6 and later, writes cost 1.25× the uncached input rate, breakpoints are developer-placeable, and there's a `cache_write_tokens` counter. Anthropic went the other direction and added automatic caching. If you learned one provider's model in 2024, you are not being billed on it now.

Second, **Google is the odd one out in both directions.** Its writes are free, which makes cache creation risk-free. Its storage is not, which makes cache *retention* the risk instead. The other two charge you to start; Google charges you to keep.

## Chart two: the operational constraints

Different table, because these don't affect your rate — they affect whether you get a hit at all.

| | **Anthropic** | **OpenAI (GPT-5.6+)** | **Google Gemini** |
|---|---|---|---|
| Minimum cacheable prefix | 512–4,096 tokens, by model | 1,024 tokens | 2,048–4,096 (implicit) |
| Below the minimum | Silently uncached, no error | Not eligible | Not eligible |
| Breakpoints per request | 4 | 4 new writes; reads look back 50 | N/A — resource-based |
| Lookback window | 20 blocks | 50 breakpoints | N/A |
| Throughput constraint | — | ~15 req/min per `prompt_cache_key` | — |
| Cache isolation | Per workspace (org-level on Bedrock and Google Cloud) | Per organization | Per project |
| Manual deletion | Not possible | Not possible | Required, or you pay until TTL |

The throughput constraint on OpenAI deserves a flag: [keeping traffic per cache key to roughly 15 requests per minute](https://developers.openai.com/api/docs/guides/prompt-caching) is a real ceiling, and above it some requests just miss. High-volume workloads need key sharding with a stable mapping. Nothing in the pricing tells you this.

The isolation row deserves another. Anthropic caches are [isolated per workspace](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) on the Claude API, AWS, and Foundry, but organisation-level on Bedrock and Google Cloud. If you've split teams into workspaces, you may have quietly fragmented your hit rate on some platforms and not others.

## Rule one: two lapses buys the hour

> **Applies to:** Anthropic only. The one place TTL is a price lever.

Anthropic's 5-minute cache is [refreshed at no additional cost each time it's used](https://platform.claude.com/docs/en/build-with-claude/prompt-caching). So under steady traffic it never expires, and you pay exactly one write forever. The 1-hour tier costs double on write and buys you nothing in that scenario.

The decision therefore isn't "how long is my session." It's **how many times would the 5-minute cache expire and need rewriting?** Work the algebra and the read costs cancel out entirely — they're identical on both tiers — leaving a break-even at 1.65 lapses. Round up:

**Two or more expected lapses, buy the hour. One, stay on five minutes.**

That threshold is independent of request volume and independent of prefix size. It's pure multipliers, which means it survives repricing as long as the 1.25× / 2× / 0.1× structure holds.

## Rule two: thirty minutes of dead air is the ping threshold

> **Applies to:** Anthropic. The keep-alive question, answered with arithmetic.

Anthropic supports [cache pre-warming with `max_tokens: 0`](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) — the API reads your prompt, writes the cache, and returns immediately with an empty content array and zero output tokens billed. Their guidance for the 5-minute cache is to fire one at least every five minutes to keep it warm.

So: can you hold a cache open cheaply by pinging it? Yes — but a ping is a read, and a read costs 0.1× of the *entire* prefix, not one token. Set the keep-alive cost (one write plus a ping every four minutes) against a single 1-hour write and the crossover lands at 7.5 pings:

**Under ~30 minutes of dead air, ping it warm. Over 30 minutes, pay for the hour.**

Also size-independent. Two caveats before anyone builds on it: a pre-warm [incurs a write charge if the prefix isn't already cached](https://platform.claude.com/docs/en/build-with-claude/prompt-caching), so the arithmetic assumes your pings are landing as hits — one miss and you've paid 1.25× again. And `max_tokens: 0` is rejected with streaming, extended thinking, structured outputs, forced tool choice, and inside Batches.

## Rule three: three reads an hour is Gemini's floor

> **Applies to:** Gemini explicit caching. The rule that stops caching from costing you money.

Google's explicit caching has no write premium and no refresh. Instead you pay rent. So the question isn't cadence at all — it's whether the discount on actual reads covers the storage fee.

Divide the hourly storage rate by the per-token saving on a read and you get a break-even in **reads per hour, per cached prefix**. On Gemini 3.1 Pro Preview at published rates that's 2.5 reads/hour. On 2.5 Pro it's 4.0. On the Flash line it's under 1. Rounding to something memorable across the Pro tier:

**Below ~3 reads per hour per prefix, explicit caching is costing you money. Use implicit instead.**

At one read an hour on 3.1 Pro you're paying more than double what you'd pay uncached. And the failure mode is unbounded in a way the other providers have no equivalent for: a forgotten 1M-token cache on 3.1 Pro runs $4.50 an hour, $108 a day, $756 a week, with nothing reading it.

## What this means for how you instrument

The three rules imply three different metrics, and most teams collect none of them.

For **Anthropic**, log the *start-to-start* gap between consecutive requests sharing a prefix — not session length, and not the gap between response end and next request start. Anthropic measures TTL from request start, so generation time is inside your window.

For **OpenAI**, log `cache_write_tokens` against `cached_tokens`. High writes with low reads means a breakpoint sitting on content that changes, and on current models that's a 1.25× charge repeating forever.

For **Gemini**, log reads per hour per cache resource, and audit for orphans. Storage accrues on the resource and appears on no per-request counter, so nothing in your request logs will ever show it.

## The word is doing too much work

"Caching" now names three different bargains. One provider sells you a cadence bet, one sells you a placement problem, one rents you shelf space. The rules above are portable because they're built from ratios rather than rates — but the reason you need three of them is that there is no single thing to know.

## Deep dives for different inference providers

- **[Anthropic prompt caching: the TTL bet, worked four ways](/updates/llm-prompt-caching-anthropic-how-to-and-pro-tips)**
- **[OpenAI prompt caching after GPT-5.6: free writes are over](/updates/llm-prompt-caching-openai-how-to-and-pro-tips)**
- **[Gemini context caching: the only cache that bills you for doing nothing](/updates/llm-prompt-caching-gemini-how-to-and-pro-tips)**

*Coolhand Labs tracks inference pricing across providers, including TTL tiers and storage dimensions most catalogs can't represent. [See what we track](https://coolhandlabs.com/inference-apis).*