TEARDOWN Nº 7 / FIELD NOTES

Prompt cache TTL: 5 minutes, 30 minutes, 1 hour or 12 hours?

PUBLISHED 2026-10-27 · BY Llorenç Ballester — Chief Burn Officer

A cache write is a bet that the same prefix will come back before the cache expires. Providers now sell that bet in four sizes, and the longer ones cost more to write. So the question is how long your traffic actually goes quiet. We measured it on five months of Claude Code calls (91,133 of them) and re-priced the input side under each window.

Four windows, two price ladders

Writes are priced as a multiple of the model's normal input price. Reads cost the same whichever window wrote them. What differs, besides the price, is what a read does to the clock.

From each provider's prompt caching documentation, read on 2026-10-27. OpenAI's windows apply from GPT-5.6 onward; the 12-hour one is set with prompt_cache_options.ttl in the Responses API and can be mixed with 30-minute breakpoints in the same request. Both call these minimum lifetimes: an entry may live longer, but only the minimum is promised.

The interesting asymmetry is at the bottom of each ladder. For the same 1.25x, OpenAI's default write lives 30 minutes and Anthropic's lives five.

How long an agent goes quiet

We took every call in five months of the author's Claude Code logs, grouped them by conversation (a subagent counts as its own, since it sends a different prefix) and measured the time between each call and the one before it.

Share of gaps between consecutive calls in the same conversation. Median gap 13 seconds, 90th percentile 1.7 minutes, 95th 4.6 minutes.

Most of the traffic is the agent talking to itself: call a tool, read the result, call the model again, a few seconds apart. Those calls keep any cache warm. The gaps that matter are the human ones, when you read a diff, go to a meeting or stop for lunch. They are rare, but each one lands on a conversation that may be carrying hundreds of thousands of tokens.

The same five months under each window

We replayed every conversation under each window. While the cache is alive, the part already cached is read and what the turn adds is written. After a gap longer than the window, the whole prefix is written again. Only the multipliers change between rows, so this compares the windows and leaves the models out of it. Sending everything uncached is 100.

Reads at 0.1x input. "Full rewrites" includes the first call of every conversation, which no window can avoid. At the 0.05x read rate of GPT-6.1 Sol and Terra (and Opus 5.5 and Sonnet 5.5 on Claude) the picture holds: 11.9, 9.6, 8.3 and 8.3, in the same order as the table.

Three readings. First, the 1-hour window was the right default for Claude Code, which used it for 94% of its cache writes in these logs. It came out 13% cheaper than five minutes. Rewriting long conversations after short breaks cost more (6.5 against 3.6) than everything the hour charged extra on new tokens (1.1 against 0.7). Second, OpenAI's default terms fit this traffic better than either Anthropic option: the 1.25x write covers 98% of the gaps, so it gets most of the 1-hour benefit at the 5-minute price. Third, the 12-hour window lands at 13.2, level with the default. It trims rewrites from 2.8 to 1.9, but every new token an agent turn adds is now written at 2.5x, and that eats the saving.

Keep the scale in mind. These are differences of a few points on the input side. Picking a model at half the input price moves the bill far more than picking a window. The window is worth getting right because it is a one-line setting.

A second dataset, same shape

One developer's logs could be a habit. So we ran the same replay on the dataset from teardown #5: a different team, a different tool (opencode), 18,787 calls in 196 conversations between 2026-04-07 and 2026-08-29.

Same rules, same replay, read with npx tokenburnindex audit --source opencode. Input index with reads at 0.1x, no cache = 100.

The shape holds. This team's agent went quiet even less: only 0.8% of its gaps passed 30 minutes. The 1-hour window beats the 5-minute one again (13.7 against 15.2), and OpenAI's default is the cheapest of the four. Here the 12-hour window costs more than the default (13.3 against 12.5): with so few long gaps there are hardly any rewrites left to save, and every new token still pays 2.5x. Two datasets are still two anecdotes, but they point the same way.

When the long window pays

Take a prefix that keeps coming back, every time after the short window has expired. With the short window you write it again on each return. With the long one you write it once and read it afterwards.

• Claude, 1 hour against 5 minutes: the hour wins from the first return. One 2x write plus a 0.1x read is 2.1x, against 2.5x for two 1.25x writes. Anthropic's own advice matches: use the hour for prompts that come back less often than every five minutes.
• OpenAI, 12 hours against 30 minutes: it takes two returns. After one it is 2.6x against 2.5x, so a prefix that comes back exactly once is cheaper on the default. After two it is 2.7x against 3.75x.
• A window that always expires is worse than no cache. If your requests arrive further apart than the window, every one pays a 1.25x write and never a read. That is 25% more than sending the prompt uncached, and it is the default behaviour.

The case it was built for: an hourly job

A scheduled job sends the same 50K-token prefix (instructions plus reference material) once an hour, 12 times a day, to GPT-6.1 Sol. Prefix cost per day at today's board prices:

Left on the default, the cache makes this job 25% more expensive than not caching. With the 12-hour window it costs 25% of the uncached price. On Claude the same job sits right on the edge of the 1-hour window: a run that starts a little late finds the cache gone and pays a 2x rewrite.

Every long-window rate on the board

Per million tokens, from the board, recomputed on every deploy. Google and the open-weight providers on the board publish no separate write rate, so they have no window to choose. Background on how caching is billed: prompt caching, explained.

Method and limits

Each dataset is n=1. The main one is one developer's Claude Code logs from 2026-05-18 to 2026-10-19, the same period as teardown #6, 1,090 conversations, calls deduplicated the way our CLI does it. The second is one team's opencode database. Both are people working with a coding agent at a desk. A team that runs agents unattended, or a product with steady user traffic, will have a different shape. Only proportions are published.

The replay assumes an ideal cache: no minimum length, no prefix broken by a compaction, no request routed to a machine that doesn't hold the entry. Real bills have all three. It also applies Claude Code's traffic to OpenAI's rules, which is a what-if: Codex might call the model at a different rhythm. And it only follows the prefix within one conversation. The 12-hour window is also pitched at material shared across conversations during the day, which we did not measure. The replay applies nothing beyond the rules in the first table and the gaps above, and npx tokenburnindex audit (from version 0.5.0) runs the same replay on your own Claude Code, Codex or opencode logs. It reads the time of each call to measure the gaps and prints only the counts, never a time or a date.

Corrected 2026-10-27, the day of publication. The first version counted about 275 log entries that Claude Code writes without calling the API (zero tokens) as calls. Each one added a cache read and made the next call rewrite the whole context, which hurt the 12-hour window most: it showed 13.5 instead of 13.2, and the other windows moved by 0.1. We caught it when the replay built into our CLI did not match this page. The conclusions stand, except that the 12-hour window now ties with the default instead of trailing it.

Frequently asked questions