Prompt caching on the Claude API: what it costs and how to check it
Write and read rates per model, the prefix order that decides a hit, the silent minimum length, and the usage fields that prove the cache is working.
By ClaudeGPT Si Newsroom, Editorial team
3 min read
Prompt caching on the Claude API charges you a small surcharge to store a prompt prefix, then bills every later reuse of that prefix at a fraction of the normal input price. As of November 2026, reading cached tokens on Sonnet 5.5 costs $0.10 per million against $2 for fresh input, so long system prompts, tool lists and documents get much cheaper on repeat calls.
The rules below come from Anthropic's prompt caching documentation and its pricing page, checked on November 4, 2026.
How a cached request is billed
A request can contain three kinds of input tokens, each with its own price.
- Cache write. The first time a prefix is stored, it costs 1.25 times the input rate for the default 5-minute lifetime, or 2 times for a 1-hour lifetime.
- Cache read. Later requests that reuse the prefix pay the cache read rate. On most models that is 0.1 times input; Opus 5.5 and Sonnet 5.5 charge 0.05 times, and Fable 5.1 charges 0.025 times.
- Plain input. Anything after the cached prefix is billed at the normal rate, and output is unaffected.
| Model | Input | 5-minute write | 1-hour write | Cache read |
|---|---|---|---|---|
| Fable 5.1 | $10 | $12.50 | $20 | $0.25 |
| Opus 5.5 | $4 | $5 | $8 | $0.20 |
| Sonnet 5.5 | $2 | $2.50 | $4 | $0.10 |
| Haiku 5.5 (prompts up to 100K) | $0.10 | $0.125 | $0.20 | $0.01 |
Prices are in US dollars per million tokens. At the standard read rate, Anthropic says a 5-minute write pays for itself after one cache read and a 1-hour write after two.
What actually gets cached
Claude caches a prefix, in a fixed order: tools first, then the system prompt, then messages. Change anything at or before your cache point and the next request writes a new entry instead of reading the old one. That is why timestamps or user names near the top of a system prompt quietly break caching.
You can turn it on two ways. Automatic caching takes one top-level cache_control field. Explicit caching lets you mark up to four breakpoints on individual blocks. Each use refreshes the 5-minute lifetime at no extra cost, and an entry only becomes readable once the first response has started, so requests fired at the same moment all pay to write. Caches are separate per organization, and per workspace on the Claude API.
The minimum length trap
Short prompts are not cached at all, and the API returns no error when that happens. As of November 2026 the minimum is 512 tokens on Fable 5.1, Opus 5.5, Opus 5, Sonnet 5.5 and Haiku 5.5; 1,024 on Sonnet 5, Sonnet 4.6 and Opus 4.8; and 4,096 on Haiku 4.5 and Opus 4.6.
How to check it worked
Read the usage block of each response. cache_creation_input_tokens counts what was written and cache_read_input_tokens counts what was reused. If both stay at zero across repeated calls, nothing is being cached, and the usual causes are a prefix that changes or one below the minimum.
Caching inside Claude Code
Claude Code leans on the same cache. Its /usage command (version 2.1.251 or later) has a prompt cache line showing how much input came from the cache, and Anthropic's cost guide notes that the first message after a break longer than the cache lifetime reprocesses the whole context.
To see that pattern over days rather than one session, UsageAtlas shows input, output and cache tokens for Claude Code, Codex, OpenCode and other local tools, with an estimated cost per model. It is free, open source, runs on Windows, macOS and Linux, and works without an account. Its guide to cache tokens explains the columns. For an app you wrote against the API, the response usage fields and the Claude Console are the better source, because UsageAtlas reads coding tools on your machine, not your own requests.