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 what you pay for is the same tokens over and over. A system prompt, a set of tool definitions, a retrieved document — read fresh on every single request at full input price. Prompt caching is the lever that stops that, and it can cut input cost by an order of magnitude.
The mechanics are simple once you separate the prompt into two parts: a cached prefix that rarely changes and the fresh tokens of each new turn. The prefix is charged three different ways. On a cache miss it is written at a small premium (often ~1.25× input). On a cache hit it is read at a deep discount (often ~0.1× input). Fresh tokens always pay full price. Your effective cost per request is just the weighted blend: fresh + hitRate × cheapCached + (1 − hitRate) × writtenCached.
Two things decide whether it is worth it: how much of your prompt is the fixed prefix, and how often that prefix is reused before the cache expires. Big shared context plus high reuse equals big savings; a unique prefix per request, or traffic so sparse the cache keeps expiring, barely moves. This calculator makes the trade concrete — slide the hit rate and the prefix share and watch the effective price and the percent saved respond.
How it works
- Effective input = fresh + hit×cheap-cached + miss×written-cached.
- Cache write premium is paid on misses; read discount on hits.
- Savings grow with cached-prefix share and hit rate.
- Set the multipliers to your provider’s published numbers.
Frequently asked questions
How does prompt caching save money?
Providers let you mark a stable prefix — a system prompt, tool definitions, a long RAG or document context — so that after the first call its tokens are served from a cache at a steep discount (often around 10% of the input price) instead of being re-processed at full price on every request. On workloads where most of the prompt is the same fixed context and only a short user turn changes, that shrinks the dominant cost line dramatically.
What is the cache-write premium?
The first call that populates the cache usually costs a bit more than a normal input token — commonly around 1.25× — because the provider has to store the processed prefix. So caching only pays off when a prefix is reused enough times to amortise that one-time write premium. This calculator accounts for it: the write cost is paid on cache misses, the cheap read cost on hits.
What hit rate should I expect?
It depends on reuse and cache lifetime. A single-tenant chatbot with a fixed system prompt and steady traffic can approach a very high hit rate; a bursty or highly personalised workload where each prefix is unique gets little benefit. Caches also expire (a few minutes of idle is typical), so sparse traffic re-pays the write. Model a realistic rate here rather than assuming 100%.
Which providers support this and are the multipliers exact?
Anthropic, OpenAI and Google all offer prompt/context caching, with differing write premiums, read discounts and TTLs. The defaults here are representative, not any one vendor’s current price — set the cache-write and cache-read multipliers to match your provider’s published numbers for an accurate figure. The relative geometry (huge savings on high-reuse fixed context) holds across all of them.