Blog · 2026-07-17 · Vynaris Team

Prompt caching in production: exact cache prices and the break-even hit rate per provider

Prompt caching only pays above a break-even hit rate: 21.7% on Anthropic 5-min and GPT-5.6 (OpenAI's first cache-write fee), 52.6% on 1-hour, 0% on DeepSeek. Cache prices verified 2026-07-17.

Prompt caching is not free money, and as of GPT-5.6 it is not free on OpenAI either. gpt-5.6-sol is the first OpenAI model line the pricing page charges a cache-write fee for (about 1.25x input), which means "always enable caching" is now conditionally wrong on OpenAI the same way it already was on Anthropic. Below a hit rate of 21.7% the write fee costs more than the reads save. Cache prices verified 2026-07-17.

TL;DR

On a 1.25x-write / 0.1x-read structure (Anthropic 5-minute cache and GPT-5.6), caching only pays once your cache-hit rate clears 21.7%. On Anthropic's 1-hour cache (2x write) the break-even is 52.6%. On DeepSeek and pre-5.6 OpenAI, which charge no write fee, it is 0% (caching always pays).
A high-reuse workload wins enormously: a 20,000-token system prompt reused across 100,000 requests/day on gpt-5.6-terra drops from $5,125/day to $625/day in input cost, 88% less.
A slow chat whose turns are minutes apart, or a batch where every request has a different prefix, can cost 25% more with caching on than off, because you pay the write premium and never collect the reads.

The one number that decides it: break-even hit rate

Every provider that offers prompt caching charges two things: a one-time write to store the prefix, and a cheap read every time you reuse it. The read is uniformly cheap (0.1x the base input token price on Anthropic and OpenAI). The write is where providers differ, and the write is what turns caching from a discount into a tax when reuse is low.

The break-even is a hit rate you can compute. With a base input price of 1, a cache read costing r (=0.1), and a cache write costing w times base, the expected input cost per request at hit rate h is h*r + (1-h)*w. Set that equal to the no-cache cost (=1) and solve:

h* = (w - 1) / (w - r)

That formula gives the hit rate below which caching costs more than it saves:

Cache mode                                  Write multiplier  Break-even hit rate
------------------------------------------  ----------------  -------------------
DeepSeek v4, pre-5.6 OpenAI (no write fee)  1.0x              0.0%
Anthropic 5-minute, GPT-5.6                 1.25x             21.7%
Anthropic 1-hour                            2.0x              52.6%

Prompt-cache input cost as a fraction of the no-cache bill vs cache-hit rate, for three write regimes — Input cost relative to not caching, by hit rate. Each curve crosses 1.0 at its break-even. Cache read = 0.1x input. Prices verified 2026-07-17.

Anthropic states this outright on its pricing page: caching "pays off after just one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write)." The 21.7% and 52.6% are the same fact expressed as a steady-state hit rate. We derived the full per-provider table in the break-even post; this guide is about wiring it into a real workload.

The exact cache prices, verified 2026-07-17

Provider / model                                                   Base input $/1M  Cache read $/1M  Cache write             Structure
-----------------------------------------------------------------  ---------------  ---------------  ----------------------  ----------------------------------
gpt-5.6-sol                                                        $5.00            $0.50 (0.1x)     $6.25 (1.25x)           first OpenAI line with a write fee
gpt-5.6-terra                                                      $2.50            $0.25 (0.1x)     $3.125 (1.25x)          write fee
[gpt-5.6-luna](https://vynaris.com/models#gpt-5-6-luna)            $1.00            $0.10 (0.1x)     $1.25 (1.25x)           write fee
Claude Opus 4.8                                                    $5.00            $0.50 (0.1x)     $6.25 (5m) / $10 (1h)   1.25x / 2x write
Claude Fable 5                                                     $10.00           $1.00 (0.1x)     $12.50 (5m) / $20 (1h)  1.25x / 2x write
[deepseek-v4-flash](https://vynaris.com/models#deepseek-v4-flash)  $0.14 (miss)     $0.0028 (hit)    none                    hit = 2% of miss
deepseek-v4-pro                                                    $0.435 (miss)    $0.003625 (hit)  none                    hit = 0.83% of miss
Gemini 3.1 Pro Preview                                             $2.00            $0.20 (0.1x)     $4.50/1M/hr storage     storage rent, not a write

Two structural notes decide how you use each. First, DeepSeek charges no write fee and its cache-hit read is far cheaper as a fraction of the miss price (2% on v4-flash, 0.83% on v4-pro) than Anthropic's or OpenAI's flat 10%. So DeepSeek caching both always pays and saves deeper. Second, Gemini does not charge a write; it rents storage at $4.50 per 1M cached tokens per hour, so its break-even is a reads-per-hour number, not a hit rate: at $1.80 saved per 1M tokens read, you need 2.5 reads per hour per cached million tokens to cover the rent.

Worked workload: where caching is a landslide win

Take a classification or extraction service with a 20,000-token stable system prompt (instructions plus few-shot examples), adding 500 new tokens of content per request, running 100,000 requests a day on gpt-5.6-terra. The prefix is byte-identical on every call, so the hit rate is close to 100% as long as traffic keeps the cache warm.

            Input cost per request  Per day (100k requests)
----------  ----------------------  -----------------------
No caching  $0.05125                $5,125.00
Caching on  $0.00625                $625.00
Saving      88%                     $4,500/day

The no-cache request pays full $2.50/1M on all 20,500 tokens. The cached request pays $0.25/1M on the 20,000-token prefix (a read) and full price on only the 500 new tokens. That is the ideal case for caching: a large stable prefix, high reuse, warm cache. This is the single highest-impact change most teams running a fixed-prompt service have not made. Before you commit, run your own prefix size and hit rate through the calculator to see the daily number for your traffic.

Worked workload: where caching quietly costs you money

Now the cases the "always cache" advice gets wrong.

A chat with slow turns. A support conversation where the user reads, thinks, and replies every few minutes will blow past the 5-minute cache window between turns. Each new turn finds an expired cache, so it re-writes the whole prefix at 1.25x and collects zero discounted reads. The effective hit rate sits near 0%, well under the 21.7% break-even, and you pay a flat 25% premium on the prefix for nothing. Moving to the 1-hour cache raises the write to 2x and the break-even to 52.6%, which a one-user conversation almost never clears. The fix is not a longer cache; it is caching only the stable system prefix, not the whole growing history, and accepting that a slow single conversation is a poor caching candidate.

A batch where every request is different. Document processing where each document is unique has no shared prefix beyond the system prompt. If you cache the per-document content, the hit rate is 0%, and on a write-fee provider you again pay 25% extra. On DeepSeek or a pre-5.6 OpenAI model the write is free, so leaving caching on is harmless there, which is exactly why the provider's write structure changes your default.

The churn version of this is worse: if a mid-session change invalidates a cached prefix and forces a re-write on every step, the write premium compounds. We took that failure mode apart in the cache-write churn post; the lesson is to keep volatile content (timestamps, request IDs, per-turn state) out of the cached prefix.

The DIY implementation path

You do not need a gateway to get most of this. The mechanics, provider by provider:

Anthropic. Add a cache_control breakpoint at the end of your stable prefix (system prompt, tool schemas, fixed context). Automatic caching manages breakpoints as the conversation grows; explicit breakpoints give you control over exactly what is cached. Cache the stable head, never the volatile tail. Minimum cacheable block sizes apply, so very short prefixes will not cache.
OpenAI GPT-5.6. Caching is automatic on repeated prefixes, but now that a write is billed (1.25x), the same break-even applies: keep the shared prefix long and stable, and do not assume caching is costless the way it was pre-5.6.
DeepSeek. Context caching is automatic and free to write, so structure your prompt with the stable content first and the variable content last, and the cache hit follows the prefix. Because the hit is 2% of the miss, prefix determinism is worth more here than a model swap.
Gemini. Explicit caching rents storage by the hour, so cache only content you will read at least 2.5 times per hour per cached million tokens, and delete caches you are done with rather than letting them rent silently.

The one rule that spans all four: order your prompt stable-first, volatile-last, and set the cache boundary between them. A single timestamp near the top of a prompt can knock the whole prefix out of cache on every call.

When caching does not pay: a checklist

Leave caching off, or expect it to cost more, when:

Your reuse is below the break-even hit rate for the provider's write mode (21.7% for 5-minute / GPT-5.6, 52.6% for 1-hour).
Requests are minutes apart and the cache window expires between them.
Every request has a unique prefix, so there is nothing to reuse.
The prefix is smaller than the provider's minimum cacheable block.
Volatile tokens (timestamps, IDs, per-request state) sit inside the prefix and invalidate it every call.

On a no-write-fee provider (DeepSeek, pre-5.6 OpenAI) none of these cost you extra, so caching is safe to leave on by default. On a write-fee provider (Anthropic, GPT-5.6) each one turns caching into a tax.

The gateway path

If you route across providers, the caching decision moves per request, and a gateway can make it without you hand-tuning each call. An OpenAI-compatible gateway can hold the stable prefix warm, apply caching only where the hit rate clears the provider's break-even, and keep volatile content out of the cached block. The model routing point is that the right cache decision depends on the model you land on, because the write fee is now a per-provider variable, not a constant. That is the case for putting the decision behind one base URL instead of in every call site.

FAQ

Does prompt caching always save money? No. It saves money only above a break-even hit rate set by the provider's cache-write fee: 21.7% on Anthropic's 5-minute cache and GPT-5.6, 52.6% on Anthropic's 1-hour cache, and 0% on DeepSeek and pre-5.6 OpenAI, which charge no write. Below the break-even you pay the write premium and lose.

What changed with GPT-5.6? GPT-5.6 is the first OpenAI model line whose pricing page lists an explicit cache-write charge, about 1.25x the input price (Sol $6.25 write vs $5 input). Earlier OpenAI models discounted cached reads without a separate write line. It brings the same break-even math that Anthropic already had to OpenAI.

What is the cache-hit price? On Anthropic and GPT-5.6 a cache read is 0.1x the base input price (for example $0.50/1M on gpt-5.6-sol against $5 input). DeepSeek is steeper: a hit is 2% of the miss on v4-flash and 0.83% on v4-pro. Gemini reads at 0.1x but adds hourly storage rent.

How do I cache a growing chat prompt? Cache the stable system prefix only, and place the cache-hit boundary before the conversation history. Keep timestamps and per-turn state out of the cached block. If turns are minutes apart, expect the window to expire and the hit rate to fall below break-even.

Is caching worth it on DeepSeek? Yes, essentially always, because DeepSeek charges no write fee and its cache hit is 2% or less of the miss price. Order your prompt stable-first so the prefix hits, and prefix determinism will move your bill more than switching models.

Sources

OpenAI API pricing (GPT-5.6 cached input and cache-write rates), captured 2026-07-17: https://developers.openai.com/api/docs/pricing
Anthropic pricing (prompt-caching multipliers, the "pays off after one/two reads" note), captured 2026-07-17: https://platform.claude.com/docs/en/docs/about-claude/pricing
DeepSeek API pricing (cache-hit vs cache-miss input), captured 2026-07-17: https://api-docs.deepseek.com/quick_start/pricing
Google Gemini API pricing (context caching read and storage rate), captured 2026-07-17: https://ai.google.dev/gemini-api/docs/pricing
Break-even and workload math script: reproducible from the formula above.

Prices change. We re-verify every figure in this post monthly and stamp updates. Numbers here are current as of 2026-07-17.

Want caching applied only where it clears the break-even, across every provider? Vynaris is an OpenAI-compatible gateway that keeps the stable prefix warm and prices each request. One base URL swap. Get an API key at vynaris.com.