What is Prompt Caching, and how is it different from a normal conversation?
Every time you talk to Claude, the API actually has to reprocess the entire conversation from the beginning — the System Prompt, tool definitions, all prior conversation history, and your new message — to produce an answer. If your system prompt or reference document is long, and nearly identical across requests, you're paying repeatedly for the same computation.
Prompt caching lets you mark the parts of your prompt that don't change, and Anthropic stores the processed result of that computation. As long as a subsequent request starts with content that exactly matches what's cached, Claude can read the already-computed result directly instead of reprocessing it — at roughly one-tenth the standard input price. Think of it like not having to photocopy a fifty-page manual for someone every single time; they've already seen it and remember it, so you just say "the same one as last time."
Why was Prompt Caching designed, and what problem does it solve?
A lot of real-world Claude use cases share a common trait: a large portion of every request is actually repeated content. A support bot carries the same product manual every time; a coding assistant carries the same CLAUDE.md project description every time; a RAG (retrieval-augmented generation) application carries the same batch of knowledge-base documents every time. Without a caching mechanism, this repeated content has to be fully recomputed each time, with the computational cost stacking up as the conversation grows longer.
Prompt caching solves exactly this "paying repeatedly" problem: as long as the same content is reused within the cache's validity window, it doesn't need to be recomputed at standard price every single time. This is also why the official documentation describes it as one of the most directly effective API cost optimizations available — you don't need to change how you converse with Claude, just mark which content is stable and unchanging, and you see the cost drop immediately.
How is Prompt Caching actually configured, and what numbers or thresholds should I watch for?
In the Anthropic API, you add a cache_control: {type: "ephemeral"} marker to the content Block you want cached, typically placed after your System Prompt, long document, or tool definitions. On the first request, that content gets written to cache at 1.25× the standard input price (5-minute TTL) or 2.0× (1-hour TTL, an extended caching option); any subsequent request within the validity window whose prefix exactly matches can then read from cache at roughly one-tenth the standard price, with no additional configuration needed. Cacheable content has a minimum threshold, typically starting at 1,024 tokens (varying slightly by model) — content below that threshold won't produce a caching effect even if marked.
One thing especially worth knowing: Anthropic quietly changed the default cache TTL from 1 hour to 5 minutes in early 2026. This shift caused quite a few applications originally designed around a 1-hour cache to see costs rise 30-60% without anyone realizing it, until developers carefully compared their bills and spotted the discrepancy. This is also why, once prompt caching is enabled, "how much time elapses between requests" becomes a cost variable worth genuinely calculating, not a detail you can casually ignore.
Understanding Prompt Caching — how does this actually help me use Claude better?
If you only chat with Claude through the claude.ai web app or mobile app, prompt caching configuration is already handled automatically by the platform — regular users don't need to and can't manually mark cache blocks. This concept mainly applies to the context of building applications through the API.
If you're a developer, understanding this mechanism can directly save you real money: checking whether your application has large, stable, repeated blocks of prompt content (system prompts, knowledge bases, tool definitions) and marking them as cacheable is typically one of the highest-return optimizations available, and Anthropic's own documentation recommends it as one of the first things to check when optimizing API costs. Also, if your application's bill suddenly rose recently without any obvious code changes, understanding the TTL shift from 1 hour to 5 minutes can help you quickly pinpoint the issue, rather than assuming it was a sudden traffic spike or the model getting more expensive.
Multiple independent technical blogs documented that Anthropic quietly changed the default cache TTL for Claude Code and the API from 1 hour down to 5 minutes in early 2026. One blog recorded the author opening their billing dashboard one morning to find a single day's cost had spiked to $13.86 — far above normal — and only traced it back afterward to the TTL change, which caused requests that used to reliably hit the cache to expire and get recomputed at full price simply because they were spaced more than 5 minutes apart. This underscores that the cache TTL itself is an important cost variable, not a setting you configure once and never think about again.
The advantage is roughly a 90% reduction in input cost on a cache hit, with especially large benefits for applications that repeatedly reuse large amounts of fixed content (system prompts, knowledge bases, tool definitions), and no impact on output quality. The drawback is that the first write costs 1.25 to 2 times more (though it typically pays for itself after just one or two hits), cache hits require an exact content match — any tiny difference invalidates it — and the TTL itself can shift as Anthropic adjusts its policy, requiring ongoing attention.