The big proprietary APIs cache your prompt prefix too. I ran the same probe against four of them — OpenAI's gpt-5.4-nano, Gemini, Anthropic's haiku-4.5, and xAI's grok-4.3, all through OpenRouter — and where open-weight backends held a prefix for hours, these let go in minutes: about 10 for OpenAI, 5 for Gemini, 5 for Anthropic, and 30 for xAI, the longest of the four.

A caveat before the numbers do any work: this is a reference panel, not a controlled comparison. Across these four routes the model and the serving stack change together, so I cannot separate a short window that is the model's doing from one that is the infrastructure's. That is exactly the confound the open-weight study removes by holding the weights constant and varying only the provider. Read this post as the proprietary yardstick that sits alongside that one.

The probe is the same single cycle — prime → verify → idle → probe: send a unique ~4,000-token prefix, confirm ten seconds later that it cached, wait a fixed idle interval with no requests in between, then send it once more and read cached_tokens from the usage field.1

If the gap between your agent's turns is longer than a few minutes, a proprietary cache is already cold.

The write lands within seconds#

As with the open-weight routes, I first confirmed the prefix caches at all, and how fast. A propagation sweep sends a fresh prefix and re-probes it at short waits up to 60 seconds; each cell is the fraction of primes already visible as cached at that wait.

Cache-write visibility heatmap for the four proprietary routes
All four proprietary routes surface the cache write within about 2 seconds of the prime.

All four routes crossed 50% visibility within about 2 seconds. So a prime is readable as cached almost immediately, and back-to-back requests already benefit from the cache with no artificial pause between them. The interesting question is not whether the write lands — it is how long it stays.

Minutes, not hours#

Retention probability by idle interval for the proprietary routes
Verified retention probability per idle interval; even the longest holder, xAI at 30 minutes, is gone within the hour.

Each cell is the verified probability that the cache was still warm after sitting untouched that long. The four windows are short and clearly separated: OpenAI holds about 10 minutes, Gemini and Anthropic about 5, and xAI stretches to 30. Of the four, only Anthropic exposes an explicit TTL knob — its cache_control field, here on the 5-minute tier — and its OpenRouter path verifies cleanly and lands exactly where that tier promises. The other three are automatic, best-effort caches whose retention you can observe but not request. Gemini is the shakiest of the set: it does report cached tokens through OpenRouter, but on weaker write visibility, shallower depth, and fewer verified samples per interval than OpenAI or Anthropic.

The blunt consequence: even first-party caches are short-lived. If your requests arrive further apart than the provider's window, every call pays a full prefill, and cache pricing only ever helps the traffic that returns inside the TTL.

Does the window hold across the day?#

Retention moves with backend load, so a headline TTL is really an average over hours that may not behave alike. These two views cut the same first-crossing rule by prime-time hour.

Effective TTL by hour of day for each proprietary route
Effective TTL by prime-time hour (UTC) for each route; hourly bins are thin, so read broad patterns rather than single-hour wiggles.
Representative proprietary retention time by hour
A representative provider-level view of how the retention window shifts across the day.

The hourly bins are still thin in this live sweep, so this is a stability check on the headline number, not an hour-by-hour scheduler. A route that holds its tier around the clock can be trusted at its summary TTL; one that sags in particular hours should be judged by the worst hours that overlap your traffic.

How much of the prompt counts#

As on the open-weight side, TTL is how long the cache lasts and depth is how much of the prompt it credits on a hit — separate axes. Depth is the credited fraction, cached_tokens / prompt_tokens, on retained hits; a fraction well below 1.0 means the provider re-computes part of the prompt even when it reports a hit.

Credited cached fraction on retained hits, by provider
Cache depth on retained hits: OpenAI and Gemini credit only part of the prompt, while Anthropic and xAI are deeper when they hit.

OpenAI and Gemini credit only part of the prompt as cached even on a retained hit; Anthropic and xAI are deeper when they hit. So any cost projection built on "cached input is N× cheaper" needs scaling by the provider's actual credited fraction. On a route that credits 60% of the prompt, nearly half of your expected cache savings never materializes, even at a 100% hit ratio.

Does a hit feel faster?#

A warm probe skips prefill, so it should return its first token faster than the cold prime. As before, TTFT here includes the OpenRouter gateway hop, so compare cold against warm within a route rather than across.

First-token latency, cold prime versus warm probe, per proprietary route
Paired cold-prime versus warm-probe TTFT distributions; the latency win exists only where the warm box sits below the cold one.

The discount lands on the bill regardless. The latency win only lands where the warm box sits clearly below the cold one — and for an interactive workload both are worth checking, because a provider can credit your tokens without returning the first one any sooner.

The window is the product#

For these four APIs the cache is not something you tune; it is a fixed, best-effort window you either fit inside or you don't. The longest of them holds half an hour, the shortest five minutes, and only one lets you ask for a specific tier at all. If your traffic returns within that window — a burst of turns in one conversation, a retry, a fan-out over a shared system prompt — the cache pays. If your agent thinks for ten minutes between turns, it is priming a cold cache every time, and the discount on your invoice is describing a hit rate you are not getting.

The open-weight companion post runs this same probe across 35 backends serving three models, and finds the window swinging from seconds to more than a day on identical weights — the axis these four proprietary routes hold fixed.

These numbers come from the same probe I run through OpenRouter, snapshotted in early July 2026 — OpenRouter-routed rather than direct native-key measurements. Prefix caching is best-effort and load-dependent, so exact windows drift between runs and across times of day — read the tiers, not the decimals.

Footnotes

  1. The measured idle interval is verify → probe with no reads in between, so a miss means the prefix genuinely sat idle that long. Retention is verified-only: computed only over trials whose prime provably cached by the +10s verify probe, excluding trials that never landed warm rather than scoring them as evictions. Effective TTL is a first-crossing rule — the last idle interval before verified retention drops below 50%. These are OpenRouter-routed measurements, not direct native-key calls, and some routes here (Gemini especially) rest on only a handful of verified trials per interval, so read tiers, not decimals. ↩