Caching and its billing apply with and without a server prompt. Confirmed Claude cache reads cost 10 times less than regular input, Opus 5.5 reads cost 20 times less, and Fable 5.1 reads cost 40 times less. Applied server-prompt tokens use the full input or cache-read rate. A cache hit is not guaranteed.
| Model | Regular input / 1M | 5m write / 1M | 1h write / 1M | Read / 1M |
|---|---|---|---|---|
claude-haiku-5-5 | $0.10 (over 100K: $0.50) | $0.125 (over 100K: $0.625) | $0.20 (over 100K: $1.00) | $0.01 (over 100K: $0.05) |
claude-haiku-4-5 | $1.00 | $1.25 | $2.00 | $0.10 |
claude-sonnet-5-5 | $2.00 | $2.50 | $4.00 | $0.20 |
claude-sonnet-5 | $3.00 | $3.75 | $6.00 | $0.30 |
claude-opus-5-5 | $4.00 | $5.00 | $8.00 | $0.20 |
claude-opus-5 | $5.00 | $6.25 | $10.00 | $0.50 |
claude-opus-4-8 | $5.00 | $6.25 | $10.00 | $0.50 |
claude-fable-5 | $10.00 | $12.50 | $20.00 | $1.00 |
claude-fable-5-1 | $10.00 | $12.50 | $20.00 | $0.25 |
Regular uncached input costs 1×. A standard 5-minute cache write is billed at 1.25× input, an explicit 1-hour write at 2×, and a later cache read at 0.1×, 0.05× for Opus 5.5, or 0.025× for Fable 5.1. Fable 5 rates and historical charges stay unchanged. A warm-up request can therefore cost more than regular input, while savings appear on subsequent matching requests. For Haiku 5.5, a request whose whole input — regular, cache reads and cache writes — exceeds 100,000 tokens is billed at the “over 100K” rates in the table, 5× higher.
- Caching uses the stable request prefix: tool definitions, system text and the beginning of message history.
- A hit means this beginning matched a recent request byte-for-byte. Changing even the first character resets the match entirely.
- The cache lives for a few minutes and is refreshed on every hit.
- The first sufficiently large cacheable request of a new session usually "warms up" the cache, so a hit can begin on the second request. A hit is not guaranteed every time; that's normal.
- Stable beginning. Keep the system prompt and instructions identical between requests — no on-the-fly edits.
- No variables at the start. Timestamps, random ids, user names — put them at the END of the prompt: a changed first byte kills the whole prefix match.
- Append-only conversation. Add new messages to the end of the history; don't edit or reshuffle old ones.
- Stable tools. The same set and order of functions on every request — tool definitions are part of the prefix too.
- Large documents go into system once. Put knowledge bases and code at the start; changing questions at the end.
- Keep the pace. A follow-up within a few minutes hits the cache; after a long pause the first request warms it up again.
Claude /v1/messages and /v1/messages/count_tokens support cache_control: top-level automatic caching and explicit markers in eligible system/content blocks and client-tool definitions. The default TTL is 5 minutes; use "ttl": "1h" for an hour. usage.cache_creation separates 5m/1h writes.
- The "Tokens and cache" panel under Statistics in your Guard account — how many tokens were read from cache over the period.
- The "Cache read" and "Cache write" lines under the token count in Requests — per-request hits.
- In the API response:
usage.cache_read_input_tokens(Anthropic) orusage.prompt_tokens_details.cached_tokens(OpenAI).
{
"usage": {
"input_tokens": 9900,
"cache_read_input_tokens": 27451,
"output_tokens": 56
}
}- Kimi. Cache reads are billed at a separate lower rate; live rates and a spend breakdown are on Kimi: pricing, reserve and usage. The
prompt_cache_keyfield is accepted and passed to the model as it is. - Composer and Grok. A
cache_controlmarker inside a block is accepted and ignored; it does not control caching. Caching is automatic. Accounted reads appear in Messagesusage.cache_read_input_tokensand Chat Completionsusage.prompt_tokens_details.cached_tokens. - Cache writes are free for Composer and Grok. That is not a rounding or an unknown: the cache-creation rate is zero, so
cache_creation_input_tokensin the response is always0.
Codex uses automatic subscription caching. Accounted reads and writes arrive in actual usage and are priced at the requested model's rates; ordinary input does not count those tokens a second time.
GLM reports actual cache reads in native usage. Guard normalizes the three shapes and applies the lower cache rate only to tokens actually marked as cached.
| API | Total/input field | Cache field | Uncached input |
|---|---|---|---|
| Messages | usage.input_tokens | usage.cache_read_input_tokens | input_tokens already excludes cache reads |
| Chat | usage.prompt_tokens | usage.prompt_tokens_details.cached_tokens | prompt_tokens - cached_tokens |
| Responses | usage.input_tokens | usage.input_tokens_details.cached_tokens | input_tokens - cached_tokens |
For glm-5.3, 4,000 uncached and 8,000 cached input tokens cost $0.00560000 + $0.00208000. Output is priced separately at $4.40 / 1M.
The Gemini cache is Google's automatic cache only. cache_control markers are accepted, but the cache retention time is not promised. The discount applies only to tokens that Google actually read from the cache: a cache read is billed at the rate in the rates table on the Billing page, and writing to the cache has no separate charge. For gemini-4-argon, a cache read costs $0.10 per 1M tokens ($0.20 from December 1, 2026, 00:00 UTC); for gemini-3.8-flash, $0.075 ($0.15 from January 1, 2027, 00:00 UTC).
Writing to the Muse cache has no separate charge, and a long context is billed without a surcharge. A cache read costs $0.20 per 1M tokens for muse-wonder-1.0 and $0.15 for muse-spark-1.3 and muse-spark-1.2.