Theo reports a 27% Gemini cache miss rate in an agent workload test
Theo reports a 27% Gemini cache miss rate that raised costs roughly 50% above expectations and links a reproduction. The visible exchange with Phil Schmid does not establish which endpoint was tested.

TL;DR
- Gemini fell below the full-hit threshold on about 27% of turns in theo's test; most of those turns still reused part of the prefix, according to his methodology.
- Modeled Gemini costs ran 20% to 48% above ideal caching for the same workload, while Claude and OpenAI stayed at baseline in theo's results.
- The reproduction preserves an append-only conversation, as theo explained, but Gemini ran from a different network than the comparison providers.
The reproduction counts a turn as a full hit once it reuses 90% of the previous prompt. Google's caching documentation says Gemini 4 Argon has no explicit-cache option.
Partial hits
Theo's October 17 test scored 228 turns per provider. Gemini recorded 167 full hits, 57 partial hits, and four zero-read misses, according to the published methodology.
The scoring compares cached tokens against the previous request's prompt-token count:
- Full hit: at least 90% reused.
- Partial hit: some reuse, below 90%.
- Miss: zero cached tokens read.
Gemini's results varied with the delay between turns:
| Delay | Full hits | Partial hits | Zero-read misses |
| --- | ---: | ---: | ---: |
| 5 seconds | 76.3% | 23.7% | 0% |
| 30 seconds | 69.7% | 28.9% | 1.3% |
| 120 seconds | 73.7% | 22.4% | 3.9% |
Partial reads clustered in turns 1 through 6 and reused about 85% of the preceding prompt on average, leaving roughly 2,350 previously processed tokens billed again per partial turn.
Ideal-cache billing
Partial hits get expensive fast at the study's rates: uncached input costs $2 per million tokens, versus $0.10 for cache reads.
The cost multiple divides each provider's measured token charges by its own ideal-cache bill. That ideal case reuses the entire previous prompt, still charges for newly appended text, and preserves the observed output charges.
Claude and OpenAI's calculations include cache-write fees for the new tail; Gemini's calculation charges that tail as ordinary input. The headline's roughly 50% penalty corresponds to the 1.48x result at the 120-second gap.
Append-only harness
Theo described the workload as a basic agent simulation in a reply. The reproduction tests claude-sonnet-5-5, gpt-6.1-sol, and gemini-4-argon with controlled conversation histories:
- Prefix isolation: a 301-line system prompt includes a unique thread nonce, preventing reuse across threads or earlier runs.
- Growing context: each turn appends a literal assistant
OK.and synthetic tool output containing 40 fresh UUID-bearing lines. Gemini's prompt grows from about 10,200 to 49,000 tokens. - Sampling: four threads at each of three delays, with all 12 threads per provider running concurrently.
- Warmup: each thread has 20 requests; the first primes the cache and is excluded from scoring.
- Output control: replies are capped at 16 tokens, and generated replies never enter subsequent prompts. No actual tools are called.
- Run totals: 720 requests, 684 scored turns, and zero reported errors, with no application-level retries.
Caching configuration differs by provider: Gemini and OpenAI use implicit caching; Claude receives an explicit top-level cache_control setting with a five-minute TTL. The runner requires Node 22 or later and writes per-request JSONL containing prompt, cache-read, cache-write, output, and latency fields.
Endpoint and network
The visible exchange leaves the endpoint unanswered. The published runner constructs GoogleGenAI with an API key and calls models.generateContent, without an explicit Vertex flag or custom base URL.
Google's Node SDK source also permits API selection through GOOGLE_GENAI_USE_VERTEXAI. The reproduction logs token counters and latency without recording the resolved request URL.
Gemini ran separately from another network after the original network received HTTP 403 responses. Network, region, backend routing, and the synthetic prompt text appear among the methodology's caveats; the comparison did not hold network location constant.
Cache lifetime
Google's generateContent documentation offers no cost-saving guarantee for implicit caching. A separate six-thread probe in theo's methodology tested persistence using unique prefixes of about 25,000 tokens:
- Without refresh: requests after 2 and 6.5 minutes missed; a request after 15 minutes hit; requests after 35 and 65 minutes missed.
- With refresh: requests at 4, 8, and 12 minutes all hit.
Each unrefreshed delay had one sample. Those observations do not establish a fixed implicit-cache lifetime.