Cache writes cost more than a normal input token. Cache reads cost far less. Here's the actual math, not just "up to 90% off."
| Token type | Multiplier on input price | Sonnet 5 effective $/1M |
|---|---|---|
| Normal input (uncached) | 1× | $3.00 |
| Cache write, 5m TTL | 1.25× | $3.75 |
| Cache write, 1h TTL | 2× | $6.00 |
| Cache read (hit) | 0.1× | $0.30 |
Prices as of 2026-07, Sonnet 5. The write is a one-time premium on the turn that populates the cache; every later turn that hits it pays the 0.1× read rate instead of full price. Always confirm current numbers at platform.claude.com/docs/en/about-claude/pricing.
Say a coding agent reuses a 20,000-token system prompt + tool schema across 50 turns in a session, with 5-minute-TTL caching:
| Approach | Cost for 20K tokens × 50 turns |
|---|---|
| No caching — pay full input price every turn | $3.00 |
| With caching — 1 write (1.25×) + 49 reads (0.1×) | $0.36 |
That's ~88% cheaper on the repeated-context portion alone, and the gap widens the longer the session runs — turn 100 costs the same marginal $0.006 as turn 2.
If your context changes on every single turn (no stable prefix — e.g. each request has genuinely unique input with nothing shared), there's nothing to cache and the write premium just adds cost. Caching pays off specifically when a prefix — system prompt, tool definitions, a large document, conversation history — repeats across calls within the TTL window.
The full calculator has dedicated cache write/read fields (with a 5m vs 1h TTL toggle) so you can plug in your actual prefix size and turn count instead of trusting a generic "up to 90%" claim. See also: real monthly cost estimates for Claude Code.