What is prompt caching? How Anthropic, OpenAI and Google discount repeated prompts

Prompt caching is a feature of AI APIs that reuses the computation for the beginning of a prompt that a provider has already processed, so repeated requests cost less and return faster. The answer you get is the same either way; only the bill and the delay change.

This explainer covers how it works, what each major provider documents as of October 2026 and how to get hits. Prices and minimums change often, so check the linked documentation before you plan a budget.

How prompt caching works

When you send a prompt, the model processes every token. If the first part is the same as a recent request, the provider can skip reprocessing it. OpenAI's documentation says the cache stores the model's key-value tensors for the prefix, not the tokens themselves, and that "cache reuse requires the entire rendered prefix to match."

That single rule shapes everything else: the cached part must be an exact prefix. Anthropic's documentation says hits need "100 percent identical prompt segments, including all text and images" up to the cache breakpoint. Change one early word and the cache misses.

Anthropic

Anthropic's documentation says caching covers the whole prompt in this order: tools, system, then messages, up to the block marked with cache_control. You can enable it two ways: a single top-level cache_control field for automatic caching, or explicit breakpoints on individual blocks, up to four.

• Lifetime. Default is 5 minutes, refreshed at no extra cost each time the content is used. A 1-hour option exists at extra cost.
• Multipliers on base input price. A 5-minute write costs 1.25x, a 1-hour write 2x and a read 0.1x. Claude Fable 5.1 and Mythos 5.1 reads cost 0.025x, and Opus 5.5 and Sonnet 5.5 reads cost 0.05x.
• Minimum length. 512 tokens for models including Opus 5.5, Sonnet 5.5 and Haiku 5.5; 1,024 for several earlier models; up to 4,096 for some older ones.

Anthropic's worked example: Opus 5.5 at a $4 per million token base input price means a 5-minute write costs $5 per million and a read $0.20 per million. If both cache fields in the usage data are 0, the prompt was not cached, and no error is returned for prompts that are too short.

OpenAI

OpenAI says caching is enabled by default for supported models. For GPT-5.6 and later, the minimum is 1,024 visible input tokens. Per its documentation:

• Cache reads cost 0.1x the ordinary input rate, or 0.05x on GPT-6.1 Sol.
• Cache writes cost 1.25x with the default 30-minute lifetime, or 2.5x with a 12-hour lifetime in the Responses API.
• You set the lifetime with prompt_cache_options.ttl to "30m" or "12h", and these are minimum lifetimes, not guaranteed deletion times.
• Cached tokens still count toward tokens-per-minute rate limits, and manual clearing is not available.

Earlier models use a different setting, prompt_cache_retention, with in-memory and 24-hour options.

Google

Google's documentation says implicit caching is on by default for Gemini 2.5 and newer models, and savings pass through automatically on a hit. Explicit caching is not available for Gemini 4 Argon and later. Minimums are 4,096 tokens for Gemini 4 Argon and 2,048 for Gemini 2.5 Flash and Pro. The page does not state a discount percentage.

For Gemini 4 and newer, Google notes that multi-turn and agent loops need to add at least 2,050 tokens to cache the full previous request; smaller additions reprocess the last 2,050 tokens at the standard rate.

How to get hits

• Stable first, variable last. Put instructions, tool definitions and reference documents at the start, and the changing user input at the end.
• Keep prefixes byte-identical. Do not put timestamps or random IDs near the top.
• Send requests close together. Short lifetimes mean sparse traffic may miss the cache.
• Watch the usage fields. Anthropic reports cache creation and read tokens, and Google reports cached tokens in usage data. Do not assume.
• Mind the write premium. A write costs more than a normal read of the same tokens, so a prefix used only once can cost more.

Why it matters for agents

Agents resend large context, such as tool definitions and conversation history, on every step. That is the ideal case for caching, and it is why price tables now carry cache columns. Our frontier API price tracker shows list prices, and the agent harness explainer shows where that repeated context comes from.

What caching does not do

It does not change outputs, improve quality or reduce output token costs. The providers say so directly. It also does not make your data public: cached content is processed under each provider's data handling terms, so check retention rules if you use Zero Data Retention.

A worked example

Suppose an agent sends a 20,000-token prefix of tool definitions and instructions on every step. On Anthropic's documented multipliers, the first request pays a 1.25x write premium on that prefix and later requests within five minutes pay 0.1x, or 0.05x on Opus 5.5. Over ten steps, the prefix costs roughly 2.2 times one normal read instead of ten, before counting the changing part of each prompt. The arithmetic is ours, based on the published multipliers, and real savings depend on your hit rate and the time between requests.

Our position

Caching is the easiest cost cut in most agent systems and the one most often misconfigured. Measure your hit rate for a week before you forecast savings.