Claude API Prompt Caching for Enterprise: Guide 2026
Anthropic's prompt caching cuts Claude API costs up to 90% and latency up to 85% on repeated context. Here is how caching actually works, what to cache, a worked cost example, and the pitfalls teams hit at scale.
In this article
Why this matters
Most production Claude applications send a large, unchanging block of context with every single request: the system prompt, retrieved documents, a product catalog, or tool definitions. Only the user's actual question changes. Without caching, you pay full input price for that entire block on every call, and the model has to re-read it each time, which also adds latency.
This compounds with scale. The cost of Claude itself keeps falling, but reprocessing identical context is pure waste that grows linearly with traffic. Caching turns that fixed context from a per-request expense into something you pay for roughly once per cache window.
If you are also looking at raw token pricing, caching stacks on top of recent rate cuts rather than replacing them. Claude API Pricing Just Dropped 40-50%: What This Means
How prompt caching actually works
Caching works by prefix matching. You insert a cache_control breakpoint at the end of the content you want cached, and Anthropic caches everything from the start of the prompt up to that point. On the next request, if the prefix is byte-for-byte identical, the API serves it from cache instead of reprocessing it.
- The first request that creates the cache costs slightly more than a normal request (cache writes are billed at roughly 1.25x the base input rate).
- Every later request that hits the cache pays only about 10% of the base input rate for those cached tokens.
- The cache has a 5-minute time-to-live that refreshes on every hit, so an actively used cache stays warm.
- You can opt into a 1-hour TTL via the API for workloads with longer gaps between requests.
Caching is automatic via prefix matching. There is no cache ID to capture and pass back yourself. You simply send the same prefix with a cache_control breakpoint, and the API resolves the hit for you. The response usage object reports cache_creation_input_tokens and cache_read_input_tokens so you can confirm hits and measure savings.
Implementation
Mark the stable prefix with a cache_control block. Everything before and including that block is cached; the variable user input goes after it.
{
"model": "claude-sonnet-4-5",
"system": [
{
"type": "text",
"text": "You are a support assistant. Here is the full product knowledge base: ...50KB of stable context...",
"cache_control": { "type": "ephemeral" }
}
],
"messages": [
{ "role": "user", "content": "How do I reset my password?" }
]
}There are practical limits to know up front. A cached prefix must clear a minimum length (1024 tokens for the larger models, 2048 for the smallest) or it will not cache. You also get a limited number of cache breakpoints per request, so cache the largest, most stable blocks rather than sprinkling breakpoints everywhere.
A worked cost example
Say each request carries 20,000 tokens of fixed context plus a 500-token question, and you serve 100,000 requests a month. Without caching you pay full input price on roughly 2.05 billion input tokens. With caching, you pay the full rate once to write the cache, then about 10% of the input rate on those 20,000 tokens for the other 99,999 requests.
The cached portion drops to roughly a tenth of its previous cost, so the fixed-context line of your bill falls by close to 90%. The variable question tokens are unaffected because they change every time. The bigger and more stable your context relative to the user input, the closer your total savings get to that 90% ceiling.
What to cache (and what not to)
- System prompts and core instructions that never change between requests.
- Large context: knowledge bases, product catalogs, API docs, long policy text.
- Tool and function-calling schemas, which are often large and completely static.
- Few-shot examples that guide formatting and tone.
- Unique user queries, which never repeat and cannot hit the cache.
- Rapidly changing data that expires before it is reused.
- Short prompts that fall below the minimum token threshold.
- Anything placed before a frequently changing field, since a single early difference breaks the whole prefix.
Pitfalls that quietly kill your hit rate
The most common mistake is a non-deterministic prefix. If you inject a timestamp, a request ID, a randomly ordered set of documents, or a per-user greeting before your cached block, the prefix changes every call and you never get a hit. Keep everything before the cache breakpoint identical, and push anything dynamic after it.
Watch your traffic pattern too. The default 5-minute TTL refreshes on each hit, so steady traffic stays warm cheaply, but bursty workloads with long quiet gaps will let the cache expire and pay the write cost repeatedly. For spiky or batch-style traffic, the 1-hour TTL or the Message Batches API may be the better tool. Caching reduces the cost of repeated context; batching reduces the cost of throughput on non-urgent jobs. They solve different problems and can be combined.
The takeaway
If your application repeatedly sends the same context, prompt caching is close to free money. Structure your prompt so the stable content sits in a fixed prefix, add one cache_control breakpoint, and confirm hits by watching cache_read_input_tokens in the response. Then decide between the 5-minute and 1-hour TTL based on how bursty your traffic is.
For teams running Claude at enterprise volume, the win is not a hidden feature flag. It is disciplined prompt structure plus monitoring of hit rates, so a high percentage of requests actually land on a warm cache. Get that right and the fixed-context portion of your bill drops by an order of magnitude.
Anthropic prompt caching docs: The authoritative reference for cache_control, TTLs, token minimums, and pricing multipliers. Read the documentation
Get the Claude playbook in your inbox.
One weekly email for Claude and Claude Code users. Real workflows, no hype. Subscribe and we send you The Claude Power-User Cheatsheet.
— ¶ —
Luke Thompson
Luke Thompson is the founder of The Operations Guide, LLC and editor of The Claude Insider. Based in Jonesborough, Tennessee, he has spent years building AI-augmented business systems and automation workflows for operators and teams. He began working with large language models in production well before the current wave of consumer AI tools, integrating them into client workflows, content pipelines, and operational infrastructure. At The Claude Insider, he writes about Claude with the specificity of someone who uses it daily as a professional tool — not as a reviewer or commentator, but as a builder. His coverage focuses on what actually works: prompt patterns, API integration strategies, agentic workflows, and the real-world tradeoffs that practitioners face. He is not affiliated with Anthropic, PBC.
Articles are researched and drafted with AI assistance, reviewed and edited by Luke Thompson.
Know where AI can pay off in your company.
Take the free two-minute AI Readiness Assessment. See your score, the two gaps holding you back, and the next move worth making.
