# Anthropic prompt caching: the TTL bet, worked four ways

*Anthropic is the only provider where the TTL you choose changes what you pay to write. That makes it the only one asking you to forecast your own request cadence — and to price the forecast.*

---

Anthropic's caching model is the most explicit of the three, in both senses. You mark what to cache, and you choose how long to keep it, and both choices show up on the invoice. [The multipliers](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) are uniform across every active Claude model: a 5-minute cache write costs 1.25× base input, a 1-hour write costs 2×, and a read costs 0.1×. Only the minimum cacheable length varies by model.

That uniformity is a gift for reasoning. The entire decision is ratios, so the conclusions below hold whatever model you're on and whatever the rates do next.

Vocabulary in [the glossary](/updates/llm-prompt-caching-what-it-is-and-key-terms-explained); the cross-provider chart is in [pricing 101](/updates/llm-prompt-caching-pricing-guide-and-cost-breakdown).

## The mechanic everything else depends on

> **Cost shape:** the 5-minute cache refreshes free on every hit. You pay for lapses, not requests.

Anthropic's docs are direct about this: [the cache is refreshed for no additional cost each time the cached content is used](https://platform.claude.com/docs/en/build-with-claude/prompt-caching). A prefix under steady traffic is written once and read forever.

Which reframes the TTL question entirely. It is not "how long does my session run." It's "how many times will this prefix go cold?" Because the read cost is identical on both tiers, those terms cancel out of any comparison, and the break-even sits at **1.65 lapses — independent of request count and independent of prefix size.** Two or more expected lapses, buy the hour.

## The clock starts earlier than you think

> **The trap:** generation time is inside your TTL window.

