---

Abstract #

Providers price a cached input token at 2% to 50% of a fresh one, and several charge 1.25 to 2.5 times the base price to write the cache. We ask when that trade pays off once real request timing and engineering effort are counted. We collected prices, time-to-live (TTL) options and minimum cacheable lengths for 18 model and cache-mode pairs from Anthropic, OpenAI, Google and DeepSeek on 21 October 2026, derived break-even conditions, modelled Poisson arrivals, and replayed four public traces: 140,338 Claude Code and 216,823 Codex requests from TraceLab and one hour of Kimi conversation and tool-agent traffic from Mooncake. First, the cache breaks even after one read within the TTL at a 1.25-times write and two reads at 2 or 2.5 times; under Poisson arrivals, Claude Sonnet 5.5’s 5-minute cache is net-positive only if requests for a prefix arrive at least every 21.4 minutes on average. Second, the workload, not the price sheet, sets the saving: coding-agent sessions keep 86.3% to 92.5% of input cost off the bill against a 95% ceiling, while on Kimi conversation traffic the same 5-minute policy saves 10.2% and 1-hour and 12-hour writes lose 27.1% and 58.4%. Third, under our stated effort assumptions, prefix-stable caching on a $2-per-million-token model repays five engineer-days plus one day a month within three months above about 1.28 billion input tokens a month.

1. Introduction #

Our previous article in this series, Model Routing at Scale[1]^[2], found that the expensive model’s share of traffic sets the saving from routing, not the price gap between tiers. Prompt caching invites the same check: it changes not which model runs but what the provider charges when a request repeats recent context. Our KV-cache compression article[2]^[3] treated the provider’s cache-hit discount as a complement to self-hosted compression; here we take the buyer’s side and ask what the discount is worth once three frictions are counted: the premium for writing the cache, the TTL after which a cached prefix expires, and the engineering time needed to keep prefixes stable.

Anthropic’s pricing page states that caching pays off after one cache read for the 5-minute duration and after two reads for the 1-hour duration[3]^[4]. That holds only if the read arrives before the entry expires, and no price page says how often that happens or what it costs to keep the cached prefix byte-identical across requests. A change to tool definitions, for example, invalidates the entire Anthropic cache[4]^[5].

RQ1: At list prices on 21 October 2026, how many reuses within the TTL does each provider’s prompt cache need to beat no caching, and how frequent must requests be for that to happen under random arrivals? RQ2: How much of the list-price discount survives the arrival timing and reuse structure of real agent and chat traces, and which TTL is cheapest? RQ3: Including engineering effort, what monthly input-token volume makes caching work pay back within three months, and how sensitive is that threshold to our assumptions?

This matters for the series because caching is now the default cost lever for agent workloads, yet its value is quoted as a list-price discount, not a realised one.

2. Existing Approaches (2025–2026 state of the art) #

2.1 Explicit caches with write premiums #

Anthropic and OpenAI’s newest models use explicit caches that bill the write. On Anthropic, a 5-minute cache write costs 1.25 times the base input price and a 1-hour write 2 times; reads cost 0.1 times, 0.05 times on Claude Opus 5.5 and Sonnet 5.5, and 0.025 times on Claude Fable 5.1 and Mythos 5.1[4]^[5]. The 5-minute cache is refreshed free on each use, a request may define up to four breakpoints, and the minimum cacheable prompt ranges from 512 to 4,096 tokens depending on the model[4]^[5]. OpenAI’s GPT-5.6 and later models charge 1.25 times for a 30-minute write and 2.5 times for a 12-hour write, read at 0.1 times (0.05 times on GPT-6.1 Sol), and set a 1,024-token minimum[5]^[6]. On gpt-6.1-sol that is $2.00 per million fresh input tokens, $0.10 cached and $2.50 or $5.00 to write[6]^[7].

2.2 Implicit and disk-backed caches without write premiums #

