Sending the same system prompt and reference documents with every Claude request creates an obvious opportunity to reuse work. Whether prompt caching lowers the bill depends on how often that prefix repeats, whether it meets the model's minimum length, and whether the next request arrives before the cache expires.
The read discount is only part of the calculation: cache writes carry a premium, and the five-minute and one-hour lifetimes suit different traffic patterns. This breakdown works through rates and break-even examples for Anthropic's API, Bedrock, and OpenRouter, then compares Groq's caching on its supported models.
Anthropic's caching documentation prices it as three multipliers of a model's base input rate. Writing to the cache with the default five-minute lifetime costs 1.25x base input. Writing with the one-hour lifetime costs 2x. Reading from the cache costs 0.1x, a 90% discount, on every model except Claude Fable 5.1 and Claude Mythos 5.1, where reads run at 0.025x.
These are standard-routing list rates before modifiers. Batch can reduce them, and on Anthropic's pricing page, inference_geo: "us" adds 1.1x to all token categories on Claude Opus 4.6, Claude Sonnet 4.6, and later models, while older models don't support the parameter. Everything after that depends on whether you clear the minimums and stay inside the window.
โ
Two consequences fall out of that arithmetic. A prefix you send twice is already ahead: 1.25x to write plus 0.1x to read is 1.35x, against 2.0x to process it twice uncached. A prefix you write and never reuse costs you 25% more than not caching at all. Caching is a bet on repetition and a cheap bet to lose, so we'd turn it on for anything with a stable prefix and think twice only when traffic is genuinely one-shot.
Rates below are per million tokens, from Anthropic's pricing documentation, as of September 3, 2026. Anthropic ships generations often enough that these move; verify against the live page before you budget on them.
Watch the Fable 5.1 and Mythos 5.1 rows: the only two where the read multiplier isn't 0.1x, pairing the platform's deepest discount with its most expensive base rate.
Anthropic supports caching on all active Claude models. Retired models differ by platform: Opus 4.1, Sonnet 4, and Haiku 3.5 are retired on the first-party API and still carry cache pricing on Bedrock and Google Cloud, and Opus 4 is retired everywhere except Google Cloud.
Check the minimum cacheable prefix length. A prefix shorter than the model's minimum doesn't cache. Anthropic processes it without caching or an error, so check the cache-read count to confirm reuse.
The minimums do not track model size, and they do not move in one direction across versions.
โ
Claude Haiku 4.5, the cheapest active model, has the highest minimum at 4,096 tokens. Claude Opus 5 has the lowest at 512, and the Opus line falls from 4,096 at 4.5 and 4.6 to 2,048, then 1,024, then 512, so every upgrade moves the threshold. Short system prompts may therefore fall below Haiku's caching minimum without producing an API error.
The default lifetime is five minutes, and Anthropic's caching docs say it refreshes at no cost every time the cached content is used. A conversation with a turn every couple of minutes keeps its cache alive on the cheaper write for as long as the turns continue.
Account for request duration when estimating cache lifetime. Anthropic measures the lifetime from the start of the request that writes or reads the entry, not from the end of the response. Their example: a response that takes four minutes to stream leaves roughly one minute for the follow-up request to start. Any "ping it every five minutes to keep it warm" scheme is wrong for long-generation workloads: the safe interval is materially shorter than the TTL.
Take a 20,000-token system prompt on Sonnet 5, base input $2 per million. Uncached, each call costs $0.04 for that prefix, while the first cached call costs 1.25x, or $0.05, and every hit after that costs 0.1x, or $0.004.
Two calls cost $0.054 cached vs. $0.08 uncached, so you're ahead on the second one. Ten calls inside the window are $0.086 against $0.40, a 78.5% saving on the prefix. That's the steady-traffic case: the five-minute tier is usually cheaper when the identical eligible prefix is reused within five minutes.
The one-hour TTL costs 2x the base input to write instead of 1.25x. On the same 20,000-token Sonnet 5 prefix, the write goes from $0.05 to $0.08.
That only pays when the gap between calls exceeds five minutes: a support tool queried a few times an hour against the same knowledge base, an agent that pauses for human approval. Under those patterns, the five-minute cache expires between every call, so you pay the 1.25x write every time and never collect a read discount. Two calls forty minutes apart cost $0.10 on the five-minute cache against $0.084 on the one-hour cache, and the gap widens with every additional call in the hour.
Our rule of thumb: if your median gap between calls on the same prefix is under five minutes, take the default. Between five and sixty minutes, the one-hour write beats the five-minute cache immediately, and beats no caching at all on the second cache read, which is the third call. Above an hour, neither helps, and you're back to paying full input rate.
Both cases, two calls on the same prefix:
โ
You can mix both in one request, but entries with the longer TTL must come first.
Caching is opt-in on Anthropic's API. You mark a content block with cache_control and everything from the start of the prompt up to and including that block becomes the cacheable prefix.
from anthropic import Anthropic
client = Anthropic()
# Must clear Sonnet 5's 1,024-token minimum, or the call is processed uncached.
LONG_SYSTEM_PROMPT = open("system_prompt.txt").read()
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
system=[
{
"type": "text",
"text": LONG_SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"} # 5-minute TTL
}
],
messages=[{"role": "user", "content": "..."}],
)
print(response.usage.cache_creation_input_tokens) # tokens written on this call
print(response.usage.cache_read_input_tokens) # tokens served from cacheFor the one-hour lifetime, the same block takes {"type": "ephemeral", "ttl": "1h"}. That system prompt has to clear the model's minimum to cache at all, which is 1,024 tokens on Sonnet 5.
Four things then decide whether you get a hit.
Prefix order is fixed. Anthropic documents that it builds cached prefixes as tools, then system, then messages, and a change at one level invalidates that level and everything after it. Reordering tool definitions therefore costs you the entire cache, while changing tool_choice costs you only the messages portion.
Anthropic requires identical prompt segments for a cache hit, so a timestamp, a request ID or a reordered JSON key in a tool_use block silently ends your hit rate. Even a whitespace change before the breakpoint changes the prefix and causes a miss. Their troubleshooting notes call out languages that randomize map key order during serialization as a specific cause. This is the constraint that defeats agent workloads most often: edit anything early in the context and the whole prefix is gone, which is why non-prefix caching exists at all.
Tensormesh Platform provides non-prefix caching for supported dense models.
You get four breakpoints, and they're free: adding more doesn't raise costs. Putting cache_control at the top level of the request body turns on automatic caching, which moves the breakpoint forward as the conversation grows and consumes one of the four slots; if four explicit breakpoints already exist, that request returns a 400.
Automatic caching also has a 20-block lookback, checking at most 20 positions per breakpoint. The breakpoint still lands at the end of the request, but a prior matching write outside that lookback won't be found, so add an earlier explicit breakpoint when a stable prefix spans more than 20 content blocks.
And input_tokens is not your input token count. It counts only tokens after the last breakpoint. The documented total is cache_read_input_tokens + cache_creation_input_tokens + input_tokens, and any cost model that multiplies input_tokens by the base rate is understating the bill. For why the split exists, our post on how KV caching works under the hood explains what's actually being stored.
Bedrock offers two modes. Implicit prompt caching means Bedrock and the model automatically attempt to reuse eligible prefixes with no cache controls in the request. Implicit caching is best effort: even an identical prompt may miss, and hit rates can vary.
Explicit prompt caching means you place cache checkpoints yourself, with the same four-checkpoint maximum and the same system, messages, and tools fields as the first-party API. The field names don't carry over. Bedrock's Converse API uses cachePoint with type: "default" and reports cacheWriteInputTokens and cacheReadInputTokens, where InvokeModel for Claude takes Anthropic's own cache_control.
Bedrock publishes absolute per-million-token rates rather than cache multipliers. Depending on the model, writing tokens to cache can cost more than processing ordinary input tokens.
On Bedrock's pricing page, under the global cross-region inference card read at US East (Ohio), the numbers line up exactly with Anthropic's own: Opus 5 at $5.00 base and $6.25 for the five-minute write, Sonnet 5 at $2.00 and $2.50, Haiku 4.5 at $1.00 and $1.25. The ratios work out to 1.25x, 2x, and 0.1x, with the same 0.025x read carve-out on Fable 5.1 and Mythos 5.1. These ratios are calculated from the listed rates; confirm the applicable rate card for your deployment.
Two practical differences matter more than rates. The minimums disagree. Anthropic lists 2,048 tokens for Opus 4.7 and Mythos Preview and says those minimums apply across supported platforms. Bedrock's own support table lists 4,096 for both. Near the threshold on either model, size against the platform you're actually calling.
The rate card depends on where you run. AWS lists three Anthropic rate cards: global cross-region inference, geo or in-region inference, and a legacy extended-access card. On the geo card, models from 4.5 onward run 10% higher, while Opus 4.1 and earlier releases carry the same prices on both. AWS also notes that cross-region inference under load may lead to increased cache writes, without quantifying it, which is a real risk on a write costing 1.25x to 2x.
Bedrock also documents a 30-minute TTL for the GPT-5.6 models, which matches neither Anthropic option.
OpenRouter is a routing layer, and its caching behavior follows from that: it doesn't publish its own cache price. What its documentation gives instead is a per-provider multiplier of that provider's input price: Anthropic cache reads at 0.1x, DeepSeek at 0.1x, Qwen at 0.1x, OpenAI at 0.25x or 0.50x, Gemini, Grok, and Moonshot at 0.25x, Z.AI at roughly 0.2x, Groq at 0.5x. Use the rates for your selected OpenRouter route when estimating costs.
Enablement varies by provider. Most cache automatically; OpenRouter singles out Anthropic and Alibaba as needing per-message enablement, using the same cache_control block described above, though Anthropic's top-level automatic field works here too.
Provider sticky routing helps preserve reuse across requests. After a request that uses caching, OpenRouter remembers which provider served it and routes follow-ups for that model to the same provider, keeping the cache warm. It activates only when the provider's cache read pricing beats regular input pricing, and steps aside if you pin a manual provider.order.
Sessions are identified by hashing the opening messages, or you can pass a session_id in the body or an x-session-id header. Setting one explicitly makes sticky routing activate on the first successful request rather than waiting for an observed cache hit. Sticky sessions expire after 10 minutes of inactivity, which is a routing timer, not a cache TTL. Don't conflate the two.
Cache economics show up in the response as a top-level cache_discount field, with cached_tokens and cache_write_tokens inside the usage details. OpenRouter notes that providers like Anthropic show a negative discount on writes and a positive one on reads.
Groq's model is structurally different from Anthropic's and much simpler. Caching is automatic on all API requests to supported models, requires no code changes, cannot be disabled, and carries no additional fee. There is no write premium. Cached input tokens get a flat 50% discount, on successful cache hits only, and Groq says it tries to maximize hits but doesn't guarantee them.
No write premium changes the break-even completely. On Anthropic, you're ahead on the second send. On Groq, there is nothing to be ahead of, because you never paid extra to create the entry.
Cached data expires after two hours without use, according to Groq's documentation. The troubleshooting and FAQ sections use "a few hours," so design against two hours, not against a guarantee. The minimum cacheable prompt runs from 128 to 1,024 tokens depending on the model, and Groq doesn't publish the per-model breakdown. Usage appears as cached_tokens inside prompt_tokens_details; there is no write-token field, which is consistent with writes being free.
As of September 3, 2026, Groq's direct API docs list caching support for three models, all in the GPT-OSS family: openai/gpt-oss-20b, openai/gpt-oss-120b, and openai/gpt-oss-safeguard-20b. OpenRouter separately claims Kimi K2 coverage for its Groq route, so coverage depends on whether you call Groq directly or through OpenRouter. Artificial Analysis, which aggregates published list prices across providers, shows a single Groq row for gpt-oss-120b, which corroborates Groq's own list. Treat Groq's list as authoritative for direct Groq calls, and OpenRouter's statement as scoped only to the OpenRouter route.
The choice follows the shape of your traffic, not the headline discount. Anthropic's five-minute cache is hard to beat for steady conversational load against a long fixed prefix. Sporadic access to the same context is where the one-hour write earns its premium. Multi-provider routing is where OpenRouter's sticky sessions do work you'd otherwise do yourself. A workload already on a supported GPT-OSS model gets Groq's discount for free.
For open-weight models, our Serverless Inference service bills successful cached input at $0 on most models on the current rate card, with no Anthropic-style cache-write premium. For self-hosted models, Tensormesh Platform provides persistent cross-session retention through filesystem-backed storage, where teams control storage and lifecycle.
It's built on the open-source LMCache project our founders created, and we make the case for owning your own context-caching lifecycle rather than renting it by the minute in the hidden cost of reprocessing context.
Contact our team to discuss context caching options for your workload.
Yes, on the write. Per Anthropic's caching docs, creating a cache entry costs 1.25x the base input rate for the five-minute lifetime and 2x for the one-hour lifetime. Reads then cost 0.1x. A prefix sent twice on the five-minute cache already beats sending it uncached twice; the one-hour write needs two reads to get there. Written and never reused, it costs 25% more on the five-minute tier or 100% more on the one-hour tier.
No. Claude plans and Claude Console API billing are separate products. Pro, Max, and Team include plan limits, while optional usage credits and current Enterprise usage can be billed at standard API rates. Those product-plan rules don't change the prompt-cache multipliers for direct API calls.
Yes. Claude Code manages prompt caching automatically unless it's disabled. It reuses stable system-prompt, project-context, and conversation prefixes, and switching models, compacting or upgrading can rebuild some or all of the cache. Reconnecting an MCP server usually costs nothing. Under deferred tools, which Anthropic's documentation calls the default on supported models, connecting or disconnecting a server, or changing its tool list, appends content without invalidating the existing cache. Reconnection rebuilds the cache only where tool definitions are loaded into the prompt prefix instead, which is not the default configuration.
On OpenAI's own API, GPT-5.6 defaults to implicit caching but also supports explicit breakpoints, so it isn't the purely automatic model Groq runs. On GPT-5.6 and later, the generation that includes GPT-5.6 Sol, first-party writes cost 1.25x, the same premium Anthropic charges on its five-minute tier, and first-party cached input is 0.1x, matching Anthropic's read discount. Both numbers are generation-scoped: on GPT-5.5 and earlier, the cached-input rate is model-dependent, and there is no cache-write charge. The 0.25x and 0.50x read figures usually quoted for OpenAI are OpenRouter's route-specific numbers for its OpenAI providers, not universal OpenAI pricing.
Three usual causes, most likely first. The prefix is below the model's minimum, which fails silently. The prefix isn't byte-identical between calls, usually a timestamp or unstable JSON key order. Or the gap between calls exceeded the TTL, remembering that the clock starts when the previous request started, not when its response finished.