Prompt caching: Save 20–73% on LLM API Costs
Does prompt caching save money on LLM API costs?
Yes, for the right workload shape: 20–73% based on Net monthly savings across 3 sourced providers, priced models, and cacheable workload shapes: pricingHub input/output rates plus each provider's sourced write/read multipliers and TTL, with one write per TTL window. It does not apply universally — see the applicability and tradeoff sections below before using it.
How it works
Prompt caching stores a stable prefix so later requests pay the provider’s cache-read rate instead of the normal input rate. The economics are not a universal 90% rule: this guide joins each provider’s sourced read multiplier, write multiplier, minimum prefix, and TTL to the same model prices used by the cost calculator. A first write can cost more than an ordinary input; the break-even reuse count is therefore calculated as the write premium divided by the per-read saving. Keep stable instructions and reference material first, put changing user content after the cache boundary, and measure cache hits in production.
Where it applies
Stable-prefix workloads: long system instructions, tool definitions, repeated documents, and multi-turn agents. It does nothing when the prefix changes every request, falls below the provider minimum, or is reused too infrequently to repay the first write.
Prompt-cache economics by provider
| Provider | Cache read | Cache write | Minimum prefix | TTL | Break-even reuses | Verified |
|---|---|---|---|---|---|---|
| OpenAI | 10% of input | 1.25× input | 1,024 tokens | 30 min | 1 reuse | 2026-08-15 |
| Anthropic | 10% of input | 1.25× input | 1,024 tokens | 5 min | 1 reuse | 2026-08-15 |
| 10% of input | 1× input | 4,096 tokens | 60 min | First reuse | 2026-08-15 | |
| xAI | — | — | — | — | — | — |
| DeepSeek | — | — | — | — | — | — |
| Mistral | — | — | — | — | — | — |
| Groq | — | — | — | — | — | — |
| Cerebras | — | — | — | — | — | — |
| Qwen | — | — | — | — | — | — |
| Amazon | — | — | — | — | — | — |
| Z.ai | — | — | — | — | — | — |
Rows marked — are providers without a published provider-level cache record; they are excluded from the break-even and savings calculations. Read and write rates are multipliers on the provider’s ordinary input price.
Worked cache example
This llm chatbot example uses the same workload shape as the cost calculator. The break-even count is the first reuse at which the sourced write premium is repaid by cheaper reads; it is not a generic caching rule.
For a 12,000-token stable prefix, the provider rows below show whether caching is free to enable or how many reuses repay the first write. Confirm that your actual prefix clears each provider’s minimum before using the estimate.
The tradeoff
Caching can increase the bill when a prefix is written and then expires before enough requests reuse it. A changing system prompt, reordered tool list, or short prefix causes misses, so the application pays normal input pricing without receiving the expected read discount. Explicit caches can also add storage charges or require cache-control fields, and cached content has a provider-specific lifetime. Treat the result as a workload decision: use the break-even count below, verify that your prefix clears the minimum token length, and monitor hit and write tokens rather than assuming every repeated-looking request is a hit.
Worked example
For llm chatbot (growing conversation history in, short reply out) at 200,000 calls/month, GPT-5 Nano runs $52.00/month at list price and $52.00/month once verbosity is priced in. See the full ranked table for this workload →