OpenAI models before GPT-5.6 cache automatically with no additional write charge; in-memory retention lasts roughly 5 to 10 minutes of inactivity and up to one hour[5]^[6]. Gemini enables implicit caching by default on 2.5 and newer models, with a 4,096-token minimum on the Gemini 3 generation, and explicit caching is not supported for Gemini 4 Argon and later[7]^[8]. Where Gemini still offers explicit caches, it bills storage by the hour: $4.50 per million tokens per hour for Gemini 3.1 Pro, against $2.00 for fresh input and $0.20 for cached input[8]^[9]. Amazon Bedrock offers both modes; its implicit caching is best effort and its TTL resets with each hit[9]^[10]. DeepSeek’s disk cache is on by default and is cleared once unused, usually within a few hours to a few days[10]^[11], and its Flash model charges $0.006 per million cache-hit tokens against $0.30 for a miss at peak rates[11]^[12]. The operator cannot force a hit, and OpenAI warns that more than about 15 requests per minute to one cache key can overflow to other machines[5]^[6].

2.3 Self-hosted prefix caching #

Inside open-source engines, vLLM hashes every KV-cache block together with the tokens before it and evicts the least recently used block when memory runs out[12]^[13]. SGLang’s RadixAttention keeps prefixes in a radix tree and reported up to 6.4 times higher throughput on workloads that included agent control and multi-turn chat[13]^[14]. Mooncake, Kimi’s serving platform, trades storage for computation with a disaggregated KV cache and processes over 100 billion tokens daily[14]^[15]. A characterisation of Alibaba’s cloud traffic found that KV-cache reuse is skewed across requests, that reuse between single-turn requests matters as much as multi-turn reuse, and that reuse timing is predictable within a request category[15]^[16].

2.4 Measurements on agent workloads #

An evaluation across OpenAI, Anthropic and Google on more than 500 research-agent sessions with 10,000-token system prompts found cost reductions of 41% to 80% and time-to-first-token gains of 13% to 31%. Naive full-context caching could even increase latency, while placing dynamic content last and excluding dynamic tool results was more consistent[16]^[17]. In four Microsoft 365 traces spanning more than 121 million model calls, about 80% of context tokens came from the prefix cache, and a one-hour idle cap raised the share of calls that recompute context only from 4.07% to 4.53%[17]^[18]. TraceLab’s roughly 4,300 coding-agent sessions show high but imperfect prefix cache hit rates[18]^[19], and a study of 14 eviction algorithms on production agent traces found little benefit over LRU because reuse is dominated by the regular pacing of active sessions[19]^[20]. A 28-day single-developer case study of a cached frontier-model configuration reported a 99.3% hit rate that cut realised API cost by 88.6%, to an effective $0.57 per million tokens[20]^[21].

2.5 Shared caches as a side channel #

A hit is faster than a miss, and the difference leaks. Statistical audits detected global cache sharing across users in seven API providers, including OpenAI, at the time of testing[21]^[22]. PromptPeek showed that KV-cache sharing for identical token sequences in multi-tenant engines such as SGLang and vLLM allows reconstruction of other users’ prompts[22]^[23]. Anthropic now isolates caches by organisation and, on its own API, by workspace[4]^[5], and OpenAI by organisation[5]^[6]; relays can undo that. None of five open-source gateways connected to OpenAI and Anthropic bound customers to upstream credentials by default, and in a weekly OpenRouter frame cross-account reads appeared for 12 of 28 labels carrying 33.7% of token volume[23]^[24]. A separate audit tests whether OpenRouter’s shared credentials create global sharing[24]^[25], and shared prefix caching in consumer local-serving stacks exposed a timing oracle distinguishable over wide-area networks[25]^[26]. On a self-hosted vLLM, a per-tenant cache_salt restricts reuse to requests with the same salt[12]^[13].

flowchart TD
    A[Prompt caching options] --> B[Explicit, write premium]
    A --> C[Implicit, no write premium]
    A --> D[Self-hosted prefix cache]
    B --> B1[Anthropic 5 min or 1 h]
    B --> B2[OpenAI GPT-5.6 and later, 30 min or 12 h]
    B --> B3[Gemini explicit, storage per hour]
    C --> C1[OpenAI pre-5.6, Gemini implicit]
    C --> C2[DeepSeek disk cache]
    D --> D1[vLLM, SGLang, Mooncake]
    A --> E[Costs not on the price sheet]
    E --> E1[TTL expiry]
    E --> E2[Prefix stability engineering]
    E --> E3[Tenant isolation]

3. Method and Data #

