Cache TTL Options and Pricing Reference

A quick reference for the two cache TTL (time-to-live) windows Claude supports, what each one costs relative to a normal input token, and how to select one in the cache_control block.

How to Use This Reference

Use this page to decide between the 5-minute default and the 1-hour extended TTL for a given workload.
Treat the pricing behavior described here as qualitative and relative - always confirm current exact multipliers at platform.claude.com/docs before budgeting, since pricing moves independently of this page.
Pair this reference with usage.cache_read_input_tokens and usage.cache_creation_input_tokens on real responses to validate your assumptions against actual traffic.
Revisit your TTL choice whenever your request cadence changes - a workload that used to fire every few seconds and now fires every few minutes may need the longer TTL to keep hitting cache.

TTL Options at a Glance

TTL	`cache_control` value	Cache lifetime	Cache write cost	Best fit
Default (5 minutes)	`{"type": "ephemeral"}`	Refreshed on each hit; expires 5 minutes after the last access	Base cache-write multiplier over a normal input token	Interactive sessions, chat UIs, request bursts within a few minutes of each other
Extended (1 hour)	`{"type": "ephemeral", "ttl": "1h"}`	Refreshed on each hit; expires 1 hour after the last access	Higher cache-write multiplier than the 5-minute default	Long-running agent sessions, batch jobs spread over an hour, infrequent-but-recurring workloads

Both TTLs are ephemeral: the cache entry's expiration resets on every cache hit, so a steady stream of requests within the window keeps the entry alive indefinitely.
A cache read (cache_read_input_tokens) is always billed at a lower rate than a normal input token, regardless of which TTL wrote the entry.
A cache write (cache_creation_input_tokens) costs more than a normal input token on both TTLs - the 1-hour TTL's write multiplier is higher than the 5-minute TTL's write multiplier, since you're paying for a longer-lived guarantee.
Exact multipliers vary by model and change over time; this page intentionally avoids quoting fixed dollar amounts.

Setting the TTL in Python

import anthropic
 
client = anthropic.Anthropic()
 
# 5-minute default TTL - omit "ttl" entirely, or set it explicitly.
system_5m = [
    {
        "type": "text",
        "text": "You are Acme Corp's support assistant." * 50,
        "cache_control": {"type": "ephemeral"},

Deciding Between the Two

Estimate your request cadence. If consecutive requests sharing a prefix are typically seconds to a couple of minutes apart, the 5-minute default is usually sufficient and cheaper to write.
Estimate session length. If a single user or agent session can go 10+ minutes between calls that reuse the same prefix - long research sessions, human-in-the-loop review, slow batch pipelines - the 1-hour TTL avoids repeatedly eating the cache-write cost.
Weigh write cost against expected hit count. A higher write multiplier pays for itself once you get enough cache reads against that write; a prefix reused only once or twice doesn't recoup either TTL's write cost.
Default to 5 minutes unless you have a specific reason. It's the cheaper write and matches the majority of interactive, bursty workloads; reach for 1 hour deliberately, not by default.
Re-evaluate after measuring, not before. Instrument usage.cache_read_input_tokens and usage.cache_creation_input_tokens in production and revisit the TTL choice based on observed hit rates rather than a guess.

Checking Which TTL Actually Applied

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=200,
    system=system_1h,
    messages=[{"role": "user", "content": "What's your refund window?"}],
)
 
usage = response.usage

A nonzero cache_creation_input_tokens with zero cache_read_input_tokens means this call wrote the cache for the first time (or after it expired).
A nonzero cache_read_input_tokens means the request hit an existing entry under whichever TTL wrote it.
The response does not directly echo back which TTL was used - track that on your own side, since you set it in the request.

FAQs

What are the two TTL options for prompt caching?

A default 5-minute window and an extended 1-hour window, both set via the cache_control block on cacheable content.

How do I select the 1-hour TTL instead of the default?

Add "ttl": "1h" inside the cache_control dict: {"type": "ephemeral", "ttl": "1h"}. Omitting ttl uses the 5-minute default.

Does the cache expire exactly 5 minutes (or 1 hour) after I first write it?

No - both TTLs are ephemeral and refresh on every cache hit, so the expiration clock resets each time the entry is read, not just when it was written.

Which TTL is cheaper to write?

The 5-minute default has a lower cache-write cost multiplier than the 1-hour extended TTL. Reads are billed the same lower rate regardless of which TTL wrote the entry.

Should I always use the 1-hour TTL to be safe?

No - default to the 5-minute TTL unless you have a concrete reason (session gaps longer than a few minutes) to pay the higher write cost for the 1-hour window.

Where do I find the current exact price multipliers for cache writes and reads?

At platform.claude.com/docs. This page deliberately describes cost behavior qualitatively because exact multipliers change over time and vary by model.

Can I mix TTLs within the same request, e.g. 1 hour on tools and 5 minutes on system?

The TTL is set per cache_control block, so different breakpoints in the same request can use different TTLs if your workload genuinely needs that split.

How can I tell which TTL a given response used?

The response doesn't echo it back directly - you already know it, since you set ttl in the request. Track it on your own side alongside the usage fields if you need it in logs.

Does a cache read reset the TTL clock, or only a cache write?

A cache read also refreshes the expiration - that's what "ephemeral, refreshed on hit" means. A steady stream of hits within the window keeps the entry alive well past its original TTL.

Is a cache read always cheaper than a normal input token?

Yes, cache reads are billed at a lower rate than normal input tokens on both TTLs; the TTL choice affects the write cost, not the read discount.

How Prompt Caching's Prefix Match Actually Works - the mechanism these TTLs govern.
Prompt Caching Basics - set your first TTL in a working request.
Verifying Cache Hits with cache_read_input_tokens - confirm which TTL is actually paying off.
Prompt Caching ROI - When Cache Writes Actually Pay Off - the cost-benefit math in more depth.

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the official anthropic Python SDK (latest 0.x release). Model names, SDK versions, and pricing move quickly - verify current specifics at platform.claude.com/docs before relying on them.

Search Documentation