Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path
Prompt Caching Savings Calculator
Prompt caching is the biggest cost lever on repetitive LLM workloads — a shared system prompt or RAG context read on every call is charged at a fraction of the price once cached. Put in your prompt shape (cached prefix vs fresh tokens), a cache hit rate, and the provider's cache-write and cache-read multipliers, and see your effective cost per request and the percentage saved versus paying full price every time.
Effective input = fresh + hit×(prefix×read) + miss×(prefix×write). A written prefix pays for itself after 1.3 reuses at these multipliers. Set write/read × to your provider's published cache prices.
On a repetitive LLM workload, most of the input bill is the same tokens sent over and over. A system prompt, tool definitions and a shared document are processed at full price on every request unless the provider can reuse them. This calculator compares a request with and without prompt caching and scales the difference to a month of traffic.
What it computes
price = input $ per 1M tokens / 1,000,000
no cache = (prefix + fresh) × price
with cache = fresh × price
+ hit × prefix × price × read
+ (1 − hit) × prefix × price × write
saved % = 1 − with cache / no cache
monthly = per-request cost × requests per month
break-even = 1 + (write − 1) / (1 − read) uses of one written prefix- Prefix is the cacheable part: identical at the start of every request.
- Fresh tokens change per request and always pay full price.
- Hit is the share of requests that find the prefix already cached. A miss writes it.
- Write and read are multipliers on the base input price for writing and reading the cache.
Output tokens are not part of the calculation, because caching only discounts input.
A worked example
The defaults are an 8,000-token prefix, 400 fresh tokens, an 85% hit rate, $3 per million input tokens, a 1.25× write, a 0.1× read and 1,000,000 requests a month.
- No cache:
8,400 × $0.000003 = $0.0252per request. - Fresh tokens:
400 × $0.000003 = $0.0012. - Hits:
0.85 × 8,000 × $0.000003 × 0.1 = $0.00204. - Misses:
0.15 × 8,000 × $0.000003 × 1.25 = $0.0045. - With cache:
$0.0012 + $0.00204 + $0.0045 = $0.00774, shown as $0.0077, so 69% cheaper per request. - Monthly: $25.2K without caching against $7.7K with it, $17.5K saved. Break-even is
1 + 0.25 / 0.9 = 1.28, shown as 1.3 reuses.
Notice that the 15% of misses cost more than the 85% of hits. The hit rate, not the discount, is what moves the result:
| Hit rate | Cost per request | Saved | Monthly |
|---|---|---|---|
| 0% | $0.0312 | −24% | $31.2K |
| 50% | $0.0174 | 31% | $17.4K |
| 85% | $0.0077 | 69% | $7.7K |
| 95% | $0.0050 | 80% | $5.0K |
| 100% | $0.0036 | 86% | $3.6K |
Assumptions and limits
- Hit rate is an input. The tool does not model traffic, cache lifetimes or how many prefixes you have; you supply the rate.
- One prefix, written whole. Real caches can match several breakpoints, and a partial match still saves on the matching part.
- Provider rules are not modeled. Minimum cacheable lengths, commonly around 1,024 tokens, longer lifetimes at a higher write price, storage fees and automatic caching all change the result.
- Input only. Output pricing, rate limits and the latency benefit of caching, which is often large, are left out.
How to use the result
- Order the prompt for caching. Stable content first, per-request content last, with no timestamps or IDs in the prefix.
- Measure your real hit rate from the usage fields providers return, then plug it in rather than guessing.
- Keep traffic warm. If gaps between requests exceed the cache lifetime, every request is a miss and caching costs extra.
- Compare reuse with break-even. At an 85% hit rate each write is followed by about 5.7 reads on average, far above the 1.3 uses needed. At these multipliers caching only breaks even at about a 22% hit rate, and below that it costs more than it saves.
- Cache big shared context. Savings scale with the prefix’s share of the prompt; a 200-token system prompt barely matters.
How it works
- Effective input = fresh + hit × prefix × read + miss × prefix × write.
- Cache write premium is paid on misses; read discount on hits.
- Break-even uses = (write − read) ÷ (1 − read); 1.3 at the defaults.
- Set the multipliers to your provider’s published numbers.
Frequently asked questions
How does prompt caching save money?
Providers let a stable prefix, such as a system prompt, tool definitions or a long document, be cached after it is first processed. Later requests that start with the same prefix read it from the cache at a steep discount instead of paying full input price to process it again. On workloads where most of the prompt is fixed context and only a short user turn changes, that shrinks the largest line on the bill. With this tool’s defaults it cuts input cost per request by 69%.
What is the cache-write premium?
The call that populates the cache can cost more than a normal input token, because the provider stores the processed prefix; the default here is 1.25 times the base price. Caching pays off only when a written prefix is reused enough to recover that premium. The tool charges the write price on every miss and the read price on every hit, and reports the break-even: at 1.25 times to write and 0.1 times to read, a prefix pays for itself after about 1.3 uses.
What hit rate should I expect?
It depends on how often the same prefix repeats before the cache expires. A chatbot with one fixed system prompt and steady traffic can reach a very high rate, while a workload where every prompt is unique gets little benefit. Caches typically expire after a few minutes without use, so sparse traffic keeps paying the write premium. In this tool the default prompt saves 31% at a 50% hit rate, 69% at 85% and 80% at 95%, and costs more than no cache at 0%.
Which providers support this and are the multipliers exact?
Anthropic, OpenAI and Google all offer prompt or context caching, with different write premiums, read discounts, lifetimes and minimum prefix lengths. The defaults, a 1.25 times write and a 0.1 times read, match Anthropic’s published five-minute cache pricing; some providers charge no write premium but give a smaller read discount, and some bill for storage time. Set the write and read multipliers to your provider’s current numbers for an accurate figure.
What should go in the cached prefix?
Everything that is identical across requests and comes first: the system prompt, tool definitions, fixed instructions and examples, and any shared document or retrieved context reused across turns. Caches match on an exact prefix, so one changed character, such as a timestamp or a user name near the top, breaks the match for everything after it. Put the stable material first, the per-request material last, and keep the prefix byte-for-byte identical.