Free tool

Prompt caching savings calculator

Most production prompts repeat the same opening block on every call. Caching bills that block at roughly a tenth of the input rate. This works out what that is worth on your volume.

Only models that publish a cached input rate are listed.

For one workload, not the whole company. Caching is configured per prompt.

System prompt, examples, tool schemas and retrieved context, added together.

70%

The opening block that never changes. This is the part caching can hold.

Unchanged by caching, but it decides how much of the bill caching can reach.

85%

How often a call arrives while the cached block is still warm. Steady traffic sits high, bursty traffic much lower.

Estimated saving, each month

$4,583

That is $54,999 a year, 35.9% of this workload's bill.

$8,167 of the original $12,750

This workload today
$12,750 a month
With caching on
$8,167 a month
Input cost alone comes down
50.9%

An estimate from published rates, last checked 2026-08-20. Your provider reports cached reads and cache writes separately in its usage fields, which is where the real figure comes from.

How much does prompt caching actually save?

On a workload with a long stable prompt and a short answer, caching takes most of the input cost off the bill, and input is usually the larger half of that kind of call. The discount is steep: a cached read bills at roughly a tenth of the standard input rate on every provider that offers it. What decides your figure is not the discount, it is how much of your prompt repeats and how often calls arrive while the cache is still warm. A long system prompt hit constantly is close to the best case. A short prompt hit rarely is close to no case at all.

What to check

Where the stable block usually hides.

Caching pays for whatever sits at the front of the prompt and never changes. In most codebases that is more text than anyone remembers writing.

The system prompt
Written once, grown by every incident since, and sent in full on every call. Usually the single largest cacheable block.
Few-shot examples
Added during development to steady the output format. They are identical on every request by definition.
Tool and schema definitions
An agent with a dozen tools can carry several thousand tokens of schema before the user has said anything.
Policy and reference documents
Compliance text, style guides, product catalogs and pricing tables pasted into the prompt rather than retrieved.
The stable head of a conversation
In chat and agent loops the opening turns never change again, so everything before the newest message can be held.
Before you switch it on

Three things that decide whether this works.

  • Put the stable text first. Caching matches a prefix, so anything variable near the front of the prompt cancels everything after it. A timestamp in the opening line is enough to do that.
  • Keep the block byte-identical. Reordered JSON keys, a changed date, or a rebuilt tool list all read as a different prefix and quietly stop the cache working.
  • Measure the hit rate rather than assuming it. Every provider reports cached reads in the usage fields on the response. If that figure stays at zero, something in the prefix is changing on every call.
FAQ

About prompt caching

What is prompt caching?

Most production prompts start with the same block of text every time: a system prompt, a set of examples, a tool schema, a policy document. Prompt caching lets the provider keep that opening block warm so you are not billed the full input rate for sending it again on the next call.

A cached read costs roughly a tenth of the standard input rate on every provider that offers it. Nothing about the request or the answer changes. It is configuration, not a rewrite.

Why does the saving only apply to input?

Because caching is a discount on text you send, and the model still has to generate every output token from scratch. On a workload with a long stable prompt and a short answer the saving is large. On a workload with a short prompt and a long answer it is small, and this calculator will show you that rather than hide it.

What does the cache hit rate mean, and what is realistic?

It is the share of calls that arrive while the cached block is still warm. Caches expire after a few minutes of inactivity on most providers, so a workload with steady traffic hits often and a workload with long quiet gaps hits rarely.

Steady production traffic against one stable prompt usually sits high. Bursty internal tools sit much lower. If you are guessing, run the number at two hit rates and look at the gap.

Can caching ever cost more than it saves?

Yes, on Anthropic models, and this calculator will tell you when. Writing a block into the cache costs about a quarter more than sending it normally, so if your hit rate is low enough that you are mostly paying to write and rarely reading, the arithmetic turns against you. Drop the hit rate slider and watch the figure go negative.

On OpenAI and Google there is no write premium on the input rate, so the downside case is different. Google also bills cache storage by the hour, which this page does not model.

How exact is this?

It is an estimate built from published rates, last checked 2026-08-20. It assumes one stable prefix and one hit rate across the whole workload, and a real system has several of each. Use it to decide whether caching is worth an afternoon, then measure the real figure from your provider's usage fields, which report cached reads and cache writes separately.

Caching is one of seven. Find the rest.

Book 30 minutes. We connect a read-only view of every provider you pay and return a ranked list of cheaper routes to the same output, each with a dollar figure and an owner.

5 minute setup. Read-only. No engineering time needed.