Prices. We recorded base input, write, read and output prices, TTLs and minimum cacheable lengths for 18 model and mode pairs from the Anthropic, OpenAI, Google and DeepSeek pages[3]^[4][6]^[7][8]^[9][11]^[12], all read on 21 October 2026. Costs are multiples of the base input price: a write costs w, a read r, a fresh token 1. Where a provider does not fix the implicit TTL, we modelled 5 minutes for OpenAI’s older models and for Gemini, and 3 hours for DeepSeek, the lower end of “a few hours”[10]^[11]. These TTLs are our assumptions. We also assume that every request refreshes the TTL, as Anthropic and Bedrock document for their caches[4]^[5][9]^[10].

Break-even and Poisson model. One write followed by k reads beats k + 1 uncached requests when w + kr ≤ 1 + k. For a prefix requested at Poisson rate λ, a refreshed TTL T gives a hit probability h = 1 – e^(-λT) and an expected cost per request of hr + (1 – h)w. Caching is net-positive when h > (w – 1)/(w – r).

Traces. TraceLab v0.0.1 records 357,161 LLM requests from 43 developers’ Claude Code and Codex sessions, with timestamps, prompt length and provider-reported cached tokens, under a CC BY 4.0 licence[26]^[27][18]^[19]. In the replay, a request can reuse the previous request’s prompt if its own prompt is at least as long and the gap since that request is within the TTL. A hit pays r on the reused prefix and w on the appended tokens, and a miss pays w on the whole prompt, which is what automatic caching does. As a check, the replayed hit share of Claude Code tokens is 92.76% with a 5-minute TTL and 98.02% with a 1-hour TTL, bracketing the 95.82% that the provider actually reported for those requests. The Mooncake release contains one hour of Kimi conversation traffic (12,031 requests) and tool and agent traffic (23,608 requests), with 512-token prefix-block hashes[27]^[28]. We replayed it as a service-wide block cache that starts cold. A hindsight dynamic programme choosing the 5-minute or 1-hour TTL for every write bounds the gain from TTL selection.

Engineering overhead (our assumptions). We price an engineer-day from the US median software-developer wage of $135,980 in May 2025[28]^[29], times 1.4 for benefits and overhead, divided by 230 working days: $827.70. Three effort tiers: switch-on, half a day to add a top-level cache directive; prefix-stable, five days once plus one a month to move dynamic content behind the breakpoint, freeze tool definitions and monitor hit rates; and the full programme, 20 days once plus two a month, adding multiple breakpoints, TTL tuning, cache-key routing and tenant isolation. The payback threshold is the monthly input-token volume at which the realised saving covers the one-off cost over three months plus the monthly cost. The effort figures are assumptions, so we report the threshold’s sensitivity to them.

All code, data and outputs are in stabilarity/hub/research/prompt-caching-roi-when-repeated-context-discounts-actually-offset-engineering-overhead.

flowchart LR
    P[Price pages, 21 Oct 2026] --> M[Write, read, TTL, minimum per model]
    M --> B[Break-even reads and Poisson threshold]
    T1[TraceLab coding-agent sessions] --> R[Trace replay per policy]
    T2[Mooncake Kimi traces] --> R
    M --> R
    R --> S[Realised input saving]
    W[BLS wage and effort tiers, assumed] --> E[Payback threshold]
    S --> E
    B --> Q1[RQ1]
    R --> Q2[RQ2]
    E --> Q3[RQ3]

4. Results #

4.1 RQ1: The cache breaks even after one or two reads, but only if the reads arrive in time #

Table 1 shows that one read within the TTL repays a 1.25-times write and two reads a 2- or 2.5-times write. Without a write premium a miss costs the same as no caching, so any hit is a gain. The list-price ceiling on the saving is 1 – r, from 50% on gpt-4o to 98% on DeepSeek Flash.

Model and cache mode	Write (x base)	Read (x base)	TTL	Minimum tokens	Break-even reads	Poisson break-even mean gap (min)
Claude Sonnet 5.5, 5-minute	1.25	0.05	5 min, refreshed	512	1	21.4
Claude Sonnet 5.5, 1-hour	2.00	0.05	60 min	512	2	83.4
Claude Sonnet 4.6, 5-minute	1.25	0.10	5 min, refreshed	1,024	1	20.4
gpt-6.1-sol, 30-minute	1.25	0.05	30 min	1,024	1	128.4
gpt-6.1-sol, 12-hour	2.50	0.05	720 min	1,024	2	760.0
gpt-5.5, implicit	1.00	0.10	about 5-10 min	1,024	0	none
gpt-4o, implicit	1.00	0.50	about 5-10 min	1,024	0	none
Gemini 3.1 Pro, implicit	1.00	0.10	not stated	4,096	0	none
DeepSeek Flash, disk	1.00	0.02	hours to days	not stated	0	none

