Anthropic prompt caching: how it works and how to raise your hit rate

Anthropic prompt caching reuses an identical Claude prompt prefix across requests. At November 2026 prices, a five-minute cache write costs 1.25 times the base input price, while reads cost as little as 0.025 times base input on Fable and Mythos 5.1 and 5.2. Your saving depends on the read price and the share of input tokens served from cache (Anthropic prompt caching docs).

What Anthropic caches

The cache stores a prefix: everything from the start of the prompt through a marked block. Anthropic processes that prefix in the order tools, system, then messages. If the prefix matches on a later request, the API can read it from the cache instead of processing those tokens at the normal input price.

You can mark up to four breakpoints in a prompt. For automatic caching, add one top-level cache_control field: the API places the breakpoint on the last cacheable block and moves it forward as the conversation grows. That automatic breakpoint occupies one of the four slots (Anthropic prompt caching docs).

Cacheable prefixes also have a minimum length: 512 tokens for Fable 5.2, Fable 5.1, Opus 5.5, Opus 5, Sonnet 5.5 and Haiku 5.5. The minimum is 1,024 tokens for Opus 4.8, Sonnet 5 and Sonnet 4.6, and 4,096 tokens for Opus 4.6 and Opus 4.5. A shorter prefix is processed normally without being cached (Anthropic docs, Anthropic cookbook).

November 2026 cache prices

Anthropic charges for cache writes and cache reads separately. A five-minute write costs 1.25 times the base input price, and a one-hour write costs twice the base input price. Most models charge 0.1 times base input for a cache read, but the newer models below have lower read multipliers.

These are November 2026 prices. Base input prices, write multipliers and read prices come from Anthropic's prompt caching docs and pricing page. For other providers, see our cache read price comparison.

Fable 5.2, Mythos 5.2, Fable 5.1 and Mythos 5.1 have a 0.025 times read multiplier. Opus 5.5 and Sonnet 5.5 use 0.05 times, and all other models use 0.1 times (Anthropic prompt caching docs). The Fable 5.1 cache read price cut reduced its read price from $1 to $0.25 per million tokens.

Haiku 5.5 has an extra prompt-length rule: requests over 100,000 input tokens pay higher prices. Cache reads and writes count toward that length (Anthropic pricing).

What a 90% hit rate saves

Take a Sonnet 5.5 workload that sends the same 100,000-token prefix across 10 requests. The first request writes a five-minute cache entry, the next nine read it before it expires, and every request uses the full prefix. Output tokens and other input tokens sit outside this calculation.

Without caching, the 1 million input tokens cost $2.00. With caching, the write costs $0.25 and the nine reads cost $0.09. The total is $0.34, which saves $1.66, or 83%, on those input tokens.

The hit rate is 90%: 900,000 of the 1 million input tokens are cache reads. The saving is lower because the first 100,000 tokens cost more to write than they would have cost at the base input price.

With a one-hour write, the write costs $0.40 and the reads still cost $0.09, for a total of $0.49. That is a $1.51 saving. Anthropic's pricing guidance says the five-minute cache pays off after one read, while the one-hour cache pays off after two reads (Anthropic pricing).

The same hit rate can produce a different saving on another model because read prices differ. Our cache read price comparison looks at those prices across providers.

Measured hit rates in production

In Requesty's April 2026 coding agent data, Claude Code had the highest measured hit rate: 91.9%. The metric is cached tokens divided by input tokens.

This gap is not a controlled comparison of the agents alone. Requesty's data note says hit rate depends on both agent architecture and provider, and the agents used different model mixes. Claude accounted for 99.5% of Claude Code spend and 59.0% of Zed spend in the same month (agent model share data). For more on the tools themselves, see our agentic coding tools comparison.

The production view by Claude model gives another comparison. From September 7 to November 9, 2026, Requesty's rankings reported these hit rates and cache savings:

Each row describes production traffic, so different requests and workloads sit behind the numbers. The Sonnet example above isolates one reused prefix; read its 83% saving separately from the production bill saving in this table.

How to raise your cache hit rate

1. 1
   Put stable content first

   Keep reusable content stable and put changing information later in the prompt. The Claude Code team has reported cache breaks from a detailed timestamp in a static system prompt, shuffled tool order and updated tool parameters. The team's fix is to pass changing information in messages on the next turn (Claude Code team's prompt caching notes).

2. 2
   Check the breakpoint and token count

   Put the breakpoint after the content you expect to reuse, then check that the prefix meets your model's minimum token count. Anthropic says the prompt was not cached if both cache_creation_input_tokens and cache_read_input_tokens are zero in the response (Anthropic prompt caching docs).

3. 3
   Match the lifetime to the workload

   Anthropic measures a cache entry's lifetime from the start of the request that writes or reads it. A four-minute stream can leave around one minute to reuse a five-minute entry. For parallel requests, wait until the first response starts before sending the rest, because the entry becomes available at that point (Anthropic prompt caching docs).

