What is the default TTL of Anthropic's prompt cache, and what does caching cost?

## Lifetime An entry written by a `cache_control` breakpoint is short-lived. The default is roughly five minutes, and it is a *sliding* window: every read of that entry restarts the timer. This is the single most useful fact about the TTL, because it means the relevant question is not "how long does the cache live" but "how often does this prefix get used". A prompt hit every thirty seconds stays warm for hours; the same prompt hit every ten minutes never hits at all and pays the write premium every single time. An extended lifetime of one hour is available by adding a `ttl` field to the control object — `{"type": "ephemeral", "ttl": "1h"}` — and it slides the same way. It exists for workloads with real gaps: a support agent who returns to a session after a coffee break, an analyst iterating over a large document, a batch job that revisits the same corpus every few minutes. ## The three input prices Caching splits the input token price into three: - **Ordinary input** — the base rate, for everything not involved in the cache. - **Cache write** — about 1.25x base for the five-minute tier, about 2x base for the one-hour tier. You pay this once, on the miss that populates the entry. - **Cache read** — about 0.1x base. You pay this on every hit. The response tells you which is which through `cache_creation_input_tokens` and `cache_read_input_tokens`, so the bill is reconstructable per request. ## Break-even arithmetic Take base input as 1.0 per token. Without caching, N calls over the same prefix cost N. With five-minute caching, they cost 1.25 for the write plus 0.1 for each of the N-1 reads. At N = 2 that is 1.35 against 2.0 — already cheaper. The formal break-even is well under a single reuse: the 0.25 premium is repaid by 0.28 of one reuse's 0.9 saving. The one-hour tier pays 1.0 extra on the write, so it needs about 1.12 reuses — call it two calls within the hour — before it beats no caching, and it only beats the five-minute tier when the five-minute tier would have expired and re-written. That is the decision: choose one hour when your inter-request gap regularly exceeds five minutes but stays under an hour, and the prefix is large enough that re-writing it repeatedly hurts. Where caching loses is high-variance, low-reuse traffic: single-shot requests whose prefix will never be seen again pay the write premium for nothing. Marking such prompts is a small, permanent, invisible tax. ## Latency, not just cost The read price is the headline, but the latency effect is often what justifies the feature. A cached prefix skips most of the prefill work, so time to first token on a very long stable context drops substantially. For an agent that re-sends a large system prompt and tool set on every turn, that shows up directly in perceived responsiveness. ## Practical consequences Cache lifetime interacts with traffic shape, so treat it as a tuning parameter, not a constant. Two patterns are worth internalizing. First, low-QPS services benefit from the one-hour tier far more than busy ones, because a busy service refreshes the five-minute window for free. Second, a keep-alive strategy — issuing a cheap request purely to refresh a cache entry — is usually a false economy: the refresh call itself is billed, and if the prefix is large, the cheapest correct answer is the longer TTL rather than synthetic traffic. Finally, remember what the TTL does not do. It does not make a prefix match: an expired entry and a changed prefix look identical in the usage counters (a creation instead of a read), so when hit rate falls, check prefix stability before assuming the entry timed out.