Table 1. Prices and TTLs from Anthropic[3]^[4][4]^[5], OpenAI[5]^[6][6]^[7], Google[7]^[8][8]^[9] and DeepSeek[10]^[11][11]^[12], accessed 2026-10-21. Break-even columns: our calculation.

Under Poisson arrivals, Sonnet 5.5’s 5-minute cache is net-positive only if requests that share the prefix arrive on average at least every 21.4 minutes. That is about four times the TTL, because refreshed entries still catch some requests when the mean gap exceeds 5 minutes. The 1-hour write needs a request at least every 83.4 minutes, and gpt-6.1-sol’s 12-hour write every 760 minutes. On Sonnet 5.5 (Chart 1) the 5-minute cache saves 94.19% of the prefix cost when requests arrive every minute, 50.85% at one every 5 minutes and 9.02% at one every 15 minutes. At a 60-minute mean gap it loses 15.41%. The 1-hour cache still saves 91.43% at 15 minutes and 23.26% at 60 minutes.

The Poisson model also says that a longer TTL is never the wrong choice while caching pays at all. The 5-minute cache beats the 1-hour cache only beyond a mean gap of 113.28 minutes, and the 30-minute OpenAI cache beats the 12-hour one only beyond 966.70 minutes; in both cases neither cache pays at that point. The penalty for a wrong guess is asymmetric: a write that is never read loses 25% of the prefix cost at 1.25 times and 150% at gpt-6.1-sol’s 2.5 times. For storage-billed caches, a Gemini 3.1 Pro explicit cache needs 2.5 hits per hour to cover its storage fee, Gemini 2.5 Flash 3.70 and Gemini 3.8 Flash 0.74, on our calculation from the published prices[8]^[9].

4.2 RQ2: Agent loops keep most of the discount; conversation traffic does not #

Real arrivals are not Poisson (Chart 2): the median gap between consecutive requests in a TraceLab session is 0.14 minutes (about 8 seconds) for Claude Code and 0.15 minutes for Codex, because most requests follow a tool result rather than a person. Only 4.59% of Claude Code gaps and 3.25% of Codex gaps exceed 5 minutes, and 70.87% of the Claude Code gaps over 5 minutes begin with a user message, a person returning to the session. Weighted by prompt size, 6.11% of Claude Code input follows a gap longer than 5 minutes and 0.76% a gap longer than an hour. The mean Claude Code request carries 202,840 input tokens, and fewer than 0.02% fall below a 1,024-token minimum.

Chart 3 and Table 2 turn these gaps into money. On Claude Code sessions the replay keeps 86.31% of input cost off the bill with Sonnet 5.5’s 5-minute cache, 91.14% with the 1-hour cache and 92.54% with hindsight TTL selection, against a list-price ceiling of 95%. On Codex sessions, whose gaps are shorter, the order reverses: the 1-hour cache saves 85.65%, less than the 86.48% of the 5-minute cache, because the extra premium on every appended token outweighs the few rescued pauses. Including output tokens at Sonnet 5.5’s output price, the 5-minute cache cuts the total Claude Code bill by 84.86%. These figures lie above the 41% to 80% range measured on research agents[16]^[17] and bracket the 88.6% reported in one heavy coding case study[20]^[21].

Policy (list-price ceiling)	Claude Code	Codex	Kimi conversation	Kimi tool-agent
Sonnet 5.5, 5-minute (95%)	86.31%	86.48%	10.21%	38.44%
Sonnet 5.5, 1-hour (95%)	91.14%	85.65%	-27.14%	11.27%
Sonnet 5.5, hindsight 5 min or 1 h (95%)	92.54%	89.07%	not computed	not computed
gpt-6.1-sol, 30-minute (95%)	91.41%	89.01%	19.11%	43.19%
gpt-6.1-sol, 12-hour (95%)	91.45%	83.70%	-58.37%	-10.14%
gpt-5.5, implicit (90%)	83.48%	83.61%	25.97%	47.29%
DeepSeek Flash, disk (98%)	96.35%	93.42%	36.62%	55.92%
gpt-4o, implicit (50%)	46.38%	46.45%	14.43%	26.27%

