Prompt Caching in 2026: How to Cut LLM Input Costs

Prices and model names in this article were updated on 31 October 2026.

Prompt caching is one of the cheapest cost optimizations to adopt. It needs no model change and no new infrastructure. Often the only work is reordering content you already send.

For a long prompt, the provider keeps the computed state (the KV cache) of the opening section, called the prefix. The next request that starts with the same prefix skips that computation, and you pay a reduced rate for those tokens. Cached rates on current models, as of October 2026, are 10% of the input price at Anthropic (5% on Claude Opus 5.5 and Sonnet 5.5). They are 10% on GPT-6 Astra and on Gemini 3.8 Flash, and about 2–3% at DeepSeek.

How each provider implements it

All prices are per million tokens. Anthropic skips caching without an error when a prompt is below the minimum. Full per-model prices are in the October 2026 price snapshot.

Anthropic cache breakpoints

Anthropic offers two modes. Automatic caching needs one cache_control field at the top level of the request. The API then places the breakpoint on the last cacheable block and moves it forward as a conversation grows. Explicit breakpoints put cache_control on individual content blocks, up to 4 per request. The automatic breakpoint takes one of those 4 slots.

from anthropic import Anthropic

client = Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are a contract analyst. Identify key terms, obligations and risks."
        },
        {
            "type": "text",
            "text": f"<contract>\n{large_contract_text}\n</contract>",  # ~20,000 tokens
            "cache_control": {"type": "ephemeral"}  # add "ttl": "1h" for the 1-hour cache
        }
    ],
    messages=[
        {"role": "user", "content": "What are the termination clauses in this contract?"}
    ]
)

# Check cache status in the response
print(response.usage.cache_creation_input_tokens)  # tokens written to the cache
print(response.usage.cache_read_input_tokens)      # tokens read from the cache
print(response.usage.input_tokens)                 # uncached tokens after the last breakpoint

One breakpoint after the contract caches everything before it, instructions included. A separate breakpoint after the short instruction block would add nothing, because that prefix is under the 512-token minimum.

Cache pricing on Claude:

• Cache write: 1.25x the input price for the 5-minute cache, 2x for the 1-hour cache
• Cache read: 0.1x the input price, 0.05x on Opus 5.5 and Sonnet 5.5, 0.025x on Fable 5.1 and Mythos 5.1
• Lifetime: 5 minutes, measured from the start of the request, and refreshed at no cost on every hit

Take a 20,000-token contract queried 20 times on Claude Opus 5.5 ($4 input, $5 cache write, $0.20 cache read):

• Without caching: 20,000 × 20 = 400,000 tokens × $4/M = $1.60
• 5-minute cache: 20,000 × $5/M = $0.10 to write, then 20,000 × 19 × $0.20/M = $0.076 to read
• Total with caching: $0.176 against $1.60, an 89% saving

The questions must arrive less than 5 minutes apart for this to hold. If they don't, the 1-hour cache costs $8 per million to write: $0.16 + $0.076 = $0.236, still 85% below the uncached cost.

OpenAI caches by default and bills writes on new models

OpenAI caches automatically. Its guide says prompt caching "is enabled by default for supported OpenAI models". The minimum is 1,024 tokens on GPT-5.6 and later. Two things changed from GPT-5.6 onward. First, cache writes now cost 1.25x the uncached input rate for the default 30-minute lifetime and 2.5x for the 12-hour lifetime. Earlier models have no separate write charge. Second, prompt_cache_options.ttl sets the lifetime: "30m" by default, or "12h" in the Responses API. Earlier models use prompt_cache_retention instead. Its in-memory setting typically keeps entries for 5 to 10 minutes of inactivity, up to an hour. Its 24h setting can keep them up to 24 hours.

from openai import OpenAI

client = OpenAI()

# Same prefix on every call: the first call writes the cache, later calls read it
response = client.responses.create(
    model="gpt-6-astra",
    input=[
        {"role": "system", "content": large_system_prompt},  # static, cached
        {"role": "user", "content": specific_question}       # changes every call
    ]
)

# Cached tokens billed at the cached rate; writes are reported separately
print(response.usage.input_tokens_details.cached_tokens)
print(response.usage.input_tokens_details.cache_write_tokens)

GPT-6 Astra costs $10 per million input tokens, $1 for cached input and $12.50 for a cache write. OpenAI's guide says the cached discount reaches up to 95% depending on the model.

Gemini implicit and explicit caching

Gemini caches implicitly by default on Gemini 2.5 and newer models, and Google passes the saving on when a request hits. You can also create an explicit cache on Gemini 3 and 2.5 models. Gemini 4 Argon and later models support only implicit caching. The current Python SDK is google-genai:

from google import genai
from google.genai import types

client = genai.Client()
model = "models/gemini-3.8-flash"

# Create an explicit cache (TTL defaults to 1 hour if not set)
cache = client.caches.create(
    model=model,
    config=types.CreateCachedContentConfig(
        display_name="product_catalog",
        system_instruction="You answer questions about the product catalogue.",
        contents=[large_product_catalog_text],
        ttl="3600s",
    ),
)

# Use the cache in later requests
response = client.models.generate_content(
    model=model,
    contents="Which products are in the enterprise tier?",
    config=types.GenerateContentConfig(cached_content=cache.name),
)
print(response.usage_metadata)

