What a cache write is
Prompt caching needs something in the cache before anything can be read from it. The request that puts it there is the cache write: the provider processes the prefix at full cost, then keeps its internal state so the next request starting with the same tokens can skip that work. Every later request that finds the entry is a cache read; every request that arrives after the entry expired, or with a changed prefix, writes it again.
Anthropic reports the three parts of a cached request separately: cache_creation_input_tokens for tokens written on this call, cache_read_input_tokens for tokens served from the cache, and input_tokens for whatever came after the last cache breakpoint. Total input is the sum of the three, so a dashboard that reads only input_tokens undercounts what you paid for.
How cache writes are priced
Vendors split into two camps. Anthropic prices a write above base input: 1.25× for a cache that lives five minutes and 2× for one that lives an hour, with reads at 0.1× base input on most models. OpenAI's documentation states that from GPT-5.6 onward a cache write costs 1.25× the uncached input rate, and that its earlier models carry no separate write charge — the first request is simply billed as ordinary input. OpenAI also stresses that a write is not an extra fee on top: each input token is billed once, at either the uncached, cached or cache-write rate.
Anthropic's multipliers stack with its other modifiers: the batch discount and the data-residency uplift apply to cache writes and reads as well. The numbers our index records for each model's write rate are in the panel below.
In our indexCache-write rates in our index
Counted at build from our price index: the published cache-write rate against the standard input rate among the 167 current public models we price, from 33 vendors. Each rate comes from the vendor's own price page, read between 2026-09-24 and 2026-10-09. How we collect prices.
When a write pays back
The arithmetic follows from the multipliers. A write costs the premium above input once; each read saves the gap between input and the read rate. At Anthropic's five-minute pricing the premium is 0.25× input and each read saves 0.9× input, so one read already covers the write — Anthropic's own pricing page says caching pays off after one cache read. A one-hour write costs a full extra 1× input, so it needs two reads within the hour to come out ahead.
That makes the lifetime choice a question about traffic. A prefix that is reused every few seconds stays warm on the five-minute cache, because each read refreshes it at no charge. A prefix that is reused every 20 minutes would expire and be rewritten three times an hour on the short cache — and once an hour on the long one. Anthropic suggests the one-hour cache for batch jobs, which can take longer than five minutes to work through.
Spotting write-heavy traffic on a bill
A healthy cached workload shows reads far above writes. If the write column is close to the read column, the cache is being rebuilt rather than reused: the prefix changes between requests, the traffic is too sparse for the lifetime, or requests are spread across more distinct prefixes than intended. Our cost calculator prices every cache miss at the write rate for vendors that bill writes, which is why a low hit rate on those models can cost more than no caching at all.