Calculator

Prompt cache savings calculator

Split a stable prefix from dynamic tokens, set your expected cache hit rate, and see how much prompt caching cuts from the bill—including Anthropic-style cache writes on misses.

Cache savings

Monthly savings with prompt cache

$652.5028.1% lower

37,500 hits · 12,500 misses on Claude Sonnet 4.5

Without cache$2,325.00
With cache$1,672.50
75% hit rate
Hit traffic$528.75
Miss traffic$1,143.75
Cache write$562.50
Break-even hit22%

Scenario

Prompt cache inputs

Tune prefix size and hit rate to see live savings.

Insights

Live savings gauge

Hit-rate slider drives the savings share vs full-price billing.

Savings vs full input28.1% · $652.50
Hit share of requests75%

Above break-even by 53 pts (need ≥22% hits to cover write premium).

Prefix / dynamic12,000 / 500
ModelClaude Sonnet 4.5

Prompt-cache savings depend on provider rules (TTL, minimum prefix size, and whether writes are billed). Planning figures only. Updated 2026-07-31. Approximate static list prices for planning only. Always verify against each provider’s official pricing page before production budgeting.

Guide

How to get value from this calculator

Quantify savings from prompt caching based on cache hit rate, cache write cost, and reduced cache read pricing. Providers charge a premium to write tokens into cache but discount subsequent reads—high hit rates on stable prefixes can cut input spend significantly. Model your workload before assuming caching is always net positive.

Cost formula

Net cache savings = (full input price − cache read price) × cached tokens × hit rate × requests − cache write price × cached tokens × write frequency × requests

Why it matters

Prompt caching can be the largest input-cost lever for RAG and agent apps, but write premiums and low hit rates can make it a net loss. Quantifying read savings minus write cost prevents adopting caching without economic justification.

How to use it

  1. Identify the stable token prefix you will cache (system prompt, docs, tool schemas).
  2. Enter cached token count and your expected cache hit rate.
  3. Set monthly request volume for the cached workload.
  4. Review savings from discounted cache reads at your hit rate.
  5. Slide the hit-rate control and watch the savings gauge for when caching turns net positive.
  6. Subtract cache write costs for initial and refresh writes.
  7. Confirm cache pricing, TTL, and minimum token thresholds on your provider's docs.

Planning tips

  • Stable system prompts and shared document context achieve the highest hit rates.
  • Cache TTL expirations force re-writes—factor refresh frequency into write cost.
  • Minimum cacheable token counts vary by provider; sub-threshold prefixes gain no benefit.
  • Output token pricing is unaffected by caching—savings are on the input side only.
  • Stress the savings gauge at conservative vs optimistic hit rates before committing.
  • Use the payback readout to see how many requests recover cache write cost at your hit rate.
  • Measure hit rate in provider observability after launch rather than guessing.

Frequently asked questions

What hit rate makes caching worthwhile?

It depends on write vs read price delta and cache size. Generally hit rates above 60–70% on large stable prefixes show strong savings. Run your numbers here with conservative assumptions.

Are cache prices in CentsPerToken official?

No. CentsPerToken uses approximate list prices for planning. Cache pricing, TTL rules, and eligibility change—verify on your provider's documentation.

Do all models support prompt caching?

No. Support varies by model and provider. Confirm eligibility before modeling savings for a specific model.

Does caching reduce output cost?

No. Cache discounts apply to cached input token reads. Output tokens are billed at standard output rates.