Table 2. Input-cost saving against no caching. Sources: TraceLab[26]^[27] and Mooncake[27]^[28] traces; prices accessed 2026-10-21[3]^[4][6]^[7][8]^[9][11]^[12]; our replay. Every request is repriced at the policy’s multipliers.

The Kimi traces show the other side. Even across a whole service, only 29.34% of conversation input tokens and 52.86% of tool-agent input tokens are found in a 5-minute cache, and extending the TTL to an hour raises those shares only to 37.36% and 57.06%. The rest is mostly seen once, so an automatic cache that writes everything pays the premium on content nobody reads again. The 5-minute Sonnet 5.5 cache saves 10.21% on conversation traffic, and the 1-hour and 12-hour caches turn into losses of 27.14% and 58.37%. Caches without a write premium do better here than their lower list-price ceilings would suggest: gpt-5.5’s implicit cache saves 25.97% and DeepSeek’s disk cache 36.62%. This matches the skewed reuse reported for Alibaba’s cloud traffic[15]^[16] and explains why explicit breakpoints placed after stable content outperform caching the full context[16]^[17].

4.3 RQ3: Engineering time decides only at low volume or on cheap models #

At a day rate of $827.70, the switch-on tier must save $137.95 a month to pay back in three months, the prefix-stable tier $2,207.21 and the full programme $7,173.44. Dividing by the input price and the realised replay saving gives the volume thresholds in Chart 4 and Table 3.

Model (base input, USD per MTok)	Replay input saving	Prefix-stable threshold (billion input tokens per month)	Requests per day at 10,000-token prompts	Requests per month at the mean Claude Code prompt
gpt-6-astra (10.00)	86.56%	0.26	850	1,257
Claude Opus 5.5 (4.00)	86.31%	0.64	2,131	3,152
gpt-6.1-sol (2.00)	91.41%	1.21	4,024	5,952
Claude Sonnet 5.5 (2.00)	86.31%	1.28	4,262	6,304
Gemini 3.1 Pro (2.00)	83.48%	1.32	4,407	6,517
DeepSeek Flash (0.30)	96.35%	7.64	25,454	37,647
gpt-5.6-luna (0.20)	86.56%	12.75	42,497	62,853
Claude Haiku 5.5 (0.10)	81.67%	27.03	90,088	133,240

Table 3. Prefix-stable tier: 5 engineer-days once plus 1 a month, paid back in 3 months (our assumption). Saving from the Claude Code replay with each model’s own multipliers and TTL. Prices accessed 2026-10-21[3]^[4][6]^[7][8]^[9][11]^[12]; day rate from BLS[28]^[29]; our calculation.

For a $2-per-million-token model such as Sonnet 5.5, the prefix-stable tier pays back above 1.28 billion input tokens a month. That is about 4,262 requests a day with 10,000-token prompts, or about 6,304 requests a month at the mean Claude Code prompt size. Switch-on caching pays back above 0.08 billion tokens a month, so on a mid-priced model simply enabling the cache is justified for almost any production workload. The full programme needs 4.16 billion. On Claude Haiku 5.5 at $0.10 per million tokens, the same five days of prefix work need 27.03 billion tokens a month to pay back, and on DeepSeek Flash 7.64 billion.

For Sonnet 5.5, halving the day rate brings it down to 0.64 billion and raising it by half takes it to 1.92 billion. Requiring payback within one month raises it to 2.88 billion, and allowing 12 months lowers it to 0.68 billion. If prefix instability halves the realised saving to 43.15%, the threshold doubles to 2.56 billion. None of these moves the threshold by more than a factor of about three. The workload matters more: on Kimi-like conversation traffic a 5-minute Sonnet 5.5 cache saves 10.21% instead of 86.31%, which multiplies every threshold by more than eight.

5. Discussion #

Implications for practitioners. Measure reuse before engineering anything: the share of input tokens found in a cache within the TTL ranges from 29.34% on service-wide Kimi conversation traffic to more than 92% in coding-agent sessions. As a rule of thumb from these four traces, above about 80% any provider’s cache recovers most of its discount, and below about 40% the write premium dominates, and caches without one, or breakpoints placed only after content known to repeat, are the better choice. Second, choose the TTL from the gap distribution, not the Poisson intuition. In Claude Code sessions the 1-hour TTL adds 4.83 points over 5 minutes because human pauses carry 6.11% of input. In Codex sessions it loses 0.83 points. Hindsight selection adds at most 1.39 points over the 1-hour TTL on Claude Code. Writing with the long TTL only when the agent hands control back to a person is a plausible heuristic that we did not test; Bedrock’s guidance for Anthropic models recommends the 1-hour cache for that case[9]^[10]. Third, budget engineering against volume: on frontier and mid-priced models five days of prefix work pay back within a quarter above 0.26 to 1.32 billion input tokens a month, while models priced at $0.30 per million tokens or less need 7.64 to 27.03 billion tokens a month.

