# Claude Cache TTL: 5 Minutes vs 1 Hour, With Break-Even Math > Claude cache TTL: choose 5 minutes, 1 hour or keepalive pings by request gap, then verify billable fields. Anthropic prompt caching pricing checked Nov 2026. Claude cache TTL is the window in which a repeated prompt prefix can be read from cache: five minutes by default on the Messages API, or one hour when you request the extended TTL. The right choice depends on when the next request starts, how much of the prefix expires, and whether your process can affordably send a cache read while it waits. For the basics, start with [how prompt caching works](/blog/prompt-caching-explained). I make Octomind, so weigh my framing with that in mind. I checked Anthropic’s current pricing, API, and Claude Code documentation on November 1, 2026; the code below is a request fragment, not a run. The measurements are single first-party Messages API runs from October 31, 2026. **The short answer:** Keep the 5-minute cache for requests that start inside five minutes of the last cache use. For a 5–60 minute gap, use a 1-hour marker if you cannot ping and expect the same prefix to return; a priced 5-minute keepalive can cost less when cache reads are cheap and the expiring conversation tail is small. Neither TTL covers a gap over an hour. On the direct API, switching a live conversation from a 5-minute marker to a 1-hour marker rewrote the full prefix in my measured run, so choose the marker before the session and keep it consistent. ## What is the Claude cache TTL, and what does each usage field mean? With Anthropic API caching, a cache entry on the direct Messages API lasts five minutes by default, and each successful use refreshes that window; you can request one hour with `"ttl": "1h"`. The timer starts at the beginning of the request, so a long response uses part of the window before it finishes ([Anthropic prompt-caching docs, 2026](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)). ```json { "cache_control": { "type": "ephemeral", "ttl": "1h" } } ``` Place that block on the stable prefix you want cached. The minimum cacheable prefix is model-dependent: Opus 5.5, Sonnet 5.5, Fable 5.1, and Haiku 5.5 need 512 tokens; the docs list 1,024, 2,048, or 4,096 for some other models. You can define up to four breakpoints, and the API checks a 20-block lookback at each breakpoint when searching for a matching entry ([Anthropic prompt-caching docs, 2026](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)). If you mix TTLs, put the longer-lived entries before shorter ones; Anthropic’s documented A/B/C billing rule charges a read through the highest hit, then a 1-hour write up to the next 1-hour breakpoint, then a 5-minute write through the last breakpoint ([Anthropic’s mixed-TTL rule, 2026](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)). `cache_read_input_tokens` is the cache hit, `cache_creation_input_tokens` is the write, and `input_tokens` is only the uncached tail after the final breakpoint; with mixed TTLs, `ephemeral_5m_input_tokens` and `ephemeral_1h_input_tokens` show which write duration was used ([Anthropic prompt-caching docs, 2026](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)). ## Which Claude cache TTL is cheaper for your request gap? Use the request start-to-start gap as your first rule. A 5-minute hit is billed at the cache-read rate and refreshes without another write charge; for a repeated prefix that returns after five minutes but within an hour, a 1-hour entry can avoid another 5-minute write, while pings are an alternative if you can keep the process alive. Anthropic prompt caching pricing below is in US dollars per million tokens, checked November 1, 2026. In Claude prompt caching pricing, the read multiplier differs by model, so the single “90% off” shorthand is not accurate for every current model ([Anthropic pricing, 2026](https://platform.claude.com/docs/en/about-claude/pricing)). | Model | Input | 5m write | 1h write | Cache read | Read multiplier | | ----------------- | -----: | -------: | -------: | ---------: | --------------: | | Claude Sonnet 5.5 | $2.00 | $2.50 | $4.00 | $0.10 | 0.05× | | Claude Opus 5.5 | $4.00 | $5.00 | $8.00 | $0.20 | 0.05× | | Claude Fable 5.1 | $10.00 | $12.50 | $20.00 | $0.25 | 0.025× | | Claude Sonnet 5 | $2.00 | $2.50 | $4.00 | $0.20 | 0.1× | | Claude Opus 5 | $5.00 | $6.25 | $10.00 | $0.50 | 0.1× | The break-even count against sending the whole prefix uncached is different from the choice between TTLs. A 5-minute write costs `1.25p`; one later read at `rp` brings the total to `1.25p + rp`, below the `2p` for two uncached requests for each read multiplier above. A 1-hour write costs `2p`; it needs two later reads to beat three uncached requests: `2p + 2rp < 3p`. That means the 5-minute option breaks even on the second total request, and the 1-hour option on the third, counting the first write. | Start-to-start gap | Pick | Why | | ---------------------------------- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | Under 5 minutes | 5m | A cache hit refreshes the 5-minute window without another write premium. | | Over 5 minutes, at most 60 minutes | 1h if you cannot ping; otherwise compare ping cost with the 1h premium | A 1h hit avoids a new 5m write; enough 5m pings may still cost less. | | Over 60 minutes | Neither TTL alone | The entry expires; use a later cold write, or a separate strategy that actually spans the wait. | For Claude Sonnet 5.5, if the 5-minute entry expires before the next request, the next 5-minute write costs `$2.50/M`; a 1-hour write followed by a hit costs `$4/M + $0.10/M`. For the reused prefix, that is `1.25p + 1.25p = 2.5p` versus `2p + 0.05p = 2.05p`; the hour wins on that return. If your next request arrives inside five minutes, the hour’s higher first write buys no extra hit. Prices checked November 1, 2026 ([Anthropic pricing, 2026](https://platform.claude.com/docs/en/about-claude/pricing)). ## Does switching a conversation from 5m to 1h rewrite its cache? In my single October 31, 2026 runs, yes: the first request after changing a moving conversation marker from five minutes to one hour reported zero cache reads and rewrote the full prefix on both Sonnet 5.5 (18,781 tokens) and Opus 5.5 (18,774 tokens). Anthropic documents billing for mixed TTL breakpoints, but its docs do not say that a 1-hour marker at the same position can read an existing 5-minute entry; treat this result as an observation, not a general cross-TTL guarantee. On Sonnet 5.5, that measured turn’s cache write alone cost `18,781 × $4/M = $0.075124`; four uncached input tokens add `$0.000008`, for `$0.075132` before output. If the old 16,367-token prefix had been read and only the 2,414-token new turn written at one hour, the same turn would have been `16,367 × $0.10/M + 2,414 × $4/M + 4 × $2/M = $0.011301`. The gap between those calculations is why a mid-session marker change can silently dominate the turn. The entire four-turn measured shape cost about `$0.1186` on Sonnet 5.5 when turns 1–3 used 5m and turn 4 changed to 1h. Recomputing the same token counts, all-5m was about `$0.0512`, and all-1h about `$0.0793`, before output charges. These are derived costs from one run, not a workload benchmark; they show why you should choose the marker before the conversation starts instead of switching midstream. ## Can keepalive pings cost less than a 1-hour cache? Sometimes. A keepalive ping is one cache read of the full cached prefix, while expiry forces a new write of the portion that lost its TTL. The bound on pings that can pay for themselves during one wait is `B = ((w − r) / r) × tail_share`, where `w` is the 5-minute write multiplier, `r` is the read multiplier, and `tail_share` is the fraction of the full pinged prefix that expires. With `w = 1.25`, the upper bound is 24 pings at `r = 0.05`, 49 at `r = 0.025`, and 11 at `r = 0.1`, when the whole prefix expires; multiply each by the expiring-tail share. Take Sonnet 5.5 with 30K system-and-tool tokens on a 1-hour entry and a 30K conversation tail on five minutes. A ping reads all 60K tokens for `60,000 × $0.10/M = $0.006`. If the tail expires, re-creating it instead of reading it costs `(30,000 × ($2.50 − $0.10))/M = $0.072` extra. The bound is `$0.072 / $0.006 = 12` pings, or `12 × 270 seconds = 54 minutes` at Octomind’s 270-second interval. Prices checked November 1, 2026 ([Anthropic pricing, 2026](https://platform.claude.com/docs/en/about-claude/pricing)); Octomind derives that interval as 0.9 × the 5-minute TTL, it is not an Anthropic value. The 1-hour choice can beat pings on models whose read price is 0.1× input. For a 200K Opus 5 prefix, a ping costs `200,000 × $0.50/M = $0.10`; the extra 1-hour write premium over a 5-minute write is `200,000 × ($10 − $6.25)/M = $0.75`. That premium equals `$0.75 / $0.10 = 7.5` pings, so the hour is cheaper than eight pings across an idle gap. The gap must still fit inside the hour, and if a process is available to ping fewer than eight times, pings cost less. On Sonnet 5.5, the same 200K prefix costs `$0.02` per ping and the 1-hour premium is `$0.30`, or 15 pings; a 5-minute keepalive remains cheaper for a single gap that fits inside an hour. Prices checked November 1, 2026 ([Anthropic pricing, 2026](https://platform.claude.com/docs/en/about-claude/pricing)). ## How do I verify a cache hit in a direct API request? Put the cache marker at the end of a prefix that stays identical, then compare the response’s read, write, and uncached-tail counters across two requests. A nonzero `cache_read_input_tokens` is the hit; on a new write, inspect `cache_creation_input_tokens` and the TTL-specific fields. ```python response = client.messages.create( model="claude-sonnet-5-5", max_tokens=256, system=[{ "type": "text", "text": SYSTEM_PROMPT, "cache_control": {"type": "ephemeral", "ttl": "1h"}, }], messages=[{"role": "user", "content": "Ask your question here."}], ) usage = response.usage print(usage.cache_read_input_tokens) print(usage.cache_creation_input_tokens) print(usage.input_tokens) print(usage.cache_creation.ephemeral_1h_input_tokens) ``` This fragment uses the documented field names; supply a stable prompt long enough for your model’s minimum prefix and keep the model, tools, and earlier messages unchanged. Anthropic’s formula is `total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens` ([Anthropic prompt-caching docs, 2026](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)). I also tested a non-streaming `max_tokens: 0` pre-warm after a real request. Both Opus 5.5 and Sonnet 5.5 returned `stop_reason: "max_tokens"`, empty content, 9,136 cache-read tokens, zero cache-creation tokens, and zero output tokens: the request read the cache and wrote nothing, with no generated output. It was one run on October 31, 2026. Anthropic documents this pre-warm request shape too ([Anthropic prompt-caching docs, 2026](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)). ## What is the Claude Code cache TTL, and how do I override it? The Claude Code cache TTL follows the billing route unless you set one. Within Claude subscription plan usage, the main conversation uses one hour; usage credits, API keys, and cloud providers use five minutes by default. The “everything else” bucket, including subagents and compaction, defaults to five minutes ([Claude Code prompt-caching docs, 2026](https://code.claude.com/docs/en/prompt-caching)). | Billing route | Main conversation default | Other requests default | | ----------------------------------------- | ------------------------- | ------------------------------------------------ | | Claude subscription, within plan usage | 1 hour | 5 minutes, except some server-controlled helpers | | Usage credits, API key, or cloud provider | 5 minutes | 5 minutes | To set a TTL for the main conversation, use `promptCacheTtl` in Claude Code settings or `CLAUDE_CODE_PROMPT_CACHE_TTL`; for other requests, use `subagentPromptCacheTtl` or `CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL`. Each accepts `5m` or `1h`, and the controls require Claude Code v2.1.242 or later. The environment variable takes precedence over the matching setting; `FORCE_PROMPT_CACHING_5M=1` overrides both buckets, while `ENABLE_PROMPT_CACHING_1H=1` requests one hour for both ([Claude Code prompt-caching docs, 2026](https://code.claude.com/docs/en/prompt-caching)). ```json { "promptCacheTtl": "1h", "subagentPromptCacheTtl": "5m" } ``` To check what Claude Code wrote, run `claude -p "hello" --output-format json` and inspect `usage.cache_creation`: one-hour writes appear in `ephemeral_1h_input_tokens`, and five-minute writes in `ephemeral_5m_input_tokens` ([Claude Code prompt-caching docs, 2026](https://code.claude.com/docs/en/prompt-caching)). ## How does Octomind keep a 5-minute conversation cache warm? Octomind keeps the system prompt and tools on a 1-hour entry and the changing conversation on the provider’s 5-minute default. Its `cache_keepalive_enabled` setting is opt-in and ships `false`; when enabled, it can send priced pre-warm reads every 270 seconds while the session waits, and it learns a budget from that session’s reply, background-work, and tool waits. The bound above is a ceiling, not the default spend: until three waits of a kind are measured it sends at most two pings, it never pings past the longest wait of that kind seen so far, and a rate-limited ping (HTTP 429) ends the keepalive for that wait. It skips a ping when the next request will compress or trim the conversation, because that would replace the prefix being warmed ([Context Compression docs](/docs/usage/08-compression)). `/info` shows the pings sent, their cost, and why the last budget was chosen. The request fragment above shows the direct API route; Claude Code has its own TTL settings, and a plain Messages API client can implement the same marker or pre-warm request itself. Octomind is one option when an agent runtime should own those waits and count ping costs in the session total. Its cache keepalive does not guarantee a hit or a saving; compare the actual session report. ## Which TTL should I set? Use 5 minutes for active request bursts, 1 hour for a 5–60 minute return when you cannot cheaply ping, and a measured keepalive budget when reads cost less than the extra write premium. Keep the marker steady through the conversation, then verify the write and read fields instead of guessing from elapsed time. Related reading: [compare LLM API prices by task](/blog/llm-api-pricing-comparison) · [see how agent context drives cost](/blog/tokenmaxxing-ai-agent-costs)