Prompt Caching Cuts Claude API Bills by 90 Percent

A production deployment documented by Iron Mind cut its Claude API input token costs by roughly 90% after switching on prompt caching. That number is real, but it applies to a specific kind of workload: one with large, repeated context and a high ratio of cached-to-fresh tokens. For most teams running Claude API prompt caching cost reduction strategies, the actual savings land somewhere between 40% and 70%, depending on how the application is built.

This gap between headline and reality isn't a marketing problem. It's a structural fact about how caching works. Understanding it is the difference between rolling out caching and getting a rounding error, or rolling it out and genuinely reshaping your unit economics.

#The 90% Claim: What Actually Gets Cached and Why Numbers Vary

Prompt caching stores the key-value cache state generated when Claude processes input tokens. According to Anthropic's Claude Platform blog, this lets the model retrieve that stored computation instead of reprocessing an identical prompt prefix from scratch. The prefix has to match exactly, which matters more than it sounds.

The 90% figure represents input token cost reduction, not total bill reduction. If your application sends a 10,000-token system prompt with tool definitions on every call, and only 200 tokens of actual user query change each time, caching that fixed prefix removes almost all the reprocessing cost on the static part. Output tokens are never cached, and they're billed at full price regardless.

So the real math depends on your ratio of static context to dynamic content. A customer support bot with a long policy document as context, answering short user questions, sits near the ideal case. A one-off summarization tool with a unique document every call sits near the worst case, because there's nothing to reuse.

According to Anthropic's documentation, cache control blocks can be attached to system prompts and tool definitions to enable this automatically, without a manual caching layer. That low implementation cost is part of why the technique spread so fast through agent-heavy codebases.

#Beyond the Headline: Real-World Savings Across Workload Types

Different workloads see wildly different results from the same feature. It helps to separate them before promising a number to your finance team.

#Implementation Complexity: When Caching Adds Technical Debt

Turning on caching is a small code change. Running it well in production is a different exercise.

The main technical requirement is ordering. Cached content has to sit at the start of the prompt, and it has to be byte-for-byte identical across calls, or the cache misses entirely. That means:

• System prompts and tool definitions go first, marked with a cache_control block
• Static reference material, few-shot examples, or long documents come next, in a fixed order
• User-specific and turn-specific content goes last, since it changes every call

import anthropic

client = anthropic.Anthropic(api_key="API_KEY")

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are a support agent for Example Corp. Follow the policy manual below.",
        },
        {
            "type": "text",
            "text": "<full policy manual text, thousands of tokens>",
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[
        {"role": "user", "content": "Can I return an item after 45 days?"}
    ],
)

The cache_control block goes on the last piece of content you want cached, not on every block. Anthropic's documentation confirms tool definitions are cached automatically once a cache_control marker appears in the system prompt, so you don't need a separate flag for tools.

The debt shows up later. Once a team caches a system prompt, that prompt becomes expensive to change carelessly. Editing a single line invalidates the entire cached block, and every downstream call pays full price until a new cache populates. Teams that iterate on prompts frequently, which is most teams in the first few months of a feature, can accidentally undo their own savings by shipping small wording tweaks too often.

#The Cache Hit Problem: Why Savings Run Lower Than Advertised

A cache is only useful if it gets hit. This is the part of Claude API prompt caching cost reduction that vendor blog posts tend to skip.

According to Anthropic's docs, cached prefixes support two time-to-live windows: five minutes and one hour. If your traffic pattern has gaps longer than the TTL, the cache expires before the next request arrives, and you pay full processing cost again plus a small write premium for repopulating it.

This creates a real trade-off:

This shows which cache duration fits which traffic pattern, not which one is cheaper in isolation.

A low-traffic internal tool that gets a handful of requests per hour may see almost no cache hits on the five-minute tier, because gaps between calls routinely exceed five minutes. Switching to the one-hour TTL, where available, or batching requests closer together, fixes this. But if nobody is watching hit rate, the team just assumes caching "isn't working for us" and rips it out.

The fix is measurement, not intuition. Every response includes token usage fields showing cache read and cache creation counts. Log those, and calculate a rolling hit rate:

Cache hit rate = cached_input_tokens / (cached_input_tokens + input_tokens)

If that number sits below 60-70% for a workload you expected to benefit, the problem is almost always traffic pattern or prompt instability, not the caching feature itself.

#Combining Caching with Model Routing and Batch API for Maximum ROI

Caching alone is not the ceiling. According to a guide from PE Collective, the largest total savings come from stacking caching with model routing and the Batch API rather than treating them as separate decisions.

One report from ClaudeDevs on X described combining prompt caching with effort calibration, meaning explicitly setting the model's reasoning effort to medium and constraining output length, as producing measurable savings on top of caching alone. In SWE-bench Verified testing referenced in that same post, the combination of caching, effort tuning, and removing prompt anti-patterns brought cost down by roughly 55%. A related analysis from ExplainX put total savings from caching plus effort calibration and anti-pattern removal at 52-73%.

The practical order of operations for a team starting from zero:

• Add cache_control blocks to system prompts and tool definitions first, since it's the lowest-effort change
• Route simple sub-tasks to a smaller model instead of running everything through the top-tier model
• Move anything non-urgent to the Batch API
• Tune effort settings and output length constraints last, once the bigger structural savings are in place

#Cache Invalidation Challenges: Managing Stale Data in Production

The other failure mode is caching content that shouldn't be cached, or caching it for too long. If a system prompt references dates, prices, or policy details that change, a stale cache serves outdated information at a discount, which is not a discount worth having.

A few guardrails worth building in from day one:

• Version your cached prompt blocks, so a deploy that changes the policy text also changes a version identifier, forcing a fresh cache
• Never cache content that includes per-user secrets, session tokens, or anything that shouldn't be reused across a different user's request
• Treat the 5-minute and 1-hour TTLs as expiration policies, not deletion guarantees; assume any cached block might silently vanish and design for that
• Keep genuinely dynamic content, like today's date or a live inventory count, outside the cached prefix entirely

None of this is exotic. It's the same discipline teams already apply to database caching or CDN invalidation, just applied to a newer surface.

#Measuring Success: Metrics That Matter Beyond Cost

A dollar figure on the monthly invoice is the lagging indicator. Teams that get durable results track leading indicators instead:

• Cache hit rate per endpoint, tracked over time, not as a one-time snapshot
• Latency on cache hits versus misses. According to Iron Mind's production write-up, latency dropped by up to 80% on cached prefixes, which often matters as much to users as the cost line does
• Token volume by category (cached input, fresh input, output) broken out per feature, so a single noisy endpoint doesn't hide a well-optimized one
• Prompt change frequency, since every edit to a cached block resets the clock on savings

Tracking these turns caching from a one-time optimization project into an ongoing part of how the team ships prompt changes.

#Takeaways

Prompt caching is one of the highest-leverage, lowest-effort levers available for LLM token optimization techniques right now, but the 90% figure is a ceiling, not a baseline. Match expectations to workload type before promising a number internally.

• Cache system prompts, tool definitions, and large static context blocks; leave user-specific content out of the cached prefix
• Pick the TTL that matches your actual traffic gaps, and measure hit rate rather than assuming it's working
• Stack caching with model routing and the Batch API for the largest realistic reduction in Anthropic API cost management
• Version cached prompts so deploys invalidate stale content on purpose, not by accident
• Track latency and hit rate alongside spend, since those numbers explain why the bill moved

Done properly, this is one of the few optimizations that reduces AI API spending without quality loss, because the model output doesn't change at all. Only the bill does.