Anthropic Prompt Caching: 5min vs 1hr Pricing
Anthropic prompt caching offers two tiers: 5-minute (1.25x write, 0.1x read) and 1-hour (1.5x write, 0.1x read). Decision guide for agent workloads.
TL;DR — Anthropic’s prompt caching has two tiers: 5-minute cache (1.25× write cost, 0.1× read cost) and 1-hour cache (1.5× write cost, 0.1× read cost). Both give you 90% savings on repeated context. The 5-minute tier is cheaper to write and perfect for agent loops that complete in minutes. The 1-hour tier costs more to write but saves massively for long-running sessions and multi-turn conversations. Pick based on how long your agent stays active per task.
Prompt caching is the single biggest cost optimization available for Anthropic models in 2026. If your agent sends the same system prompt, loaded documents, or conversation prefix on every call — and it almost certainly does — caching turns $15/M input tokens (Opus 5) into $1.50/M for cached reads. That’s a 90% cost reduction on repeated context.
But Anthropic doesn’t offer one-size-fits-all caching. They split it into two tiers with different economics. Most developers pick one without understanding the other. This piece breaks down exactly when each tier saves you money and when it costs you extra.
How Prompt Caching Works
On every API call, you can mark sections of your prompt as cacheable using cache_control breakpoints. The first call writes to cache (at a premium). Subsequent calls within the cache TTL read from cache (at 90% discount).
from anthropic import Anthropic
client = Anthropic()
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=4096,
messages=[
{
"role": "user",
"content": [
{
"type": "text",
"text": large_system_context, # 50K tokens of docs
"cache_control": {"type": "ephemeral"} # 5-min cache
},
{
"type": "text",
"text": "Based on the above, answer this specific question..."
}
]
}
]
)The cached portion doesn’t get re-processed on subsequent calls. It’s stored server-side and injected directly, saving both cost and latency.
The Two Tiers
| Parameter | 5-Minute Cache | 1-Hour Cache |
|---|---|---|
| Cache TTL | 5 minutes | 1 hour |
| Write cost multiplier | 1.25× base input price | 1.5× base input price |
| Read cost multiplier | 0.1× base input price | 0.1× base input price |
| Cache control type | "ephemeral" | "persistent" |
| Minimum cacheable tokens | 1,024 | 1,024 |
| Latency reduction | Yes (proportional to cached size) | Yes (proportional to cached size) |
Both tiers give the same 90% read discount. The difference is entirely in:
- How long the cache lives (5 min vs 60 min)
- How much you pay to write it (25% vs 50% premium over base input cost)
Cost Math: When Each Tier Wins
Example: Sonnet 5 with 50K tokens of cached context
Base pricing: $3/M input, $15/M output
5-Minute Cache:
- Write cost: 50K tokens × $3/M × 1.25 = $0.1875
- Read cost (per hit): 50K tokens × $3/M × 0.1 = $0.015
- Break-even: After 1.25 reads (i.e., 2nd call pays for itself)
1-Hour Cache:
- Write cost: 50K tokens × $3/M × 1.5 = $0.225
- Read cost (per hit): 50K tokens × $3/M × 0.1 = $0.015
- Break-even: After 1.5 reads (i.e., 2nd call pays for itself)
Comparison table — total cost for N calls with 50K cached context (Sonnet 5):
| Calls | No Cache | 5-Min Cache | 1-Hr Cache | Best Option |
|---|---|---|---|---|
| 1 | $0.15 | $0.1875 | $0.225 | No cache |
| 2 | $0.30 | $0.2025 | $0.24 | 5-min |
| 5 | $0.75 | $0.2475 | $0.285 | 5-min |
| 10 | $1.50 | $0.3225 | $0.36 | 5-min |
| 20 | $3.00 | $0.4725 | $0.51 | 5-min |
| 50 | $7.50 | $0.9225 | $0.96 | 5-min |
Wait — the 5-minute cache is cheaper in every scenario? Not exactly. This table assumes all calls happen within the cache TTL. Here’s where the 1-hour tier wins:
When calls are spread across time
Scenario: Agent makes 30 calls over 45 minutes
With 5-minute cache:
- Cache expires ~9 times (45min / 5min = 9 expiration cycles)
- Cache writes: 9 × $0.1875 = $1.6875
- Cache reads: 21 × $0.015 = $0.315
- Total: $2.0025
With 1-hour cache:
- Cache expires 0 times (45min < 60min)
- Cache writes: 1 × $0.225 = $0.225
- Cache reads: 29 × $0.015 = $0.435
- Total: $0.66
The 1-hour cache saves 67% in this scenario. The key variable: how many times does the cache expire during your task?
Decision Tree
How long does your agent stay active per task?
│
├── < 5 minutes (fast agent loops)
│ └── Use 5-minute cache
│ (cheaper write, cache won't expire mid-task)
│
├── 5-30 minutes (medium workflows)
│ ├── Calls clustered in bursts? → 5-minute cache
│ │ (each burst finishes within 5 min)
│ └── Calls spread evenly? → 1-hour cache
│ (avoid repeated write premiums)
│
├── 30-60 minutes (long sessions)
│ └── Use 1-hour cache
│ (single write, dozens of cheap reads)
│
└── > 60 minutes (very long sessions)
└── Use 1-hour cache
(still better than 5-min; cache renews on access)Agent Patterns and Cache Tier Selection
| Agent Pattern | Typical Duration | Calls per Task | Best Cache Tier | Why |
|---|---|---|---|---|
| Code review (single PR) | 2-4 min | 5-15 | 5-minute | Fast, concentrated burst |
| Research agent | 15-45 min | 30-80 | 1-hour | Long session, spread calls |
| Customer support session | 5-30 min | 10-40 | 1-hour | Unpredictable duration |
| Batch document processing | 1-3 min per doc | 3-8 per doc | 5-minute | Each doc is independent burst |
| Multi-agent orchestration | 10-60 min | 50-200 | 1-hour | Long coordination cycles |
| CI/CD pipeline agent | 3-8 min | 10-30 | 5-minute | Fast, predictable |
| Interactive coding session | 30-120 min | 20-100 | 1-hour | User-paced, unpredictable |
Savings with Opus 5 (Where It Really Matters)
The cache savings are most dramatic with Opus 5 because its base input price ($15/M) is so high:
100K tokens cached, Opus 5, 20 calls over 30 minutes:
| Approach | Total Input Cost |
|---|---|
| No cache | $30.00 |
| 5-min cache (6 writes) | $11.25 + $2.10 = $13.35 |
| 1-hr cache (1 write) | $2.25 + $2.85 = $5.10 |
The 1-hour cache saves 83% vs no caching on this Opus 5 workload. That turns a $30 agent run into a $5 one — the difference between “too expensive to use Opus 5 for this” and “actually affordable.”
This is why caching strategy directly affects model selection. With 1-hour caching, Opus 5 on repeated-context tasks costs less than Sonnet 5 without caching would cost for the same token volume.
Implementation Tips
Cache what doesn’t change
The ideal caching target is content that stays identical across calls:
- System prompts (thousands of tokens of instructions)
- Loaded documents (the codebase, the contract set, the research papers)
- Conversation history prefix (grows but old messages don’t change)
- Tool definitions (function schemas)
Don’t cache what changes
User messages, variable data, and dynamic state should sit after the cache breakpoint. Changing any byte in the cached segment invalidates the cache.
Layer your cache breakpoints
You can have multiple breakpoints. Cache the system prompt (rarely changes), then cache loaded documents (changes per task), then leave the current turn uncached:
messages = [
{"role": "system", "content": [
{"type": "text", "text": system_prompt, "cache_control": {"type": "persistent"}},
]},
{"role": "user", "content": [
{"type": "text", "text": loaded_docs, "cache_control": {"type": "persistent"}},
{"type": "text", "text": current_question} # Not cached
]}
]Monitor cache hit rates
Track cache_creation_input_tokens and cache_read_input_tokens in API responses. If your cache hit rate is below 70%, you’re paying write premiums without enough read savings. Investigate why — usually it’s cache invalidation from changing content in the cached segment.
Combining with Model Routing
The optimal cost architecture combines caching with model routing:
- Cache system prompt + docs with 1-hour tier
- Route simple calls to Sonnet 5 (cached context + cheap model)
- Route complex calls to Opus 5 (same cached context + deep reasoning)
Both models share the cache when accessed through the same prompt structure. You don’t pay the write premium twice.
For detailed Sonnet 5 agent patterns, see Claude Sonnet 5 for agents and coding. For full pricing across providers, see our LLM API pricing guide.
FAQ
Does the cache persist across different API keys?
No. Cache is scoped to your API key/organization. Different keys sharing the same prompt won’t benefit from each other’s cache.
What happens if I exceed 1M tokens with cached content?
The total prompt (cached + uncached) still can’t exceed the model’s context window. Caching doesn’t extend the context limit — it reduces cost and latency for content within that limit.
Can I force-invalidate a cache entry?
Not directly. Change the cached content (even one character) and the old cache is automatically invalidated. A new cache write happens on the next call. If you need fresh processing of the same content, add a unique nonce to the cached section.
Is there a minimum call volume where caching breaks even?
Two calls. Both tiers break even on the second call (the write premium is recovered by the read discount). If you’re making only single calls with unique context each time, caching adds 25-50% cost with zero benefit.
Does cache reduce latency as well as cost?
Yes. Cached tokens skip input processing, reducing time-to-first-token proportionally. A 100K cached prompt with 5K new tokens responds as fast as a 5K-token prompt would. For large-context agent workloads, this 10-20x latency improvement on the cached portion is often more valuable than the cost savings.
