Anthropic Prompt Caching: Cut Claude API Costs by 90%

Updated November 2, 2026 — added direct answers on prompt caching costs and mechanics, sourced from Anthropic’s published pricing.

Last refreshed: November 2, 2026 (Pacific)

If you’re sending the same large block of context — a knowledge base, a style guide, a long system prompt, a reference document — with every Claude request, you’re paying full input token rate on every single call. Anthropic’s prompt caching collapses that to roughly 10% of the standard input rate for cache hits. For context blocks of 1,000+ tokens sent repeatedly, this is one of the most reliable cost levers available.

This is part of the Claude on a Budget series. For async workloads, see The Batch API: 50% Off for Non-Urgent Work. For token reduction before the API call, see The Cold-Start Problem: Second Brain and CLAUDE.md.

How the Cache Works

Prompt caching is prefix-based. Anthropic caches the exact token sequence up to your cache_control breakpoint. Any subsequent request that begins with that identical prefix hits the cache and pays cache read rate (~$0.20/M for Sonnet 5.5 vs. $2.00/M standard — a 90% reduction). The cache is maintained for approximately 5 minutes of inactivity, with extended TTL options for longer-lived contexts. Token minimums apply — Anthropic documents these per model, and recent generations have lowered them to 1,024 tokens.

The Pricing Reality

Model	Standard Input	Cache Write	Cache Read	Read Savings
Haiku 4.5	$1.00/M	$1.25/M	$0.10/M	90%
Sonnet 5.5	$2.00/M	$2.50/M	$0.20/M	90%
Opus 5.5	$4.00/M	$5.00/M	$0.20/M	95%

Cache writes cost slightly more than standard input (25% premium). The break-even is the second hit. Every cache read after that is 90% cheaper. For any context block read more than once, caching wins.

What is prompt caching and how much can it save?

Prompt caching stores the reusable prefix of your API prompt—such as system instructions, tool definitions, or background documentation—in Anthropic’s memory so subsequent calls do not re-process it at full input price. On cache hits, it saves up to 90% on input token costs (paying 0.1x the base input rate) while reducing time-to-first-token latency.

Consider a concrete before-and-after example of a production workload running 1,000 requests that share a consistent 10,000-token prompt context (10,000,000 total prompt input tokens) using Claude Haiku 4.5 (where standard input is $1.00 per million tokens):

Without caching:
All 1,000 requests are billed at standard input ($1.00 / MTok):
10.0 MTok × $1.00 / MTok = $10.00

With prompt caching (5-minute TTL rates):
• Cache-write price (Request 1): 10,000 tokens (0.01 MTok) written at the cache-write rate of $1.25 / MTok (1.25x base) = $0.0125
• Cache-read price (Requests 2–1,000): 9,990,000 tokens (9.99 MTok) read at the cache-read rate of $0.10 / MTok (0.1x base) = $0.9990
• Total prompt input cost: $0.0125 + $0.9990 = $1.0115 (approx. $1.01)
• Net savings: Cost drops from $10.00 to $1.01, saving $8.99 (89.9%) on prompt input tokens.

How does prompt caching reduce my Claude API costs?

Prompt caching reduces API costs by splitting each incoming request into two distinct segments: a stable prompt prefix and a dynamic suffix.

• Stable prompt prefix (cached): Contains the parts of your prompt that remain identical across calls—system instructions, persona rules, few-shot examples, and schema definitions marked with cache_control. Anthropic hashes this prefix and writes it to memory on the first request; every subsequent call within the time-to-live (5 minutes by default, refreshed on each hit) re-reads that prefix at the discounted cache-read rate ($0.10 / MTok on Haiku 4.5 or Sonnet 5.5).
• Dynamic suffix (not cached): Contains the parts that change on every query—the user’s specific question, dynamic conversation turns, or runtime variables placed after the cache breakpoint. Because this content changes, it is billed at standard input token rates.
• Why this split drives the savings: In multi-turn or agentic pipelines, system context and reference data frequently account for 80% to 95% of total input tokens. By isolating the static prefix behind a breakpoint, you pay the one-time 25% cache-write premium once, and then pay only 10% of the input cost on the vast majority of your prompt volume across all remaining requests.

The Implementation

import anthropic

client = anthropic.Anthropic()

# Large system prompt or knowledge base -- mark for caching
SYSTEM_CONTEXT = "Your 5,000-token knowledge base or style guide here..."

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": SYSTEM_CONTEXT,
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[
        {"role": "user", "content": "Your specific question or task here"}
    ]
)

# Check cache performance in usage stats
usage = response.usage
print(f"Input tokens: {usage.input_tokens}")
print(f"Cache creation tokens: {usage.cache_creation_input_tokens}")
print(f"Cache read tokens: {usage.cache_read_input_tokens}")

On the first call, you will see cache_creation_input_tokens populated — that is the write. On subsequent calls with the same prefix, cache_read_input_tokens shows what was served from cache at 10% cost.

What to Cache

Anything large, stable, and repeated qualifies. The highest-value candidates: long system prompts defining agent behavior or personas; reference documents such as product specs, legal terms, or knowledge bases; few-shot example sets (10+ examples add up fast); conversation history in multi-turn applications where you mark the stable history prefix for caching and leave only the new turn uncached. In agentic pipelines where Claude processes a document repeatedly across multiple analysis passes, cache the document body and vary only the instruction. You pay full rate once per document, cache rate on every subsequent pass.

The CLAUDE.md and Second Brain Connection

The cold-start reduction strategy covered in Cluster 1 works because you are reducing what gets sent, not how it gets priced. Prompt caching is the complement: for context that must be sent, cache it. Together, the disciplines compound — your CLAUDE.md file keeps context lean; prompt caching ensures whatever you do send repeatedly costs 90% less after the first hit.

Cache Design Principles

Place stable content at the front of your prompt. Place dynamic content at the end. The cache key is prefix-matched, so any change to content before the cache_control marker invalidates the cache. If your system prompt has a dynamic date or session ID embedded at the top, you are guaranteeing cache misses on every call. The correct structure: static knowledge base, then cache marker, then dynamic task-specific instruction. Never the reverse.

You can set up to 4 cache breakpoints in a single request for granular control. Most production implementations need only one or two — the system prompt cache and optionally a conversation history cache in long multi-turn sessions.

Operational Impact

Teams running Claude with consistent system prompts across many requests report effective input costs dropping to near-cache-read rates after the first request. For a content pipeline running 1,000 daily requests with a 5,000-token system prompt: uncached cost is $10/day on input alone at Sonnet 5.5 rates ($2/M). Cached cost after the first request: about $1/day. That is roughly $9/day saved on system prompt tokens alone — about $3,285/year from one implementation change that takes an afternoon to ship.

Next: Output Compression Discipline: Concentrated Slices vs Full Meals →