VynarisEarly betaGet your API key

Blog · 2026-07-15 · Vynaris Team

Prompt caching break-even: below 21.7% hit rate, caching costs more

Below a 21.7% hit rate (5-min cache) or 52.6% (1-hour), prompt caching costs more than not caching. Per-provider break-even math, verified 2026-07-15.

Caching stopped being automatic free money. OpenAI now charges a 1.25x premium to write the cache on its GPT-5.6 family, matching Anthropic's long-standing 1.25x, and that write fee creates a floor: below a 21.7% cache-hit rate on the five-minute cache, prompt caching costs more than not caching at all. Prices verified 2026-07-15 against each provider's live pricing page.

TL;DR

What we computed and why

Every guide tells you to turn on caching. Almost none tell you when it loses money. Caching a prefix is a bet: you pay a write cost up front, then hope enough later requests read that prefix at the discounted rate to more than repay the write. When the reads do not arrive, or the cache expires between them, you paid the premium for nothing.

Two things changed the arithmetic this year. First, OpenAI added a 1.25x cache-write charge on its GPT-5.6 models, so a cache miss now costs more than a plain uncached request instead of the same. Second, agentic workloads pushed cached input to the majority of many teams' bills. One Hacker News comment on the "AI margin collapse" thread (693 points) put cached input at roughly 90% of an agentic coding tool's API cost. When one line item is 90% of the bill, the rules that govern it are worth deriving exactly.

So we derived the break-even hit rate for each provider's pricing model, from the published multipliers only. No internal data, no benchmarks. Just the formula and the numbers on the pricing pages.

The two pricing models

Providers charge for caching in one of two shapes.

Multiplier model (Anthropic, OpenAI). A cache write costs a multiple of the base input-token price; a cache read costs a small fraction of it. Anthropic's page states the multipliers directly:

Cache operation       Multiplier        Duration
--------------------  ----------------  ------------------------
5-minute cache write  1.25x base input  cache valid 5 minutes
1-hour cache write    2x base input     cache valid 1 hour
Cache read (hit)      0.1x base input   same window as the write

OpenAI's GPT-5.6 family uses the same shape: cache write 1.25x, cache read 0.1x. OpenAI's GPT-5.5 keeps the old model, where a write is billed at the normal input rate (no premium) and a hit still costs 0.1x.

Storage-rent model (Google Gemini explicit caching). You pay to process the content once, then rent storage per hour for as long as you keep it cached, and reads come at 0.1x. There is no per-write multiplier; the hourly rent is the cost you are betting against.

The break-even formula

Take a stable prefix of P tokens sent on every request. With caching on, each request either hits (pays the read multiplier) or misses (the cache is cold or expired, so it re-writes, paying the write multiplier). Let h be the fraction of requests that hit. The per-request prefix cost, in units of the base input price, is:

cost_with_caching  = h * read_mult + (1 - h) * write_mult
cost_without_cache = 1.0

Setting them equal and solving for the break-even hit rate:

h* = (write_mult - 1) / (write_mult - read_mult)

For the five-minute cache: (1.25 - 1) / (1.25 - 0.1) = 0.25 / 1.15 = 21.7%. For the one-hour cache: (2 - 1) / (2 - 0.1) = 1 / 1.9 = 52.6%. When there is no write premium (write_mult = 1.0), the numerator is zero, so h* is 0%: any hit at all lowers the bill.

Break-even by provider

Cache-hit rate needed to break even, by provider and cache tier; below the bar caching costs more than not caching
Break-even hit rate by provider/tier. Write premium creates the floor: 5-min write 1.25x, 1-hour 2x, read 0.1x. Sources: Anthropic, OpenAI, DeepSeek pricing verified 2026-07-15.
Provider / tier   Write              Read    Break-even hit rate
----------------  -----------------  ------  -------------------
OpenAI GPT-5.5    1.0x (no premium)  0.1x    0% (any hit saves)
DeepSeek v4       1.0x (no premium)  ~0.02x  0% (any hit saves)
Anthropic 5-min   1.25x              0.1x    21.7%
OpenAI GPT-5.6    1.25x              0.1x    21.7%
Anthropic 1-hour  2x                 0.1x    52.6%

The gap between the top and bottom rows is the whole story. On a no-premium provider, caching is a strict improvement and you should default it on. On a 1.25x-write provider, caching a prefix that most requests will not reuse within five minutes is a surcharge. On the one-hour cache you need better than a coin flip.

