Anthropic Prompt Caching, The Lever Indian Operators Are Leaving On The Table
Cache reads cost one tenth of the base input rate, while a five-minute write costs 1.25 times it. The savings depend on a stable shared prefix.
Prompt caching references the entire prompt, including tools, system prompts, and messages, up to and including the block designated with cache_control.
— Anthropic, Prompt caching documentation (opens in a new tab)
- A cache hit is billed at 0.1x the base input price, but a five-minute write is billed at 1.25x. Reuse a stable prefix before calling the setup a saving.
- Put cache_control after the shared tools, instructions, and context. A changing user turn belongs after that boundary.
- Use the five-minute duration when requests recur inside that window. Use one hour for longer gaps, then measure whether the additional write charge earns its place.
- Track cache_read_input_tokens, cache_creation_input_tokens, and input_tokens together. The response usage fields, not a dashboard hunch, prove a hit.
Prompt caching is only a cost lever when the same prefix is read again. That sounds obvious, but it is easy to mistake a cache write for a cache strategy. The current Anthropic prompt-caching documentation is the source of truth for the request order, cache controls, durations, and response usage fields. This guide turns those mechanics into a conservative operating checklist.
Do not start with a projected saving or a model-specific rate card. Start with a trace of your own requests: what stays unchanged, what moves on every turn, and whether later requests report cached input. That approach travels cleanly from a document-heavy support assistant to a coding workflow such as a five-model fallback router.
What The Pricing Actually Says
Anthropic documents four relevant input multipliers. Base input is 1x. A five-minute cache write is 1.25x, a one-hour cache write is 2x, and a cache read is 0.1x. The provider's pricing page carries the current model-specific rates; do not copy a rate from an old post into a budget.
| Input event | Multiplier against base input |
|---|---|
| Cold input | 1x |
| Five-minute cache write | 1.25x |
| One-hour cache write | 2x |
| Cache read | 0.1x |
This makes one-off calls a poor fit: they pay for a write and may never read it. A repeated task with a large unchanged prefix can be a good fit, but only after you observe actual reads. The multiplier is not a promised percentage saving. It is an input to a workload-specific calculation.
Where The Hit Rate Comes From
The cache boundary should end after the longest prefix that is genuinely shared. Anthropic evaluates tools, the system prompt, and messages in that order up to the cache_control block. Put durable tool definitions, operating instructions, product material, or a fixed reference corpus before the boundary. Put the latest user request and other per-call data after it.
This is an architectural decision, not a prompt-writing trick. A date injected into the system prompt, a reordered tool list, or a changing retrieval block can make the prefix different. The right response is not to guess. Log the request shape, make one change, and compare cache_read_input_tokens across a representative sample.
For a multi-agent system, centralize the fixed brief and tool contract once, then let each worker append its own narrow task. That is compatible with the operational lesson in multi-agent orchestration: concurrency becomes useful when ownership and inputs are explicit.
The Five-Minute TTL Is Not A Bug, It Is The Operator Lever
The default cache duration is five minutes. A cache hit refreshes that window. Choose the one-hour duration only when the observed gap between useful requests is longer than five minutes and the repeated reads justify its higher creation price. There is no universal break-even count because request cadence, prefix size, and model pricing all matter.
Use a small worksheet rather than a slogan. For a sample of requests, record cold input tokens, cache creation tokens, cache read tokens, the time since the previous matching request, and the selected TTL. Then compare the effective input cost against the same sample without caching. The Messages API response provides the usage fields needed for that comparison.
An interactive workflow may have frequent reads that keep a five-minute entry alive. A scheduled job may need an hour-long entry or may simply be too infrequent to benefit. Treat duration as a tested configuration choice, not a default to maximize.
Five Patterns That Actually Work
- Stable product reference. Keep a versioned product guide after the system instructions and before
cache_control; append the customer question after it. - Fixed codebase brief. Cache a deliberately selected repository summary, not an uncontrolled dump. Regenerate the brief when the revision changes.
- Repeated review rubric. Put the rubric and fixed tool contract before the boundary; append the pull request or test evidence after it.
- Shared worker contract. Give each worker the same compact operating rules, then append a disjoint task. This pairs well with an explicit subagent and worktree plan.
- Replayable task payload. Store the stable part under a content hash so a changed input is visible in logs instead of silently eroding the hit rate.
Three Patterns That Burn The Cache
A changing instruction block. Move variable dates, account state, and user-specific values after the stable boundary whenever the task permits it.
Changing tool definitions. Tool definitions participate in the cacheable prefix. Version them deliberately rather than regenerating their descriptions on every call.
Unstable ordering. Keep tools, system instructions, and reference blocks in a deterministic order. If a retrieval result must change, isolate it after the cache boundary and measure the tradeoff.
What This Means For Your May Bill
Instrument before refactoring. Log cache_read_input_tokens, cache_creation_input_tokens, input_tokens, model, TTL, request identifier, and a non-sensitive prefix version. Segment by workflow, because a coding loop and a daily batch do not have the same reuse pattern.
Then make one bounded change: move the boundary, stabilize a tool schema, or change the duration. Compare an equivalent set of requests. If cached reads do not rise meaningfully, remove the complexity. This is the same discipline that separates a measured channel result from an SEO assumption in Bing-first traffic analysis.
Prompt caching is a useful pricing primitive, not a promise. Design the request around a stable boundary, record the response usage, and let those numbers decide whether the optimization stays.
Sources
Topics
More from the same beat.
303 Routes, 0 Red Gates: Static Export Still Needs a Preflight
A green build is not release clearance. The artefact needs its own route, metadata, link, and visual checks.
- Treat out/ as the release candidate.
GLM-5.2 Cleared the Six Hard Tasks I Use to Vet Any Cheap Model
A new open-weights model matched my flagship on objective hard tasks. The battery I run before trusting any cheap model in production did not change.
- A leaderboard rank is a reason to test a model, not a reason to trust it. I keep a fixed battery of objective hard tasks with execution-checked answers and run it on every cheap or open release bef…
GLM-5.2 Ships 753B Open Weights. My GTX 1660 Holds 6 GB.
The most powerful open-weight model of mid-June 2026 needs a cluster. A 4B model on a 6 GB card taught me what that headline leaves out.
- Open weights and a model you can run are two different claims. GLM-5.2 ships MIT weights at over 750 billion parameters, and none of that helps a 6 GB card.