The lifetime is [measured from the start of the request that writes or reads the entry, not from the end of its response](https://platform.claude.com/docs/en/build-with-claude/prompt-caching). Anthropic's own example: a response that takes four minutes to stream leaves about one minute before the follow-up must begin.

For anything agentic this is the difference between a working cost model and a wrong one. The gap that matters is **start-to-start** between consecutive requests, not the gap between one response finishing and the next beginning. A tool-calling loop with long generations can blow a 5-minute window while looking, in your logs, like it had plenty of room.

Instrument start-to-start. Everything below assumes you have.

## Scenario one: the orchestrator waiting on sub-agents

> **Verdict:** 1-hour, and it isn't close.

An orchestrator that dispatches work and waits is idle by definition. Its own prefix — the plan, the tool definitions, the accumulated state — goes cold every time a sub-agent runs long. Anthropic names this case directly in their guidance for the 1-hour tier: [an agentic side-agent that will take longer than five minutes](https://platform.claude.com/docs/en/build-with-claude/prompt-caching).

Take eight orchestrator turns across 90 minutes, roughly twelve minutes apart. Illustrative rates, Sonnet 5 at $2.00/MTok, 100k prefix:

- **5-minute tier:** the cache dies before every turn. Eight writes, zero reads — **$2.00**. That is precisely what you'd have paid with no caching at all, because eight writes at 1.25× equals ten uncached sends.
- **1-hour tier:** roughly two writes across the span, six reads — **$0.92**.

**54% cheaper**, and the 5-minute tier has degraded to a pure 25% tax. Note "roughly two writes": TTL is measured from request start and reads refresh it, so the exact count depends on hit timing. Directionally it holds comfortably.

The subtlety worth stating: this is a **per-prefix** decision, not a per-application one. The orchestrator's prefix wants the hour. Its sub-agents, running tight internal loops, want five minutes. Same system, opposite answers.

Same logic covers human-gated approval steps and long-running verification tools — anywhere the gap is structural rather than incidental.

## Scenario two: the fast sub-agent

> **Verdict:** 5-minute. The premium buys nothing.

A sub-agent grinding through a tool loop with seconds between turns never lets its cache lapse. One write, then reads forever, each one refreshing the clock for free.

On the 1-hour tier that same workload pays 2× on the write for a window it never needed. On a single write against a 100k prefix that's $0.40 rather than $0.25 — trivial in isolation, and not trivial multiplied by every sub-agent invocation in production.

The one thing to watch here is not price but **invalidation**. Sub-agents often differ from their parent in exactly the ways that break caches: [modifying tool definitions invalidates the entire cache](https://platform.claude.com/docs/en/build-with-claude/prompt-caching), and changing the thinking configuration or `output_config.effort` always invalidates message blocks. If your sub-agents run at a different effort setting from the orchestrator, they are not sharing anything, whatever your prefix looks like.

## Scenario three: the chatbot

> **Verdict:** splits on cadence. Rapid-fire stays on 5 minutes; human-paced may not.

Two chatbots, opposite answers.

**Rapid-fire**, 100 turns roughly 30 seconds apart: the 5-minute cache never lapses. One write, 99 reads — **$2.23**. The 1-hour tier: **$2.38**. The premium buys 6% of extra cost and zero benefit. This is the case where "longer is safer" quietly taxes you.

**Human-paced**, where a user reads a long answer and thinks before replying: gaps routinely exceed five minutes, especially once you remember generation time counts against the window. Anthropic names this too — [storing a long chat conversation where you expect the user may not respond in the next 5 minutes](https://platform.claude.com/docs/en/build-with-claude/prompt-caching). Apply rule one: if you expect two or more lapses in a session, take the hour.

Two extras for chatbots specifically. **Automatic caching** is designed for exactly this shape — a single top-level `cache_control` field, with the breakpoint advancing to the last cacheable block as the conversation grows, so you never manage markers by hand. And watch the **20-block lookback**: if a conversation adds 20 or more blocks between writes, the lookback misses the previous entry entirely and you get no hit. Anthropic's remedy is a second breakpoint placed earlier, established before you need it.

The other lever here isn't cost at all. [Cache hits are not deducted against your rate limit](https://platform.claude.com/docs/en/build-with-claude/prompt-caching), so on a throughput-constrained chat product the 1-hour tier can be a capacity decision rather than a savings one.

## Scenario four: high-volume single-shot extraction

> **Verdict:** 5-minute, and the whole game is breakpoint placement.

Thousands of independent documents, same instruction block and schema on every request. Cadence is irrelevant — traffic is continuous, so the cache never lapses. One write, then reads all day: **$20.23 against $200 uncached across 1,000 documents, a 90% saving.** The theoretical maximum, near enough.

Which makes this the scenario where getting it wrong is most expensive, and it goes wrong two ways.

**Breakpoint on the wrong block.** The document is the variable suffix; the instructions are the stable prefix. Put `cache_control` on the block containing the document — or on anything carrying a timestamp or request ID — and Anthropic's [documented failure mode](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) fires: the prefix hash differs every time, the lookback finds nothing because writes only ever happen at breakpoints, and you pay a fresh 1.25× write on every single request while never collecting a read. At this volume that's a 25% surcharge on 200 dollars rather than a 90% discount.

Worth noting that **automatic caching hits the same trap here**, because it places the breakpoint on the last cacheable block — which in this structure is the document. This is the one scenario where you should reach for an explicit breakpoint instead.

**Falling under the minimum.** If your instruction block is lean, check it against your model's floor: [512 tokens on Opus 5, 1,024 on Sonnet 5, 4,096 on Haiku 4.5](https://platform.claude.com/docs/en/build-with-claude/prompt-caching). Under the floor, caching silently doesn't happen and no error is returned. Anthropic's own advice is that padding the cached content up to the threshold is often worth it. On Haiku in particular, a 4,096-token floor is high enough that plenty of production extraction prompts sit below it and nobody notices.

One more, easy to miss at scale: [a cache entry only becomes available after the first response begins](https://platform.claude.com/docs/en/build-with-claude/prompt-caching). Fan out 500 parallel requests cold and every one of them pays a write. Send one, wait, then fan out.

## What to log, and what it won't tell you

Anthropic's reporting is the most complete of the three. `cache_creation_input_tokens` and `cache_read_input_tokens` give you writes and reads, and the `cache_creation` object breaks writes out by TTL into `ephemeral_5m_input_tokens` and `ephemeral_1h_input_tokens` — so you can actually audit whether your TTL choices match your cadence, which is not possible on either other provider.

The field that misleads is `input_tokens`. It counts only tokens *after* your last breakpoint, not your whole prompt. Total input is the sum of all three. Any dashboard treating `input_tokens` as request size will understate your traffic badly on cached workloads.

What none of it tells you is the counterfactual — whether a different TTL would have been cheaper. That requires joining write counts to inter-request gaps, and it's the analysis worth building once.

## The forecast is the product

Anthropic is selling you an option on your own traffic pattern. Predict cadence correctly and caching approaches a 90% discount on your prefix. Predict it wrong in one direction and you buy headroom you never use; wrong in the other and you re-pay the write until someone notices.

The good news is that the decision compresses to one question, asked per prefix rather than per app: **will this be re-hit within five minutes of the previous request starting?** Reliably yes means five minutes. No, but within the hour, means the hour. No to both means don't cache it — you'll pay the premium for nothing.

Next: [OpenAI](/updates/llm-prompt-caching-openai-how-to-and-pro-tips), where there's no TTL choice at all and the entire optimisation is boundary placement.

*Coolhand Labs tracks inference pricing across providers, including per-TTL write tiers. [See what we track](https://coolhandlabs.com/inference-apis).*