flowchart TD
    A[Measure share of input reused within TTL] --> B{Reuse share above 80 percent?}
    B -->|Yes| C[Enable caching, choose TTL from gap distribution]
    B -->|No| D{Reuse share above 40 percent?}
    D -->|Yes| E[Explicit breakpoints only after stable content]
    D -->|No| F[Prefer caches without write premium]
    C --> G{Volume above payback threshold for model price?}
    E --> G
    G -->|Yes| H[Invest in prefix stability and monitoring]
    G -->|No| I[Switch-on only]
    H --> J[Check tenant isolation on relays and self-hosted engines]

Isolation is part of the cost. A gateway that pools upstream credentials can expose one customer’s cache state to another[23]^[24], and audits have found global sharing at several providers in the past[21]^[22]. Isolation reduces reuse. Microsoft’s traces show cached-context reuse falling from 89% to 29% when the next call reaches a different deployment[17]^[18], but splitting the namespace after public prefixes cost only 1.7% to 2.5% in the relay study[23]^[24].

Limitations and threats to validity. Prices are one day’s list prices, some of them promotional. Implicit-cache TTLs for OpenAI’s older models, Gemini and DeepSeek are not fixed by the providers, and the replay assumes every eligible request hits, which overstates best-effort caches, especially above OpenAI’s 15-requests-per-minute guidance per cache key[5]^[6]. TraceLab’s 43 contributing developers are not an enterprise fleet; our append-only rule ignores reuse across sessions, so those savings are conservative. Mooncake hashes are service-wide and cover one hour, so they overstate a single customer’s reuse and cannot separate TTLs beyond an hour. We price every request at one policy’s multipliers regardless of the model that produced it, and ignore latency and rate-limit benefits; Bedrock, for example, does not count cached tokens against input-token rate limits for OpenAI models[9]^[10].

What would change the conclusion. A provider that dropped write premiums, as DeepSeek and OpenAI’s older models already do, would remove the downside in Table 2 and leave only the engineering threshold. Retrieval-augmented workloads, whose reuse likely sits between the coding and conversation traces, need their own replay. An eviction policy tuned to pacing[19]^[20] or tail latency[29]^[30] on the provider side would raise hit rates for implicit caches without any buyer effort.

6. Conclusion #

RQ1 Finding: The cache breaks even after one read at a 1.25-times write and two reads at a 2- or 2.5-times write, provided those reads arrive within the TTL. Measured by the Poisson break-even mean gap = 21.4 minutes for Sonnet 5.5’s 5-minute cache, 83.4 minutes for its 1-hour cache and 760.0 minutes for gpt-6.1-sol’s 12-hour cache, with no threshold for caches without a write premium. This matters for the series because “pays off after one read” holds only for prefixes requested several times an hour.

RQ2 Finding: Coding-agent sessions keep most of the discount, but conversation traffic does not. Measured by realised input saving = 86.31% (5-minute) to 92.54% (hindsight TTL) on Claude Code against a 95% ceiling, versus 10.21% (5-minute), -27.14% (1-hour) and -58.37% (12-hour) on Kimi conversation traffic, where only 29.34% of input is reused within 5 minutes. This matters for the series because the same feature is a near-maximal saving in agent loops and a net loss on low-reuse traffic.

RQ3 Finding: Engineering effort is decisive only at low volume or on cheap models. Measured by the prefix-stable payback threshold = 1.28 billion input tokens a month on Sonnet 5.5, 0.26 billion on gpt-6-astra and 27.03 billion on Claude Haiku 5.5, with a range of 0.64 to 2.88 billion on Sonnet 5.5 across our sensitivity cases. This matters for the series because it turns the caching decision into a volume test a team can run on its own token bill.

The next question for the series is how cache-aware routing, which sends a request to the model and deployment that already holds its prefix, trades routing savings against the reuse lost when traffic is split.