Prompt caching lets an LLM API reuse the work it already did on the start of a prompt, so when a new request begins with exactly the same content (a system prompt, tool definitions, a long document or the earlier conversation), that part costs less and the response starts sooner. The model still writes a new answer each time; only the input processing is reused.
Anthropic, OpenAI and Google all offer it, with different defaults, lifetimes and prices. This guide explains the shared mechanism, then how each provider handles it, based on their docs as of October 2026.
How does prompt caching work?
Every request to an LLM API sends the full input: instructions, tools, any documents and the conversation so far. In a chat or an agent loop, most of that is identical to the previous request, with only the newest message added at the end.
Prompt caching stores the processed form of that repeated beginning, called the prefix. When the next request starts with the same prefix, the provider skips reprocessing it. Two rules follow:
- The match must be exact. OpenAI's prompt caching guide says "Cache reuse requires the entire rendered prefix to match." Change one character early in the prompt and everything after it is processed again.
- Order matters. Stable content has to come first. OpenAI's advice: "Put stable developer instructions and shared reference material first."
Claude Code's docs explain the consequence clearly: "The match is exact, so a change anywhere in the prefix recomputes everything after it. There is no per-file or per-segment caching."
Prompt caching is not response caching. Nothing stops the model from giving a different answer to the same prompt; you save on reading the input, not on generating the output.
How does prompt caching work on Anthropic's API?
Anthropic's prompt caching docs describe two ways to turn it on:
- Automatic caching: "Add a single
cache_controlfield at the top level of your request." The API places the cache breakpoint on the last cacheable block and moves it forward as the conversation grows. - Explicit cache breakpoints: "Place
cache_controldirectly on individual content blocks for fine-grained control over exactly what gets cached." You can define up to 4 breakpoints.
The cached prefix follows a fixed order: "tools, system, and messages (in that order), up to and including the block designated with cache_control." Here is the automatic form from the docs:
curl https://api.anthropic.com/v1/messages \
-H "content-type: application/json" \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-d '{
"model": "claude-opus-5-5",
"max_tokens": 1024,
"cache_control": {"type": "ephemeral"},
"system": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.",
"messages": [
{"role": "user", "content": "Analyze the major themes in Pride and Prejudice."}
]
}'
Lifetime. "By default, the cache has a 5-minute lifetime. The cache is refreshed for no additional cost each time the cached content is used." A 1-hour lifetime is available with "ttl": "1h".
Pricing, as of October 2026. Per the same page, 5-minute cache writes cost 1.25 times the base input price, 1-hour writes cost 2 times, and cache reads cost 0.1 times, with lower read rates on some newer models listed in the page's footnote. Check Anthropic's pricing page for current per-model prices.
Minimum length. The minimum cacheable prompt is 512 tokens for current models such as Claude Opus 5.5, Sonnet 5.5 and Haiku 5.5, and higher for some older ones. Shorter prompts are processed without caching, "and no error is returned."
Measuring. Each response reports cache_creation_input_tokens, cache_read_input_tokens and input_tokens, which add up to the total input.
How does prompt caching work on OpenAI's API?
OpenAI's guide says "Prompt caching is enabled by default for supported OpenAI models." Reused tokens are billed at a reduced cached-input rate, "discounted up to 95%."
The details depend on the model generation:
- GPT-5.6 and later: "The minimum cacheable prompt length is 1,024 tokens for GPT-5.6 and later." These models also support explicit breakpoints. The
prompt_cache_options.ttlsetting sets a minimum lifetime, with30mas the default. As of October 2026, "cache writes cost 1.25× the standard, uncached input-token rate for the default 30-minute lifetime." In the Responses API you can choose a 12-hour minimum lifetime, with writes at 2.5 times ordinary input. Reads cost 0.1 times the input rate on most of these models, whichever lifetime you pick. - Earlier models: "Only implicit caching is supported." In-memory entries "typically remain active for around 5 to 10 minutes of inactivity, up to one hour," and an extended retention option can keep them for up to 24 hours. A stable
prompt_cache_keyhelps route similar requests to the same cache, though keys "do not pin requests to a machine or guarantee a cache hit."
You can see cache hits in usage.input_tokens_details.cached_tokens on each response.
How does caching work in the Gemini API?
Google offers two kinds. Per the Gemini caching docs, "Implicit caching is enabled by default for all Gemini 2.5 and newer models," and "We automatically pass on cost savings if your request hits caches." Implicit caching has no cost-saving guarantee: you benefit when a hit happens.
Minimum input sizes for caching vary by model, for example 4,096 tokens for Gemini 4 Argon and 2,048 for Gemini 2.5 Flash and 2.5 Pro. Cache hits appear in usage.total_cached_tokens.
Explicit caching works differently: you create a cache object holding the shared content, then reference it in later requests. The explicit context caching page says it carries a cost-saving guarantee, and "If not set, the TTL defaults to 1 hour." Cached tokens are "billed at a reduced rate when included in subsequent prompts," and storage is "billed based on the TTL duration of cached token count." Explicit caching uses the generateContent API; it is not supported in the Interactions API or for Gemini 4 Argon.
Google suggests caching where "a substantial initial context is referenced repeatedly by shorter requests," such as chatbots with long system instructions, repeated questions about large document sets, or "Frequent code repository analysis or bug fixing."
How do the providers compare?
| Anthropic | OpenAI | Google Gemini | |
|---|---|---|---|
| On by default | No, add cache_control |
Yes | Implicit: yes (2.5 and newer) |
| Explicit control | Up to 4 breakpoints | GPT-5.6 and later | Cache objects via generateContent |
| Default lifetime | 5 minutes, refreshed on use | 30-minute minimum on GPT-5.6+ | Explicit: 1 hour |
| Longer option | 1 hour | 12 hours on GPT-5.6+; up to 24 hours on earlier models | Set your own TTL |
| Write surcharge | Yes (1.25x or 2x) | Yes on GPT-5.6+ | Storage billed by TTL (explicit) |
| Usage field | cache_read_input_tokens |
cached_tokens |
total_cached_tokens |
All figures are from each provider's docs as of October 2026 and change often, so check the linked pages before you budget.
How do you structure prompts to get cache hits?
The same habits work on every provider:
- Put stable content first. Tool definitions, the system prompt, reference documents and few-shot examples go at the top. The user's question goes last.
- Keep the prefix byte-for-byte identical. Do not put a timestamp, request ID or user name in the system prompt. Keep tool order fixed.
- Batch similar requests close together. Google's tip: "Try to send requests with similar prefix in a short amount of time," before the cache expires.
- Clear the minimum. A 300-token prompt will not cache on most models. Caching pays off with long, reused context.
- Measure. Read the cached token fields on real traffic. If cache writes stay high turn after turn, something early in your prompt is changing.
Our guide to context engineering covers how to arrange long contexts more generally, and LLM tokens explained covers how input tokens are counted.
What breaks a prompt cache?
Anything that changes the prefix. Anthropic's docs give a precise rule for their hierarchy: "Changes at each level invalidate that level and all subsequent levels." Some examples from its table:
- "Modifying tool definitions (names, descriptions, parameters) invalidates the entire cache"
- Changing
tool_choiceor adding or removing images affects only the message blocks - Changing thinking parameters always invalidates the message blocks, and on some models the tool and system caches too
Switching models also misses the cache. Claude Code's docs note that "each model has its own cache," so the first request on a new model reprocesses everything.
How does Claude Code use prompt caching?
Coding agents resend the whole conversation on every turn, so caching does a lot of work there. Claude Code's prompt caching page says "Claude Code handles prompt caching for you," ordering each request as system prompt, project context, then conversation, so the stable parts stay cached.
Actions that change the early layers, such as switching models or adding tool definitions, cause one slower, uncached turn. See Claude Code prompt caching for the full list, the TTLs on subscriptions versus API keys, and how to check your hit rate with /usage.
Where does a prompt library fit?
A long, carefully written system prompt is exactly the kind of stable prefix that caches well, and it only stays stable if you reuse the same text. Kipt stores prompts and Agent Skills as Markdown in a private GitHub repo you own, so the exact version you deploy is one file you can copy from instead of retyping. For writing that prompt in the first place, see what is a system prompt.