4. 4
   Find where the prefix changed

   Anthropic's opt-in cache diagnostics report the first point where a prefix diverged. Send a diagnostics object on every turn: set previous_message_id to null on the first turn and to the previous response ID on later turns. Diagnostics are available on the Claude API; Bedrock and Google Cloud do not support them (Anthropic cache diagnostics).

Anthropic also lists changes to tool_choice and adding or removing images anywhere in the prompt as changes that can invalidate a prefix. Changes to thinking parameters invalidate cached message prefixes, and you should keep JSON key order stable for tool_use (Anthropic prompt caching docs).

For Message Batches, cache hits are best effort because requests run concurrently and in any order. Anthropic says the one-hour cache helps; the Batch API also gives a 50% discount on input and output (Anthropic prompt caching docs).

Check Claude Code before changing your prompt

Start with /usage in Claude Code v2.1.251 or later. Its "Prompt cache (main)" line shows the hit ratio, miss count and whether the cache is warm; from v2.1.260, it also names the likely cause of the last miss (Claude Code prompt caching docs).

The working directory affects reuse. Claude Code's cache is effectively scoped to a machine and directory: sessions in different directories build different prefixes, while parallel sessions in the same directory can build matching prefixes and read each other's cache (Claude Code prompt caching docs).

Model switches are another place to look. The opusplan setting switches between Opus and Sonnet, so toggling plan mode starts a fresh cache. A skill or command that names a different model also reads the conversation history without cache hits for that turn (Claude Code prompt caching docs).

Unless you choose a lifetime, Claude Code requests the one-hour cache only for a Claude subscription within the plan's included usage. Over the plan limit, it drops the main conversation to five minutes. Set the main-conversation lifetime with promptCacheTtl or CLAUDE_CODE_PROMPT_CACHE_TTL (Claude Code prompt caching docs).

Choose where to add breakpoints

On the direct Claude API, start with a stable prefix and inspect the cache usage fields after the first write and subsequent requests. If the prefix should match but reads stay low, use cache diagnostics.

For automatic caching with the default five-minute lifetime, add this top-level field to the request body:

{
  "cache_control": {"type": "ephemeral"}
}

For a one-hour lifetime, add ttl to the same object (Anthropic prompt caching docs):

{
  "cache_control": {"type": "ephemeral", "ttl": "1h"}
}

To set an explicit breakpoint, mark a text block in the system array (Anthropic prompt caching docs):

{
  "system": [
    {
      "type": "text",
      "text": "Stable instructions and context",
      "cache_control": {"type": "ephemeral"}
    }
  ]
}

This is direct Claude API syntax, while Requesty's auto_cache flag adds breakpoints for you.

On Requesty's OpenAI-compatible API, set auto_cache to true inside the request's requesty field. The router adds cache breakpoints to the largest content blocks before forwarding requests to providers that need explicit breakpoints, including Anthropic. It works on /v1/chat/completions and /v1/responses (Requesty auto-caching docs).

The examples below send the same long system prompt twice. Repetition makes the prompt long enough to cache; in your application, replace it with the stable instructions or context you want to reuse.

for attempt in 1 2; do
  python3 -c '
import json
 
system_prompt = (
    "Answer questions about the codebase using the supplied context. "
    "Explain assumptions and cite relevant details from the request. "
) * 600
 
print(json.dumps({
    "model": "anthropic/claude-sonnet-5-5",
    "messages": [
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": "What should I check before changing an API?"},
    ],
    "requesty": {"auto_cache": True},
}))
' | curl -sS https://router.requesty.ai/v1/chat/completions \
    -H "Authorization: Bearer $REQUESTY_API_KEY" \
    -H "Content-Type: application/json" \
    --data-binary @-
  echo
done

import os
 
from openai import OpenAI
 
client = OpenAI(
    base_url="https://router.requesty.ai/v1",
    api_key=os.environ["REQUESTY_API_KEY"],
)
 
system_prompt = (
    "Answer questions about the codebase using the supplied context. "
    "Explain assumptions and cite relevant details from the request. "
) * 600
 
for _ in range(2):
    response = client.chat.completions.create(
        model="anthropic/claude-sonnet-5-5",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": "What should I check before changing an API?"},
        ],
        extra_body={"requesty": {"auto_cache": True}},
    )
    print(response.usage)

Requesty reports cache reads in usage.prompt_tokens_details.cached_tokens (Requesty manual caching docs). Compare the two responses: the first should show few or no cached tokens, while the second should show a cached_tokens value close to prompt_tokens if the prefix is reused.

In direct Claude API responses, usage.cache_creation_input_tokens reports tokens written to the cache, and usage.cache_read_input_tokens reports tokens read from it. Compare the first response with the second to check whether the prefix was reused. Calculate the hit rate as cache_read_input_tokens / (cache_read_input_tokens + cache_creation_input_tokens + input_tokens); this is the token-based equivalent of the cached-tokens-over-input-tokens metric used in Requesty's data (Anthropic prompt caching docs).

Run your own prompt twice, measure the cache reads and choose a lifetime that covers the interval between requests. Use the price table to estimate the saving; if manual breakpoints are a burden, turn on Requesty's auto_cache.