Prompt Caching: Cached Input 10-40x Cheaper (Claude, OpenAI, Gemini)
What is prompt caching?
Prompt caching is an API mechanism where the provider stores the already processed beginning of a request (the prefix: tools, system prompt, documents) and reuses it when the next request starts with the same prefix. Those input tokens are billed at a discount (on Claude Opus 5.5 and Sonnet 5.5 a cache read costs 5% of the base input price), and processing gets faster. The cache only hits on an exact prefix match and expires after a limited time.
TL;DR
- -The cache stores the request prefix, not the model's answer. Any change before the cache breakpoint kills the hit, so static content goes first and variable content goes last.
- -On Claude Opus 5.5 and Sonnet 5.5 a cache read costs 5% of the input price, on Haiku 5.5 10%. A write costs 1.25x (5 minutes) or 2x (1 hour). In the author's test on Haiku 5.5, the second request with a 12.6K-token cache was 12 times cheaper than the first.
- -A 5-minute cache pays off from the second request within the TTL, a 1-hour cache from the third. A prompt sent only once costs 25% more with caching than without it.
- -OpenAI caches automatically from GPT-5.6 onward, but writes cost 1.25x (30 minutes) or 2.5x (12 hours). Gemini uses an implicit cache by default with no guaranteed hit. DeepSeek's disk cache is always on and works on a best-effort basis.
- -Check the cache through usage fields (cache_read_input_tokens, cached_tokens). Common causes of misses: a timestamp or ID at the start of the system prompt, changed tools, a prefix below the minimum, a pause longer than the TTL.
Prompt caching is an API mechanism where the provider stores the already processed beginning of a request and reuses it when the next request starts with the same prefix. Those input tokens cost less: on Claude Opus 5.5 and Sonnet 5.5 a cache read costs 5% of the base input price, on Haiku 5.5 10%. The cache only hits on an exact prefix match and expires after a limited time, from minutes to hours.
LLM API requests repeat a lot: the same system prompt, tool definitions, a reference document, a conversation history that grows every turn. Without a cache, every request pays full price for that prefix. In the author’s test on Haiku 5.5, the input of the tenth conversation turn was 57 times larger than the first, because the whole history is sent again each time. The context window article explains why.
This guide covers how prefix caching works at Anthropic, OpenAI, Google Gemini and DeepSeek, what it costs, from which request it pays off, and why the cache often misses without any error. Prices and parameters come from vendor documentation as of November 8, 2026. The author’s measurements were taken on November 7 and 8, 2026 through OpenRouter, not directly against vendor APIs.
What gets cached and why order matters
The request prefix, not the answer
The model processes input tokens in order and computes an intermediate state for each one (the KV cache). If the start of a new request matches the start of a previous one byte for byte, that state doesn’t need to be recomputed. The provider stores it and bills a reduced price for those tokens on a hit.
Only the input is cached. The answer is generated again: Anthropic, OpenAI and DeepSeek state this explicitly, and on DeepSeek temperature still produces different answers to identical requests. So caching doesn’t affect answer quality. It changes the price and processing time of the input.
The match has to be exact. Anthropic’s documentation says cache hits “require 100 percent identical prompt segments”, up to and including the block marked with cache_control. One changed line at the start of a request turns everything after it into a new prefix.
Order: tools → system → messages
Anthropic caches a request hierarchically: tools first, then system, then messages. A change at one level invalidates the cache for that level and every level after it. This gives the main rule for all vendors: static content first, variable content last.
| Part of the request | How often it changes | Where to put it |
|---|---|---|
| Tool definitions | Rarely, on release | At the very start |
| System prompt, instructions | Rarely | After tools |
| Reference documents, knowledge base | Sometimes | After system |
| Conversation history | Grows every turn | After documents |
| Current question, timestamp, request ID | Every request | At the very end |
Block order in a prompt is covered in how to write prompts. For how text turns into billable tokens, see tokens explained.
Prompt caching vs semantic cache
These are different things. A semantic cache stores finished answers and returns them for similar questions by comparing embeddings of the requests; the model isn’t called at all. Prompt caching runs on the provider side, and the answer is always new. Semantic caching and other ways to cut spend are covered in LLM cost optimization.
Prompt caching by vendor: summary table
Multipliers are relative to the model’s normal input token price. Sources: documentation from Anthropic, OpenAI, Google, DeepSeek and their price lists as of November 8, 2026.
| Vendor and model | How to enable | Read | Write | TTL | Minimum, tokens |
|---|---|---|---|---|---|
| Anthropic Opus 5.5, Sonnet 5.5 | cache_control at the top level or on blocks (up to 4) | 0.05x | 1.25x (5 min), 2x (1 h) | 5 min or 1 h, reads refresh it | 512 |
| Anthropic Haiku 5.5 | same | 0.1x | 1.25x / 2x | same | 512 |
| Anthropic Fable 5.1 | same | 0.025x | 1.25x / 2x | same | 512 |
| OpenAI GPT-5.6 | automatic; explicit via prompt_cache_breakpoint | 0.1x | 1.25x (30 min), 2.5x (12 h) | 30 min or 12 h | 1,024 |
| OpenAI GPT-6.1 Sol, Terra | same | 0.05x | same | same | 1,024 |
| Google Gemini 3.8 Flash | implicit by default; explicit via caches.create | 0.1x | implicit: no premium; explicit: storage fee | explicit 1 h by default; implicit not published | 4,096 (implicit) |
| DeepSeek V4.1 Flash | always on, disk cache | 0.02x | no premium | no fixed TTL | not documented |
OpenRouter’s own summary table lists different read ratios for OpenAI, Gemini and DeepSeek (for example, 0.25x or 0.5x for OpenAI). The table above uses the vendors’ primary price lists.
Prices in dollars per 1M tokens as of November 8, 2026:
| Model | Input | Write | Read |
|---|---|---|---|
| Claude Opus 5.5 | $4 | $5 (5 min) / $8 (1 h) | $0.20 |
| Claude Sonnet 5.5 | $2 | $2.50 / $4 | $0.10 |
| Claude Haiku 5.5 (prompts up to 100K) | $0.10 | $0.125 / $0.20 | $0.01 |
| Claude Fable 5.1 | $10 | $12.50 / $20 | $0.25 |
| GPT-6.1 Terra | $1.00 | $1.25 (30 min) | $0.05 |
| GPT-6.1 Sol | $2.00 | $2.50 (30 min) | $0.10 |
| Gemini 3.8 Flash (until 12/31/2026) | $0.75 | explicit storage $0.50 per 1M tokens per hour | $0.075 |
| DeepSeek V4.1 Flash (off-peak) | $0.15 | no premium | $0.003 |
Gemini 3.8 Flash prices are promotional: per Google’s price list, they double from January 1, 2027 ($1.50 / $0.15 / $1.00). DeepSeek charges twice the off-peak price during peak hours.
Anthropic prompt caching: cache_control
Without cache_control, the Claude API caches nothing. A full Claude API reference, including minimums for older models, is in the developer guide. Here the focus is on two things: price and why the cache misses.
Automatic mode and explicit breakpoints
There are two ways to turn caching on. Automatic: one cache_control field at the top level of the request. The API places the breakpoint on the last cacheable block and moves it as the conversation grows. Explicit: cache_control on specific blocks, up to 4 breakpoints per request. If you use both, the automatic breakpoint takes one of the 4 slots.
An example with an explicit breakpoint on a large system prompt:
import anthropic
client = anthropic.Anthropic()
spec = open("spec.md").read() # stable large context
def ask(question: str):
r = client.messages.create(
model="claude-sonnet-5-5",
max_tokens=512,
system=[{"type": "text", "text": spec,
"cache_control": {"type": "ephemeral"}}], # "ttl": "1h" for an hour
messages=[{"role": "user", "content": question}],
)
u = r.usage
print(u.cache_creation_input_tokens, u.cache_read_input_tokens, u.input_tokens)
ask("What are the security requirements?") # write
ask("What are the logging requirements?") # read
In the documentation example, automatic mode looks like client.messages.create(..., cache_control={"type": "ephemeral"}, ...) with no per-block markup.
Cache TTL: 5 minutes or 1 hour
By default the cache lives for 5 minutes, and a write costs 1.25x the input price. With "ttl": "1h" it lives for an hour, and a write costs 2x. In both cases a read refreshes the TTL at no cost. The TTL starts at the beginning of the request, so generation time counts toward it. If one request mixes both TTLs, the 1-hour entries must come before the 5-minute ones.
The 1-hour cache is for cases where pauses between requests to the same prefix exceed 5 minutes: an agent waits for the user, or a job runs on a schedule. It pays off from the third request, and over two requests it can cost more than no cache at all.
Reading usage
| Field | Meaning |
|---|---|
cache_creation_input_tokens | Tokens written to the cache (at the write rate) |
cache_read_input_tokens | Tokens read from the cache (at the read rate) |
input_tokens | Tokens after the last breakpoint, at the normal price |
cache_creation.ephemeral_5m_input_tokens, ephemeral_1h_input_tokens | Write breakdown by TTL |
Total input equals the sum of the first three fields. If both cache fields are zero, the cache wasn’t involved: either the prefix is below the minimum or cache_control never reached the API.
What invalidates the cache
Per the invalidation table in Anthropic’s documentation as of November 8, 2026:
| What changed | Tools cache | System cache | Messages cache |
|---|---|---|---|
| Tool definitions (names, descriptions, parameters) | invalidated | invalidated | invalidated |
Enabling web search or citations, the speed setting | kept | invalidated | invalidated |
tool_choice, adding or removing images | kept | kept | invalidated |
Thinking parameters, effort | model-dependent | model-dependent | invalidated |
In practice, keep the tool set unchanged between calls and don’t flip switches like web search mid-conversation.
One more limit: for each breakpoint, the API checks at most 20 positions back. In a long conversation with more than 20 blocks between the current breakpoint and the previous write, the hit is lost. The fix is a second explicit breakpoint closer to the start, or automatic mode, which moves the breakpoint itself.
OpenAI prompt caching: automatic mode and explicit breakpoints
From GPT-5.6 onward, OpenAI has two modes. Implicit is on by default: OpenAI places a breakpoint at the end of the last eligible message. Explicit caches only at breakpoints the developer sets. The minimum is 1,024 visible input tokens.
The main change from earlier models: writes are no longer free. Before GPT-5.6 there was no write premium. On GPT-5.6 and newer, a write costs 1.25x with a 30-minute TTL and 2.5x with a 12-hour TTL. A read costs 0.1x, or 0.05x on GPT-6.1 Sol and Terra. The TTL is set in prompt_cache_options, breakpoints go in the prompt_cache_breakpoint field, with up to 4 writes per request.
A Responses API request body with an explicit breakpoint:
{
"model": "gpt-6.1-terra",
"prompt_cache_options": {"mode": "explicit", "ttl": "30m"},
"input": [
{"role": "developer", "content": [{
"type": "input_text",
"text": "<stable instructions, 1,024+ tokens>",
"prompt_cache_breakpoint": {"mode": "explicit"}
}]},
{"role": "user", "content": "<current question>"}
]
}
In explicit mode with no breakpoints, nothing is cached. Results show up in usage.input_tokens_details: cached_tokens (read), cache_write_tokens (write) and cache_write_tokens_details with ttl_30m_tokens and ttl_12h_tokens. Per the documentation, normal input is input_tokens − cached_tokens − cache_write_tokens.
On GPT-5.6 and newer, prompt_cache_key isn’t needed for hits. It’s useful for tracking cache usage separately per customer or user. On older models the key affected request routing, and the TTL was set with prompt_cache_retention.
Two more details from OpenAI’s documentation: cached tokens count toward the TPM limit, and there’s no manual cache clearing.
Gemini and DeepSeek
Gemini context caching: implicit and explicit
Google calls the mechanism context caching. On Gemini 2.5 and newer the implicit cache is on by default with nothing to configure. Google recommends putting large shared content at the start of the request and sending similar requests close together in time. The minimum for Gemini 3.8 Flash is 4,096 tokens. Google doesn’t publish a TTL for the implicit cache; OpenRouter’s documentation says it averages 3-5 minutes.
The explicit cache is created separately with client.caches.create(...), and its name is then passed to generate_content via cached_content. It lives for 1 hour by default, and the TTL is set as a string like "300s". On top of reads, you pay for storage: $0.50 per 1M tokens per hour on Gemini 3.8 Flash until December 31, 2026. Explicit caching works only through generateContent on Gemini 3 and 2.5 models; it isn’t available in the Interactions API or on the Gemini 4 line and newer.
Explicit caching pays off with a steady stream of requests against one large document. For infrequent requests implicit is cheaper: there’s no storage fee, but no guaranteed hit either.
DeepSeek context caching on disk
DeepSeek’s context cache is on for all users, with no code changes. Hits show up in prompt_cache_hit_tokens and prompt_cache_miss_tokens. There’s no fixed TTL: the cache is cleared once it stops being used, usually within a few hours to a few days per the documentation. It’s described as best-effort, with no guarantee of a 100% hit rate. The documentation doesn’t state a minimum size.
There’s no write premium: a miss costs the same as normal input. On V4.1 Flash a read costs $0.003 per 1M tokens against $0.15 for a miss off-peak, which is 50 times cheaper.
Through OpenRouter
OpenRouter passes cache parameters to the provider and returns the result in usage.prompt_tokens_details: cached_tokens (read) and cache_write_tokens (write). For Claude, both top-level cache_control and explicit blocks work.
The cache lives at a specific provider, so a repeat request has to reach the same one. OpenRouter handles this with sticky routing. Per the documentation, it only turns on when the provider’s cache read is cheaper than normal input, a session stays sticky for 60 minutes without requests, and the session key is set with session_id. A manual provider.order disables sticky routing. Routing, ZDR and BYOK are covered in the OpenRouter guide.
Does the cache pay off: formula and thresholds
Notation: B is the normal price of the prefix, N is the number of requests to it, w is the write multiplier, r is the read multiplier. If all requests fall within the TTL (counting refreshes on read):
- without cache: N·B;
- with cache: w·B + (N − 1)·r·B;
- caching wins when N > (w − r) / (1 − r).
| Mode | w | r | Threshold N | Wins from request |
|---|---|---|---|---|
| Claude 5 min, Haiku 5.5 | 1.25 | 0.1 | 1.28 | 2nd |
| Claude 5 min, Opus 5.5 / Sonnet 5.5 | 1.25 | 0.05 | 1.26 | 2nd |
| Claude 1 hour, Haiku 5.5 | 2 | 0.1 | 2.11 | 3rd |
| Claude 1 hour, Opus 5.5 / Sonnet 5.5 | 2 | 0.05 | 2.05 | 3rd |
| OpenAI 30 min, GPT-6.1 Terra | 1.25 | 0.05 | 1.26 | 2nd |
| OpenAI 12 h, GPT-6.1 Terra | 2.5 | 0.05 | 2.58 | 3rd |
| DeepSeek | 1 | 0.02 | 1 | 2nd |
In dollars: Sonnet 5.5, a 50K-token prefix. Without caching it costs $0.10 per request. A 5-minute write costs $0.125, a read $0.005. Ten requests within the TTL: $1.00 without cache against $0.125 + 9 × $0.005 = $0.17 with it, about 83% saved. With a 1-hour write: $0.20 + 9 × $0.005 = $0.245.
It gets harder when pauses are longer than 5 minutes but shorter than an hour. The 5-minute cache is then rewritten every time and costs 1.25·N·B, 25% more than no cache. The 1-hour cache costs 2·B + (N − 1)·r·B. With r = 0.1 and two requests, that’s 2.1·B against 2.0·B without cache, so the 1-hour cache loses over two requests. Over three it already pays off: 2.2·B against 3.0·B.
There are two losing scenarios: a prompt sent once but with cache_control (25% more on Claude and GPT-5.6+), and pauses longer than the TTL. For Gemini explicit caching, add a storage fee proportional to the cache’s lifetime.
Measurements: Haiku 5.5, Sonnet 5.5 and three vendors via OpenRouter
These are the author’s measurements, all taken through OpenRouter; Claude requests were served by the Claude Platform on AWS provider. Response times include gateway and network latency. Costs come from the cost field in OpenRouter’s response.
Baseline: 12,635 tokens on Haiku 5.5
On November 7, 2026, two identical requests to Haiku 5.5 with a 12,635-token system prompt and cache_control: {type: "ephemeral"} cost $0.00158 (write) and $0.00013 (read of 12,619 tokens): the second was 12 times cheaper. The table and details are in the OpenRouter guide.
The charges match Anthropic’s prices: 12,635 × $0.10 per 1M = $0.00126, and with the 1.25 write multiplier that’s $0.00158; 12,619 × $0.01 per 1M = $0.00013. Sixteen tokens weren’t read from cache, probably the tail after the breakpoint (the user message and markup). Response time was 1.51 s against 1.41 s, which on 12K tokens is within noise.
5-minute TTL
November 8, 2026, Haiku 5.5, the same 12.6K-token system prompt:
| Time (UTC) | Step | cached | cache_write | Cost |
|---|---|---|---|---|
| 08:51:34 | write | 0 | 12,618 | $0.00158 |
| 08:55:36 | 4 min later | 12,618 | 0 | $0.00013 |
| 09:01:38 | 6 min after the previous request | 0 | 12,618 | $0.00158 |
After 4 minutes the cache is read. Six minutes after the last request it’s gone: the request writes the cache again and costs as much as the first one.
80K prefix: cost and time to first token
November 8, 2026, streaming, Haiku 5.5 (three write-read pairs) and Sonnet 5.5 (one write, four reads). TTFT is the time to the first token of the response.
| Model | Step | Input, tokens | TTFT, s | Cost |
|---|---|---|---|---|
| Haiku 5.5 | write (×3) | 80,802 | 2.47 / 2.78 / 1.71 | $0.0101 |
| Haiku 5.5 | read (×3) | 80,802, 80,786 from cache | 1.27 / 1.63 / 1.29 | $0.00081 |
| Sonnet 5.5 | write | 80,804 | 1.69 | $0.2020 |
| Sonnet 5.5 | read (×4) | 80,804, 80,788 from cache | 1.32 / 1.32 / 1.33 / 1.21 | $0.00815 |
At 80K, a read is 12.5 times cheaper than a write on Haiku 5.5 and 25 times cheaper on Sonnet 5.5. TTFT on reads is shorter, but the spread is wide: 1.3-1.6 s against 1.7-2.8 s on Haiku, about 1.3 s against 1.7 s on Sonnet’s single write. The main gain is cost. Times were measured through the gateway; direct API numbers will differ.
On OpenRouter, Sonnet 5.5 reasoning can’t be turned off: reasoning: {enabled: false} returns a 400 error with the message “Reasoning is mandatory for this endpoint and cannot be disabled”. So Sonnet’s read cost includes reasoning tokens. On Haiku 5.5, reasoning can be disabled.
Three vendors on one prefix
November 8, 2026, a prefix of about 18K tokens, no explicit cache parameters, requests sent back to back a few seconds apart:
| Model | Provider | Call | cached | cache_write | Cost |
|---|---|---|---|---|---|
| GPT-6.1 Terra | OpenAI | 1 | 0 | 18,234 | $0.02282 |
| GPT-6.1 Terra | OpenAI | 2 | 18,234 | 0 | $0.00094 |
| Gemini 3.8 Flash | 1 / 2 | 0 / 0 | 0 | $0.01336 each | |
| Gemini 3.8 Flash | new prefix, 1 / 2 / 3 | 0 / 0 / 12,261 | 0 | $0.01334 / $0.01336 / $0.00508 | |
| DeepSeek V4.1 Flash | not pinned | 1 / 2 | 0 / 0 | n/a | $0.000115 / $0.00349 |
| DeepSeek V4.1 Flash | DeepInfra (pinned) | 1 / 2 / 3 | 0 / 18,304 / 18,304 | n/a | $0.00257 / $0.0000843 / $0.0000843 |
What this shows for the three vendors:
- GPT-6.1 Terra caches automatically and bills the write at the higher rate: 18,234 × $1.25 per 1M ≈ $0.0228. A read is 24 times cheaper than the write.
- On Gemini 3.8 Flash, the implicit cache hit only on the third call, and only partially: 12,261 tokens out of 17,779. Hits aren’t guaranteed.
- Without a pinned provider, two identical requests to DeepSeek V4.1 Flash went to different providers (Relace and Wafer). There was no cache hit, and the prices differed 30-fold. With the provider pinned via
provider: {order: [...], allow_fallbacks: false}, reads were 30 times cheaper from the second call. These are DeepInfra’s prices, not DeepSeek’s price list.
Where caching helps most
Agents and coding agents
An agent loop sends the same tools and system prompt at every step while the history grows. This is the best case for caching: a large prefix, frequent requests, short pauses. Anthropic’s automatic mode moves the breakpoint along with the history, so each step reads almost all of the previous context from cache. If the agent waits for the user longer than 5 minutes, run the 1-hour option through the formula above. Agent loops are covered in the AI agents guide.
RAG with a large fixed context
If every request carries the same knowledge base of tens of thousands of tokens, caching cuts the cost of resending it by 90-95% on most Claude and OpenAI models (not counting the first write). Retrieved chunks and the user’s question go after it. When it’s cheaper to keep everything in context with caching and when to retrieve chunks is covered in Context Engineering vs RAG.
Chatbots and support
A long instruction set, company policy and FAQ are the same for every user. The user’s name, data and the current time go at the end, after the breakpoint. Otherwise every user gets their own prefix and the cache is never reused.
Parallel requests and batch
On Anthropic, a cache write becomes available only after the response to the first request starts. If you send 20 requests with the same prefix at once, each of them may write the cache from scratch. The fix: send one request, wait for its response to start, then launch the rest in parallel.
Anti-patterns and diagnostics
A timestamp at the start of the prompt: measured
A common mistake is a line with the current time, a request ID or a user name at the start of the system prompt. Test on November 8, 2026, Haiku 5.5, a 12.6K-token system prompt:
| Variant | Request | cached | cache_write | Cost |
|---|---|---|---|---|
Current time: … at the start of system | 1 / 2 / 3 | 0 / 0 / 0 | 12,638 each | $0.00158 each |
static block with cache_control, time in a separate block after it | 1 | 0 | 12,626 | $0.00158 |
| same | 2 / 3 | 12,626 | 0 | $0.00013 |
One changing line at the start disables caching completely, and every request pays for a write, which is 25% more than no cache at all. The fixed version:
{
"system": [
{"type": "text", "text": "<long static instructions>",
"cache_control": {"type": "ephemeral"}},
{"type": "text", "text": "Current time: 2026-11-08T08:51:45Z"}
]
}
Other causes of misses
- Tools are generated dynamically or in a different order. On Anthropic, changing tools invalidates the entire cache.
tool_choice, thinking parameters or the set of images change between calls.- The prefix is below the minimum: 512 tokens on Claude 5.5, 1,024 on OpenAI GPT-5.6+, 4,096 for Gemini 3.8 Flash’s implicit cache. There’s no error, and no cache either.
- A pause longer than the TTL.
- Parallel first requests without a warm-up.
- More than 20 blocks between the breakpoint and the previous write in a conversation.
- On DeepSeek and Gemini’s implicit cache, hits aren’t guaranteed by design.
- Through OpenRouter: requests go to different providers.
Checklist: is the cache working
- Log three numbers for every request: read from cache, written to cache, normal input.
- Compute the hit rate as the share of cache-read tokens in total input.
- Compare actual charges with the formula: if every request writes, the prefix is changing.
- Check that the first difference between two consecutive requests comes after the breakpoint.
- Put the hit rate on a dashboard and alert on drops; collecting such metrics is covered in LLM observability.
Fields to log by vendor:
| Vendor | Read | Write |
|---|---|---|
| Anthropic | cache_read_input_tokens | cache_creation_input_tokens |
| OpenAI | input_tokens_details.cached_tokens | input_tokens_details.cache_write_tokens |
| DeepSeek | prompt_cache_hit_tokens | none (miss: prompt_cache_miss_tokens) |
| OpenRouter | prompt_tokens_details.cached_tokens | prompt_tokens_details.cache_write_tokens |
On Gemini the field name depends on the API and SDK: the Interactions API documentation uses usage.total_cached_tokens, and in generateContent the counter comes in usage_metadata.
Summary
Prompt caching makes a resent prefix 10 to 50 times cheaper to read, depending on vendor and model (10x on Haiku 5.5, 20x on Opus 5.5 and Sonnet 5.5, 40x on Fable 5.1, 50x on DeepSeek V4.1 Flash). It only works under three conditions:
- Static content goes at the start of the request, and everything that changes goes after the breakpoint.
- The TTL matches the real pauses between requests: 5 minutes for a steady stream, an hour for agents that wait on the user.
- Hits are checked in usage on every request, not assumed.
Prefix caching is one of several ways to cut LLM spend. The others (choosing the model for the task, batch, semantic caching, trimming context) are covered in LLM cost optimization.