I'm a regular claude.ai user, not a developer — does this article have anything to do with me?
The actual configuration doesn't apply to you directly — Prompt Caching is an API-level feature, and the caching logic in the claude.ai web app and mobile app is handled automatically by the platform. Regular users don't need to and can't manually mark cache blocks.
However, if your work involves evaluating or procuring a third-party tool that connects to the Claude API (a customer support system, an internal knowledge-base Q&A bot), understanding this concept helps you ask the right questions when discussing pricing with a vendor — things like "is your system correctly configured for Prompt Caching" or "have you recently checked for changes to the cache TTL." Questions like these often help you judge whether their cost management is solid, which indirectly affects what you actually end up paying for the service.
If my use case has a different conversation for every user, can I still use Prompt Caching?
Yes — the key is distinguishing what content genuinely varies by user from what's actually shared. Even if each user's specific question is different, most applications still have a large shared Block: the System Prompt (defining role and rules), a product knowledge base, tool definitions — these are typically identical across all users and can be cached. Only the user's current input and the accumulated history of that particular conversation are genuinely user-specific and can't share a cache.
The practical approach is placing the cacheable shared content early in your prompt structure (system prompt, knowledge base) and the user-specific content later (the user's message, conversation history), then only marking the shared block for caching. That way, even if every user asks something completely different, that large shared block still hits the cache, and the savings are usually still substantial.
Does Prompt Caching affect the quality or speed of Claude's answers?
No effect on quality — content served from a cache hit is semantically identical to what you'd get from reprocessing; this isn't a "downgrade" or "simplification" mechanism, it's simply skipping a redundant computation step. Speed is usually helped, if anything, since reading an already-computed cache is theoretically faster than processing a large Block of content from scratch — which is also why some technical writeups note that cache hit rate isn't just a cost metric, but an indirect indicator of latency and user experience too.
What genuinely needs attention is a cache miss: if content doesn't match (the cache expired, or something in the prompt changed) and the cache doesn't hit, that request gets processed as entirely new content — beyond the cost jumping to standard price or even the write premium, processing time is typically a bit longer than a cache hit too. But that's not "quality dropping" — it's just falling back to normal processing speed without the caching boost.
If I want to start checking whether my application is using Prompt Caching well, what should I actually do?
The most direct starting point is looking at the cache_read_input_tokens and cache_creation_input_tokens fields in your API responses — if your application consistently shows cache_creation_input_tokens (constantly writing) but rarely shows cache_read_input_tokens (almost no hits), that suggests something's wrong with your caching setup. Common causes are content that includes something that changes every time (a timestamp), or request intervals that regularly exceed your current TTL, causing the cache to keep expiring.
Once you've spotted the issue, check your System Prompt and tool definitions for unnecessary dynamic content and move it outside the cache Block; then evaluate your request interval pattern to judge whether the current 5-minute TTL is suitable, or whether you need the 1-hour extended cache instead. After going through this check, you'll usually see the proportion of cache_read_input_tokens rise noticeably — the most direct signal of whether your caching setup is correct.
If you're building a product on the Claude API and your System Prompt or reference documents aren't exactly short, Prompt Caching is probably the single highest-return optimization available — the setup cost is nearly zero, but the savings are real. There's one change to this mechanism that happened in 2026, though, that caught quite a few developers off guard and is worth calling out specifically.
Every time you call the Claude API, the system 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 knowledge-base document is long, and nearly identical across requests, you're effectively 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's prefix exactly matches what's cached, Claude can read the already-computed result directly, at roughly one-tenth the standard input price. The real-world numbers are intuitive: a support bot carrying an 8,000-Token system prompt and document set costs $24 per million messages just for the repeated fixed content at Sonnet's standard input rate; with caching enabled, that portion drops to $0.30 per million messages.
Setup is simple: add a `cache_control: {type: "ephemeral"}` marker to the content Block you want cached — typically the system prompt, a 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 with a matching prefix can then read at one-tenth the standard price. The break-even is fast — with a 5-minute TTL, a single hit already recovers the write premium, and every hit after that is pure savings.
Worth flagging: cacheable content has a minimum threshold, typically starting at 1,024 tokens (varying slightly by model). Content below that threshold produces no caching effect even if marked, wasting the effort of marking it.
This is the key thing this article wants to flag: Anthropic quietly changed the default cache TTL from 1 hour down to 5 minutes in early 2026. Multiple independent technical blogs documented the real impact — one developer recorded 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 requests that used to reliably hit the cache — originally spaced within a 1-hour window — massively invalidating under the new 5-minute TTL and getting forced back to full price (or even the write premium).
For applications originally designed around a 1-hour cache, this shift raised real costs 30-60% with zero warning. The most important takeaway here isn't the single fact that "TTL got shorter" — it's that the cache TTL itself is a parameter that can shift as Anthropic adjusts its policy, not a constant you configure once and apply forever. A cost estimate validated in the past is worth rechecking at a different point in time.
A simple decision rule: if your application has a high request frequency, with requests typically spaced far less than 5 minutes apart (real-time customer support chat, for instance), the standard 5-minute TTL is sufficient, since the cache almost never gets the chance to expire. If your use case has more spread-out request intervals, but still frequent enough to hit the cache at least five to seven times within an hour (multiple users sharing the same system prompt, with individual request intervals varying), the 1-hour extended cache is worthwhile long-term despite its higher write cost.
A simple rule of thumb: content that "has real substance and doesn't change often" is almost always a good caching candidate — system prompts, lengthy knowledge-base documents, and tool definitions are the typical examples. Conversely, "metadata-like content that changes every time" is a poor fit. The most common trap is developers habitually injecting a current timestamp into the system prompt — this makes every request's prefix content different, so the cache never hits, completely wiping out the optimization's benefit while still paying the write premium.
If your team spends a meaningful budget on the Claude API each month, checking whether prompt caching is enabled and whether the current TTL matches your actual usage pattern is usually the fastest way to see costs drop, without rewriting any prompt logic. And if your application's bill has risen recently without any obvious code changes, checking your cache hit rate first (observable through the API's `cache_read_input_tokens` and `cache_creation_input_tokens` response fields) is often much faster than combing through code line by line to find the root cause — exactly the trap described at the start of this article that caught a number of developers off guard.