The discount at the other end

The break-even is the floor. The ceiling is worth naming too, because it explains why teams tolerate the risk. As the hit rate climbs, the effective prefix cost falls toward the read rate of 0.1x, a 90% discount. Here is the per-request prefix cost, again in units of the base input price:

Hit rate  Anthropic 5-min     Anthropic 1-hour    No-premium (GPT-5.5)
--------  ------------------  ------------------  --------------------
10%       1.135 (a tax)       1.810 (a tax)       0.910
21.7%     1.000 (break-even)  1.587               0.804
52.6%     0.645               1.000 (break-even)  0.526
90%       0.235               0.290               0.190
100%      0.100 (90% off)     0.100 (90% off)     0.100

A well-kept cache at 90%+ hit rate is the largest single lever in agent cost, which is exactly why cached input balloons to most of the bill. The trap is assuming you live at the right end of this table when your traffic pattern puts you at the left.

A worked dollar example

Take a 40,000-token stable prefix, 1,000 requests, on Claude Opus 4.8 (base input $5/MTok, five-minute write $6.25, read $0.50):

Hit rate  With caching  Without caching  Result
--------  ------------  ---------------  ----------------------
10%       $227.00       $200.00          caching costs $27 more
21.7%     $200.00       $200.00          break-even
50%       $135.00       $200.00          caching saves $65
90%       $43.00        $200.00          caching saves $157

The 10% row is the one people do not expect. You turned caching on, your hit rate was low because the prefix rarely repeated inside the window, and you paid 13.5% more than if you had left it off. Run your own prefix size, hit rate, and model through the calculator before assuming the feature is saving you money.

Gemini is a different bet

Gemini's explicit context caching does not charge a write multiplier. It rents storage by the hour, so its break-even is a reads-per-hour number, not a hit-rate percentage. Caching saves (base input minus cached read) on each read but costs the hourly rent whether or not anyone reads:

Model                   Base input  Cached read  Storage rent   Break-even
----------------------  ----------  -----------  -------------  --------------
Gemini 2.5 Flash        $0.30/MTok  $0.03/MTok   $1.00/MTok/hr  3.7 reads/hour
Gemini 2.5 Pro (≤200k)  $1.25/MTok  $0.125/MTok  $4.50/MTok/hr  4.0 reads/hour
Gemini 2.5 Pro (>200k)  $2.50/MTok  $0.25/MTok   $4.50/MTok/hr  2.0 reads/hour

Below roughly two to four reads per hour of the cached content, the rent exceeds the read savings and you are paying to store data nobody is using. Large prompts break even faster because each read saves more against the same flat rent. Gemini also offers implicit caching, which is automatic and carries no storage fee, but you do not control what it caches or for how long.

What it means for routing

Two operational rules fall out of this.

First, match the cache tier to the reuse window. The one-hour cache only makes sense if the same prefix will be read many times across an hour; its 2x write and 52.6% break-even punish sparse reuse. For bursty interactive traffic, the five-minute cache with its 21.7% floor is the safer default, and for one-shot requests, turn caching off entirely.

Second, cross-model routing multiplies the write cost. Caches are per model. Every time a router hands a turn to a different model, the new model must write its own copy of the prefix and pay the premium again. That is a large part of why interleaved routing saves less than batched routing, a number we work through in the coding-agent router savings analysis. The related failure, re-writing a cache you already paid for, is priced out in the cache-write churn teardown.

Where we are wrong

The break-even hit rate is exact given the multipliers, but the hit rate itself is the hard part to know in advance, and it is the input that decides everything. The honest way to measure it is to read your own usage response: the ratio of cache-read tokens to cache-creation tokens across a representative window is your real hit rate. Plug that into the formula, not an optimistic guess.

Three caveats. The Batch API halves both write and read on Anthropic, so the ratios hold but absolute dollars fall for non-interactive work. These are first-party rates; Bedrock, Vertex, and data-residency endpoints carry their own multipliers that stack on top. And Anthropic's Sonnet 5 introductory pricing ends 2026-08-31, which changes the absolute dollars though not the break-even percentages, since the multipliers are unchanged. We re-verify every price in this post monthly.

Sources

Prices change. Numbers are current as of 2026-07-15; we re-verify monthly and stamp updates.

Want your real cache-hit rate priced across providers? Vynaris is an OpenAI-compatible gateway that routes each request to the cheapest right-sized model and shows the per-request cost, cache included. One base URL swap. Get an API key at vynaris.com.