Cached input pricing across LLM APIs

The single biggest lever on input-heavy bills — and the one most estimates ignore.

Computed from the SelfBench catalog of 30 models, Oct 15, 2026. Prices are published list rates; every model page links to its source.

Most LLM APIs charge less for input tokens the provider has seen recently. It is the largest discount on the price sheet, and it applies to exactly the tokens that dominate long conversations and RAG pipelines: the repeated prefix.

Across 27 of the 30 models in our catalog that publish a cached-input rate, the cached price is a median of 10% of the standard input rate — as low as 2% and no higher than 30%.

The data

ModelStandard inputCached inputCached as % of input
DeepSeek-V4.1-Flash$0.300$0.00602%
Claude Fable 5.1$10$0.2503%
DeepSeek-V4-Pro-0813$1.32$0.0443%
Claude Opus 5.5$4$0.2005%
Claude Sonnet 5.5$2$0.1005%
Gemini 4 Argon$2$0.1005%
Muse Wonder$4$0.2005%
GPT-6.1 Sol$2$0.1005%
Claude Haiku 5.5$0.100$0.01010%
Gemini 3.8 Flash$0.750$0.07510%
Gemini 3.8 Flash Cyber$1.50$0.15010%
Kimi K3$3$0.30010%
GPT-5.3-Codex$1.75$0.17510%
GPT-6 Luna$0.100$0.01010%
Gemini 3.1 Pro Preview$2$0.20010%
GPT-5.6 Sol$4$0.40010%
GPT-6 Astra$10$110%
Grok 4.5$2$0.30015%
Grok 4.3$1.25$0.20016%
Kimi K2.6$0.950$0.16017%
Kimi K2.7 Code$0.950$0.19020%
Grok Build 0.1$1$0.20020%
Grok 4.6$2$0.50025%
Grok 4.7$2$0.50025%
GLM-5.3-Flash$0.120$0.03025%
GLM-5.3$1.19$0.30025%
GLM-5.3-FlashX$0.300$0.09030%

Published list prices, Oct 15, 2026. Cache-write prices are usually higher than standard input and are noted on each model page.

Why this matters more than the headline rate

Consider a chat product that sends a 6,000-token system prompt and tool schema on every request, plus 400 tokens of actual conversation. Ninety-four percent of the input is identical every time.

  • Without caching: you pay the full input rate on all 6,400 tokens.
  • With a 10% cached rate and a realistic 80% hit rate: the repeated 6,000 tokens bill at a tenth of the rate, so input cost falls by roughly 72%.

On an input-heavy workload that is a bigger saving than switching to a cheaper model — and it does not require re-evaluating quality.

How to model it honestly

  1. Split your input into a stable prefix (system prompt, tool definitions, static instructions) and a variable part (retrieved context, conversation).
  2. Only the stable prefix can hit the cache reliably. Assume a hit rate below 100% — cache entries expire, and the first request after a gap is a miss.
  3. Multiply the stable prefix by the cached rate and the rest by the standard rate.
  4. Subtract the cache-write cost if your vendor bills one. Here, Kimi K3 bill cache writes separately.

Price both cases in the calculator →

Frequently asked questions

Is caching automatic?

It depends on the vendor. Some cache automatically and charge the cached rate on hits; others require an explicit cache-write step or a retention parameter. Check the vendor's caching documentation before assuming a hit rate.

How do I estimate my cache-hit rate?

Look at the share of input tokens that are identical between consecutive requests — usually the system prompt and tool definitions. If that is 70% of your input and you hit on most of it, modelling a 50–60% hit rate is more realistic than assuming 100%.

Is the cache-write cost in my favour?

Only if the cached prefix is read more than once or twice. Cache writes are typically billed above the standard input rate, so a prefix used once is cheaper uncached.

Keep going