Prompt Caching for Large Claude Context

Prompt caching helps repeated stable prefixes

Prompt caching is useful when multiple requests share a large stable prefix: long instructions, many examples, a large background document, or a multi-turn base state. Instead of paying the full processing cost every time, you mark cache breakpoints and let the platform reuse the cached prefix when possible.

It is especially relevant for agents that repeatedly ask short questions against the same large source packet, evaluation harnesses that run many variants against a shared rubric, and workflows with expensive examples that rarely change.

Cache reads are not priced the same on every model

The long-standing rule is that a cache read costs 10 percent of the base input price, a 5-minute cache write costs 1.25x base input, and a 1-hour write costs 2x. That still holds for Claude Opus 5, Claude Sonnet 5, and Claude Haiku 4.5.

Claude Fable 5.1 is the exception. Its cache reads are 2.5 percent of base input, which is $0.25 per million tokens against a $10 base input price. Anthropic described this as a 75 percent cut relative to the previous Fable cache-read rate and estimated roughly 25 percent savings on a typical workload, rising to around 45 percent on highly agentic ones.

This changes the arithmetic behind model choice. On Fable 5.1 a cached million-token prefix is read back for a quarter of a dollar, so an agent that re-reads a large stable packet on every step may be cheaper on the more expensive model than on a cheaper one with a 10 percent read rate. Run the comparison on your own hit rate rather than assuming the lower base price wins.

• Claude Fable 5.1: $10 base input, $0.25 cache read (2.5 percent), $50 output.
• Claude Opus 5: $5 base input, $0.50 cache read (10 percent), $25 output.
• Claude Sonnet 5: $2 base input, $0.20 cache read (10 percent), $10 output.
• Claude Haiku 4.5: $1 base input, $0.10 cache read (10 percent), $5 output.

Changing tools mid-conversation no longer has to cost the cache

Prompt caching works on prefixes, so anything near the front of the request has historically been expensive to touch. Tool definitions usually sit in that prefix, which meant adding, removing, or editing a tool part-way through a conversation invalidated the cache and forced a full rewrite on the next call.

Claude Opus 5 ships a beta that allows mid-conversation tool changes without invalidating the prompt cache. For agent builders this removes a real design constraint: you can narrow the tool surface as a task progresses, load a specialist tool only when a step needs it, or drop tools that are no longer relevant, without paying to re-cache the whole prefix each time.

Treat it as a beta and verify against your own usage metrics before planning around it. Confirm the behavior in the Opus 5 model documentation and watch `cache_creation_input_tokens` after a tool change to check that a rewrite did not silently happen anyway.

Caching does not make bad context good

Caching lowers repeated work. It does not decide whether the context is relevant, current, non-duplicative, or safe. If your prefix contains stale docs, conflicting instructions, or 50 examples when five would do, caching just makes the bad prefix cheaper to reuse.

The context-engineering order is selection first, caching second. Trim and structure the prefix, measure tokens, then cache the parts that are genuinely stable.

TTL changes the operational model

The default cache lifetime is short, and Anthropic documents a longer 1-hour option with different cost implications. Short TTLs work for bursty tasks: a user asks several questions against the same packet, or an eval suite runs quickly. Longer TTLs are better when a large shared context is reused on a cadence over a longer session.

Cache design should reflect how your workload actually repeats. If calls are parallel, note that cache availability can depend on the first response beginning before subsequent requests expect a cache hit.

Track cache reads and writes

Prompt caching should be observable. Track cache read tokens, cache creation tokens, uncached input tokens, latency, and answer quality. A cache that rarely hits adds complexity without much value. A cache that hits frequently but serves stale context is a correctness risk.

FAQ

Sources Used

• Prompt caching, Claude Platform Docs. Accessed 2026-09-19. Official prompt-caching behavior, cache lifetime, prefix caching, usage fields, and invalidation patterns.
• Pricing, Claude Platform Docs. Accessed 2026-09-19. Official model pricing and prompt-caching multipliers for base input, cache writes, cache reads, and output tokens.
• Claude Fable and Mythos 5.1, Anthropic. Accessed 2026-09-19. September 1, 2026 launch announcement, including the 75 percent cache-read price reduction and its expected effect on agentic workloads.
• Claude Opus 5 overview, Claude Platform Docs. Accessed 2026-09-19. Opus 5 model card: 1M-token context window, adaptive thinking, and the beta allowing mid-conversation tool changes without invalidating the prompt cache.
• Token counting, Claude Platform Docs. Accessed 2026-09-19. Official endpoint guidance for estimating input tokens, costs, rate limits, and model routing.
• Context windows, Claude Platform Docs. Accessed 2026-09-19. Official context-window behavior, token accumulation, extended thinking and tool-use accounting, and compaction guidance.