An explicit cache bills storage for every hour it lives. On Gemini 3.8 Flash that is $0.50 per million tokens per hour, rising to $1.00 from 1 January 2027. Each cached read saves $0.75 − $0.075 = $0.675 per million tokens. The cache therefore pays for itself at 0.5 ÷ 0.675 ≈ 0.74 reads per hour, so about one hit an hour. After the January price change the ratio stays the same ($1.00 ÷ $1.35). On Gemini 3.1 Pro Preview storage costs $4.50 per million tokens per hour and a read saves $2.00 − $0.20 = $1.80. There the cache needs at least 2.5 hits an hour.

Static content must come first

Caches are prefix-based. The provider matches the prompt from its first token up to the cache point. Suppose dynamic content (user name, timestamp, request ID) comes before static content (system prompt, reference documents, examples). The prefix then differs on every request and nothing is reused.

Wrong order (cache never hits):

[Dynamic: user name, timestamp]
[Static: large system prompt]
[Dynamic: user message]

Correct order (cache hits on static content):

[Static: system prompt]          ← cache_control breakpoint here
[Static: reference document]     ← cache_control breakpoint here
[Dynamic: conversation history]
[Dynamic: user message]

The wrong order is worse than no caching where writes are billed. Take a support bot on Claude Sonnet 5.5 ($2 input, $2.50 cache write, $0.10 cache read). Each request carries a 50-token header with the user name and time, a 4,000-token system prompt and a 150-token user message. The bot handles 1M requests a month.

The last row leaves out occasional writes when the cache expires. At 1M requests a month a request arrives every few seconds, so the 5-minute cache rarely goes cold.

Structuring prompts for cache hits

A cache-friendly prompt for Anthropic looks like this:

def build_cached_request(
    static_instructions: str,
    reference_docs: list[str],
    conversation_history: list[dict],
    user_message: str
) -> tuple[list[dict], list[dict]]:

    # Layer 1: core instructions (rarely change)
    system = [{"type": "text", "text": static_instructions}]

    # Layer 2: reference documents (change per session, not per turn)
    for doc in reference_docs:
        system.append({"type": "text", "text": doc})

    # One breakpoint at the end of the static part caches everything before it
    system[-1]["cache_control"] = {"type": "ephemeral"}

    # Dynamic content goes in messages, after the cached prefix
    messages = conversation_history + [
        {"role": "user", "content": user_message}
    ]

    return system, messages

Anthropic allows up to 4 breakpoints per request. Use more than one when parts of the prefix update at different rates, for example fixed instructions and documents swapped per session. Each breakpoint must sit after at least the model's minimum token count to have any effect.

When caching pays off most

Multi-turn conversations with large system prompts

Every turn is a new API call that re-sends the system prompt. A 3,000-token system prompt over a 15-turn conversation adds 45,000 input tokens. Caching bills that prompt at the cached rate on turns 2 to 15. The rate is 10% of the input price at most vendors and 5% on Claude Opus 5.5 and Sonnet 5.5.

Document Q&A

Each question re-sends the whole document. Cache the document, pay the write once per session, and pay the cached rate on every later question.

RAG pipelines with stable context

Retrieval may return the same chunks for a run of related queries. Put those chunks before the question so they form a reusable prefix.

High-volume classification with shared instructions

Take 100,000 items classified with the same instructions and few-shot examples. The instructions are billed at the write rate only when the cache is written, and at the cached rate the rest of the time. Anthropic's batch discount also stacks with caching; see the batch API comparison.

Coding agents are a large case of the same pattern. The Claude Code cost guide covers which actions break its cache.

Monitoring cache performance

Log cache figures on every call. Anthropic's input_tokens usage field counts only the tokens after the last breakpoint. The total is cache_read_input_tokens + cache_creation_input_tokens + input_tokens.

def log_cache_stats(usage, read_mult=0.1, write_mult=1.25):
    """read_mult: 0.05 on Opus 5.5 and Sonnet 5.5; write_mult: 2.0 for the 1-hour cache."""
    fresh = usage.input_tokens
    read = usage.cache_read_input_tokens or 0
    written = usage.cache_creation_input_tokens or 0
    total = fresh + read + written

    hit_rate = read / total if total else 0.0

    # Effective input cost relative to sending everything uncached
    effective = fresh + written * write_mult + read * read_mult
    cost_ratio = effective / total if total else 1.0

    print(f"Cache hit rate: {hit_rate:.1%}")
    print(f"Effective input cost: {cost_ratio:.2f}x of uncached")

If the hit rate is low on a workload where every request shares a long prefix, the prompt structure is the first suspect. Look for dynamic content placed ahead of the static part. The LLM cost audit lists the other common causes.

What to do next

• Find your longest repeated prefix (system prompt, tools, documents) and move everything dynamic after it.
• Check the prefix is above the vendor minimum: 512 tokens on current Claude models, 1,024 on GPT-5.6 and later, 4,096 on current Gemini models.
• Log cache reads and writes per feature for a week and compute the hit rate.
• If you use explicit Gemini caches, compare hits per hour with the storage break-even above.
• We can run this check on a live pipeline as part of a cost audit.

Sources

• Anthropic: prompt caching
• Claude pricing (platform.claude.com)
• OpenAI: prompt caching guide
• OpenAI GPT-6 Astra model page
• Gemini API: context caching
• Gemini API: context caching with generateContent
• Gemini API pricing
• DeepSeek API pricing
• Anthropic Message Batches
• Claude Code: prompt caching