A prompt-cache write pays for itself after a single re-read within the TTL: the write bills 1.25x the input rate, the read bills 0.1x, so one hit already swings the two-call total from a 25% premium to a 32.5% saving. And yet on one of the five scenarios in our agent suite, the same premium produced a measured 6% loss. The difference is a single number, the read:write ratio of your traffic, and this post is about measuring it before the invoice does. Everything below was measured through the Synthorai gateway on live billing meters; the agent numbers come from a 150-episode suite, the TTL and clustering results from dedicated salted probes.
TL;DR
- Explicit cache writes bill 1.25x (5-minute TTL) or 2x (1-hour); GPT-5.6's breakpoints converged on the same 1.25x/0.1x shape; break-even is one re-read.
- Across our agent suite the premium's net effect ranged from +6% (RAG, read:write 0.2) to -83% (batch, 15.7).
- Cache hits refresh Claude's TTL for free: steady traffic pays the write once per idle gap, not per window.
- Implicit caching spans a spectrum: GPT-5.5's sustained 7/8 hits after one primed call, Gemini's 1-3 hits per 12 even clustered; no premium either way.
What does a cache write actually cost?
Three pricing shapes exist across the providers we compare, and two of them charge for writing. Explicit caching on Claude bills cache creation at 1.25x the input rate for the default 5-minute TTL and 2x for the 1-hour tier, with reads at 0.1x; GPT-5.6 moved to explicit breakpoints with the same 1.25x write and 0.1x read multipliers, so the industry's two largest explicit implementations now price identically. The third shape is implicit caching (Gemini, Kimi, the pre-5.6 OpenAI models): no write premium at all, only discounted reads when the provider happens to hit.
The break-even arithmetic for explicit writes is short. A prefix of P tokens costs P at the normal rate uncached. Cache it and the first call costs 1.25P; every re-read within the TTL costs 0.1P instead of P. One re-read brings the two-call total to 1.35P against 2P uncached, a 32.5% saving, and each further hit saves 90% of its prefix cost. The premium is not the risk. The risk is writing blocks that never get read back, and that risk turns out to be workload-shaped.
When does the write premium lose money?
When your prefix changes faster than it repeats. We measured the read:write token ratio across five agent scenarios (identical models, identical marker discipline), then computed the net effect of caching at the 1.25x/0.1x rates:
| Scenario | Read:write ratio | Net effect vs no caching |
|---|---|---|
| Batch (stable instructions, many jobs) | 15.7 | -83% on prefix spend |
| Long chat (growing history) | 6.8 | -75% |
| Tool loop / tooling | 5.4 | -72% |
| RAG (retrieved docs in the prefix) | 0.2 | +6%: caching costs more |
| Suite overall | 3.5 | -64% |
The RAG row is the one to internalize. Retrieved documents differ per query, so every call re-wrote a prefix that the next call could not reuse: five written tokens for every one read back, and the 1.25x premium compounds into a net loss. Nothing was misconfigured; the workload's shape simply cannot amortize a write. The fix is layering, not abstinence: mark the system prompt and tool definitions (stable across queries) and leave the retrieved documents after the last breakpoint, unmarked. The same discipline applies to anything volatile, timestamps, user names, per-request context, and to settings that silently invalidate the prefix: changing output_config.effort between turns re-renders the prompt and busts the cache, which is why effort should stay constant within a cached session. Our LangChain study found the same failure mode framework-side: builders that make marking everything as easy as marking the right thing.
How often do you actually re-pay the write?
Once per idle gap, not once per TTL window, because hits refresh the clock for free. We proved this with a salted 4,981-token prefix on Claude Opus 4.8:
| Call | Timing | Cache write | Cache read |
|---|---|---|---|
| 1 | t=0 | 4,981 | 0 |
| 2 | +3 min | 0 | 4,981 |
| 3 | +6 min | 0 | 4,981 |
| 4 | +9 min | 0 | 4,981 |
| 5 | after 7 min of silence | 4,981 | 0 |
Call 4 lands well past the original 5-minute TTL and still reads clean, because calls 2 and 3 each renewed the window at no charge; only the 7-minute silence forced a re-write. The practical consequence: for any route whose inter-arrival time stays under the TTL, the write premium is a one-time cost, and the 5-minute tier behaves like an indefinite cache. The 1-hour tier (2x write, verified billing into its own ephemeral_1h_input_tokens bucket through the gateway) is for the other traffic: pay 2x once instead of 1.25x repeatedly, which wins as soon as it saves you a single re-write, so it fits routes with idle gaps that fall between five minutes and an hour. Past an hour of silence, neither tier carries you across runs. A scheduled job should budget by what happens inside one run: a cron that fires a single request gains nothing from writing, while a cron that fans out into many same-prefix requests is just a batch, and caches exactly like one.
Can you rescue implicit caching by shaping your traffic?
It depends entirely on whose implicit cache, because best-effort spans a spectrum. At the good end, GPT-5.5's automatic caching behaved like a mechanism: after one priming call the entry was readable two seconds later (first probe hit, on both salts we tried), and a subsequent burst read 4,864 of a 5,170-token prompt from cache on seven of eight probes with no premium paid for any of it. That is genuinely free money, and it demands nothing beyond sending the same prefix twice. At the other end sits Gemini 3.6 Flash: in the same agent suite where explicit caching served 77-78% of Claude's input tokens, Gemini's implicit cache served 4%, on workloads with genuinely repeating prefixes.
We tried to rescue the bad end with traffic shaping: cluster same-prefix calls so the provider's cache is still warm. Twelve back-to-back calls on Gemini 3.6 Flash produced exactly one hit (call 10; call 11 missed again), and eight calls spread at 3-minute intervals produced zero. Suspecting a fluke, we re-ran the clustered arm on a second, independent request path and on Gemini 3.5 Flash: three hits and one hit out of twelve, respectively, never consecutive for long, and the one block that did cache came back at the same 4,073 tokens on both paths. The mechanics are consistent; the probability is not.
Part of the miss rate is ingestion lag, and its size is provider-specific: GPT-5.5's entry was readable two seconds after the prime, while Gemini's takes tens of seconds to build, so bursts that follow the first call immediately outrun its cache (no Gemini arm in any of our runs hit before the fourth call). Priming the prefix once and waiting 45 seconds before the burst lifted hits to 3 of 8, the best any shaping achieved, but a 90-second wait returned zero of 8: by the time we came back, the entry was already gone. Days earlier, a longer warm-up sweep on the same model had sustained hits, so the rate also drifts with time and load. Between the build lag, the short lifetime, and the drift, clustering on the bad end helps only in the sense that three hits beat one. (A testing note: probe implicit caches with paced calls and a prime-and-wait arm, and measure the build lag itself with a post-prime ladder; back-to-back probing measures your request rate, not the cache.)
So the honest rule is per-provider, not per-mechanism: measure whether your provider's implicit cache behaves like GPT-5.5's (prime it, then trust it) or like Gemini's (treat any hit as a rebate). Kimi K3 sits between them, no premium, a small floor, and 57-62% of input served from cache without configuration. And there is one telling data point about which end wins: OpenAI had the best implicit cache we measured and still moved GPT-5.6 to explicit breakpoints, trading its own luck-free rebate for customer-controlled marks.
Which workloads amortize the premium?
Match the decision to the read:write ratio and the idle gap, both of which you can read from your own usage records before committing:
| Workload | Verdict | Why |
|---|---|---|
| Multi-turn agent sessions | Cache | History re-reads every turn; suite measured R:W 3.3-3.6 overall |
| Shared system prompt, steady QPS | Cache, 5m tier | Inter-arrival < TTL means one write, then free refreshes |
| Bursty sessions with 5-60 min gaps | Cache, 1h tier | 2x once beats 1.25x per gap |
| Batch jobs, same instructions | Cache, and cluster the jobs | R:W 15.7 measured, -83%; clustering keeps the window warm |
| RAG with volatile documents | Layer it | Mark instructions/tools only; docs after the last breakpoint |
| Scheduled crons, one request per run | Skip | Runs are hours apart; every write expires unread |
| Scheduled crons, many requests per run | Cache within the run | The run is a batch: first request writes, the rest read; hits keep the TTL alive for the run's duration |
| Sub-floor prompts | Skip | Below the per-model cache minimums nothing caches anyway |
Two closing rules from the meters. First, judge caching by cache_read versus cache_creation in your own usage itemization, not by whether hits feel frequent; the RAG scenario felt cache-friendly and measured 0.2. Second, when the ratio is healthy, the premium disappears into rounding: at read:write 3.5, the suite's overall figure, prefix spend drops 64% including every write ever paid.
FAQ
Is prompt caching worth it for RAG?
Not for the retrieved documents. In our measurement RAG wrote five tokens for every one it read back, turning the 1.25x premium into a 6% net loss. Cache the stable layers, system prompt and tool definitions, and keep retrieved content after the last breakpoint; the complete caching guide covers prompt layering in detail.
Should I use the 5-minute or the 1-hour cache TTL?
By idle gap, not by session length. Hits refresh the 5-minute TTL for free, so any route with sub-5-minute inter-arrival never re-writes and the cheap tier behaves indefinitely. Pay the 1-hour tier's 2x write only when your gaps fall between five minutes and an hour; it wins as soon as it avoids one 1.25x re-write. Gaps beyond an hour: budget with no cache at all.
Does implicit caching charge a write fee?
No, and structurally it cannot: a write premium only makes sense where the caller opts in, so premiums exist exclusively on the explicit side (Anthropic's 1.25x/2x multipliers, GPT-5.6's breakpoints, and the storage-rent shape of explicit cached-content APIs like Gemini's per-token-hour fee). Every implicit implementation we measured (Gemini, Kimi, pre-5.6 OpenAI) and every major published rate card (DeepSeek, Qwen, Grok) bills implicit caching as discounted reads only. What varies is reliability: GPT-5.5's implicit cache sustained 7 hits in 8 primed probes, while Gemini's served 4% of input in our agent suite and clustering barely moved it. Zero premium on a discount you reliably receive beats everything; zero premium on one that arrives at random is worth less than a small premium on one you control.
Measured 2026-07-25 to 2026-07-29 through the Synthorai gateway: scenario read:write ratios from 150 Claude-arm agent episodes with per-call cache itemization (Gemini and Kimi shares from their own suite runs); TTL-refresh and 1-hour-bucket probes on claude-opus-4-8 (salted 4,981- and 3,742-token prefixes); implicit-cache probes on gemini-3.6-flash and gemini-3.5-flash (salted ~6,800-token prefixes; clustered, spread, and prime-and-wait arms) and on gpt-5.5 (salted 5,170-token prompt, primed burst). Net-effect percentages computed from measured ratios at 1.25x write / 0.1x read multipliers. Rates and cache behavior may change; verify against your own usage records.
Top comments (0)