Prompt Caching Explained: The Cost Math for Claude and OpenAI

Prompt caching lets the provider keep the processed start of a prompt for a few minutes, so the next request that begins with exactly the same text pays a fraction of the input price for that part. On Claude Sonnet 5.5 a cache hit costs $0.10 per million tokens against $2 for fresh input. That is 5%.

If every request you send starts with the same long system prompt, that discount applies to most of your input. In the worked example below it takes a support bot from $4,104 a month to $719. If your prompts are short or never repeat, it does nothing, and on Claude it can even cost a little more.

How prompt caching works

A model reads your prompt from the first token to the last. Caching saves the work done on the first part, the prefix, and reuses it when a later request starts with the same tokens. The match has to be exact from the very first token: change one character anywhere before the breakpoint and the whole cached prefix is a miss.

So order matters. Put what never changes first (tool definitions, instructions, reference documents, examples) and what changes last (the user’s message). Anthropic’s prompt caching docs (checked 2026-11-04) spell out the order the prefix is built in: tools, then system, then messages. A change at one level invalidates that level and everything after it.

The cache also expires. On Claude the default lifetime is 5 minutes, refreshed for free every time the prefix is read. A prompt that gets a request every minute stays warm all day; one that gets a request every ten minutes is written fresh every time.

What prompt caching costs on Claude and OpenAI

Anthropic charges for writing to the cache and gives a deep discount for reading it. A write with the 5-minute lifetime costs 1.25 times the normal input price, and a 1-hour write costs 2 times. A hit costs 0.1 times on most models, but 0.05 times on Opus 5.5 and Sonnet 5.5 and 0.025 times on Fable 5.1. In dollars per million tokens, Sonnet 5.5 is $2 input, $2.50 for a 5-minute write, $4 for a 1-hour write and $0.10 for a hit.

OpenAI works differently. Its prompt caching guide (2026-11) says caching is automatic for prompts of 1,024 tokens or more, and writing to the cache costs nothing extra: a miss is billed as normal input. On OpenAI’s pricing page (checked 2026-10-24), GPT-6.1 Sol’s cached input is $0.10 per million tokens against $2 for fresh input, the same 5% as Sonnet 5.5.

A worked example: a support bot with a long system prompt

Say an online furniture store runs a support assistant. Every request starts with a 20,000-token system prompt: return policy, delivery rules, assembly FAQs for its best-selling products and a tone guide. After that comes about 800 tokens of customer message and order details, and the assistant writes a 400-token reply. The store handles 3,000 requests a day.

Traffic like that keeps a 5-minute cache warm most of the day, but nights are quiet. As a round assumption, say the cache goes cold and is written again 24 times a day, once an hour on average. More cold starts raise the cached figure. You can count your own system prompt with the Token Counter to get the prefix size right.

On Sonnet 5.5 the bill falls 82%. Haiku 4.5 saves the least, 78%, because its hit discount is the standard 0.1 times rather than 0.05. Fable 5.1 saves the most, 85%, thanks to its 0.025 times hit price, and it is still the most expensive line on the table by a wide margin.

Sonnet 5.5 and GPT-6.1 Sol cost the same uncached, because their standard prices are the same. With caching, Sol comes out about $7 cheaper. That gap is the write premium: OpenAI doesn’t charge one, Anthropic does. At 24 writes a day it barely matters; at 2,000 it would.

When caching costs more than it saves

On Claude, a write costs more than sending the prefix uncached. Caching only pays when the same prefix is read again before it expires. The chart shows what a prefix costs across a run of requests with caching, as a share of sending it uncached each time, on Sonnet 5.5.

A prefix sent once costs 125% of the uncached price. After 2 requests the 5-minute cache is already cheaper (65%), and by 20 requests you pay 11%. The 1-hour cache starts at double the price and is still slightly over at two requests (102.5%), so it needs three. Pay for the hour only when requests are spaced more than 5 minutes apart but less than an hour.

The trap is a low-traffic tool that writes the cache on every request because nobody calls it twice within 5 minutes. On Claude that is a 25% surcharge on the prefix for nothing. On OpenAI a miss costs the normal price, so caching there has no downside.

How to turn on prompt caching in the Claude API

For a bot like this one, mark the end of the part that never changes. Put cache_control on the system prompt block, not on the customer’s message, because a cache entry is only written where you put the breakpoint:

{
  "model": "claude-sonnet-5-5",
  "system": [
    {
      "type": "text",
      "text": "…your 20,000-token instructions…",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "Where is my order?" }]
}

• Automatic caching is a single top-level cache_control that puts the breakpoint on the last block and moves it forward as a conversation grows. That suits multi-turn chats. In a one-shot bot the last block is the customer’s message, so it writes the cache on every request and never reads it. You can combine both, with up to 4 breakpoints per request.
• For the longer lifetime, add "ttl": "1h" inside cache_control. Worth it only for gaps between 5 minutes and an hour (see the chart above).
• Minimum size: Opus 5.5, Sonnet 5.5 and Fable 5.1 cache prompts from 512 tokens; Haiku 4.5 needs 4,096. Shorter prompts run uncached, with no error.

To check it worked, read the usage block. It reports cache_creation_input_tokens (written), cache_read_input_tokens (read) and input_tokens (the uncached rest). If both cache fields are 0, nothing was cached.

One catch the docs mention: a cache entry only becomes available once the first response starts. Fire 50 requests in parallel and they all pay for a write. Send one, wait for it to start streaming, then send the rest.

How prompt caching works on OpenAI

There is nothing to switch on. Prompts of 1,024 tokens or more are cached automatically, and every response reports a cached_tokens figure in its usage details, so you can see the hit rate per request. OpenAI also offers an extended retention option for keeping cached prefixes longer. The same ordering rule applies.

Because misses cost nothing extra, the only work on OpenAI is structuring prompts so they share a long, identical start. A timestamp or a user name at the top of the system prompt is enough to break every hit. I’d check that before anything else.

What caching won’t fix

Output tokens are never cached. Once the prefix is cheap, the reply and the changing part of the input make up most of what is left, so a model that writes long answers stays expensive. The other levers (a smaller model, shorter replies, batching) are in how to cut LLM API costs.

On privacy, Anthropic says caches are never shared between organizations and are isolated per workspace on the Claude API, and that the cached representations are held in memory for the cache lifetime, then deleted. Caching doesn’t change what you send, though. If the system prompt holds customer data, it is still customer data at 5% of the price.

To price your own workload, start with the LLM Cost Calculator: it gives the uncached monthly figure for every model, which is the ceiling. Then take the cached share of your input off the input side using the prices above. If you are still sizing the feature, the OpenAI API cost walkthrough covers how to estimate the three inputs.