Most teams calling the Anthropic API are paying full input price for the same tokens on every request, because prompt caching — the feature that serves a stable prefix of your prompt back to you at a tenth of the input rate — is documented, supported across the current Claude model line, and switched on by nothing more than a single cache_control marker in the request body. It is the cheapest line of code most backends will add this year, and in most codebases it simply is not there. This article walks through what the marker does, what the discount is worth, where the prefix has to sit, and how to wire it in whether you call the anthropic api directly or route your traffic through OrcaRouter.
The reason this matters more in 2026 than it did two years ago is the shape of the workloads. Chatbots sent a short system prompt and a few turns of history. Agents send the same long constitution — tool schemas, retrieved documents, project conventions, prior steps — on every single step of a loop that may run for hundreds of calls. The stable part of the prompt has grown from a rounding error into the overwhelming majority of the bill, and without caching that stable part is re-billed at full price every time. You are, in effect, buying the same book once per page turn.
What prompt caching actually does
Prompt caching is a prefix cache. You place a cache_control breakpoint on the last block of the stable part of your prompt — typically the system prompt or the final tool definition. The first request that carries it writes everything up to the breakpoint into a cache on Anthropic’s side, billed at a premium. Every subsequent request whose prompt begins with exactly the same tokens gets a hit: the cached portion is billed at the read rate instead of the full input rate, it is also processed faster because the model does not have to re-read it, and the hit refreshes the cache’s timer. Anything after the breakpoint is billed normally. Two properties follow. The match is literal — token-for-token from the very first token, not “similar meaning” — and it is all-or-nothing: change one token before the breakpoint and everything after it is a miss.
What the discount is actually worth
The rate structure, per Anthropic’s published rate card, comes down to three numbers. Cache writes cost 25% more than base input tokens. Cache reads cost 10% of the base input price. The cache lives for five minutes by default, refreshed on every hit, with an optional one-hour lifetime that costs more to write into. There is also a floor: prompts shorter than 1,024 tokens (2,048 on Haiku-class models) are not cached at all, so this is a lever for long prompts by design.
The arithmetic, not a benchmark: take a 20,000-token stable prefix and 1,000 fresh tokens per call, across 100 calls in a working session. Without caching you are billed for 2,100,000 input tokens. With caching you pay one write of 20,000 tokens at 1.25×, ninety-nine reads at 0.1×, and 100,000 fresh tokens at full price — roughly 223,000 token-equivalents instead of 2,100,000. The prefix spend drops to about a tenth, which is exactly what the 0.1× read rate promises. Your real numbers depend on your hit rate, which is why the last section of this article is about measuring it.
What belongs in the cached prefix
Order is the whole game, because the cache matches from the first token forward. The stable, expensive material goes first: tool definitions (frequently the single largest block in an agent’s prompt), then the system prompt, then any reference documents that do not change between calls. Conversation history comes next, up to the previous turn. The newest user message — the only part that is genuinely new — goes after the breakpoint. The classic mistake is a timestamp or a per-request nonce injected near the top “for freshness”: one changing token in position two thousand busts every token after it, and the team concludes that caching is broken when the cache is working exactly as specified and the prompt is sabotaging it. Per-user personalization has the same effect at scale: if every user’s prompt starts differently, every user gets their own cold cache. Put the shared material first and the personal tail last.
When the one-hour cache earns its premium
The five-minute default is built for tight loops: an agent stepping every few seconds, a streaming UI where each tool result triggers the next call. It is a poor fit for anything with gaps. A code-review queue that processes a repository every twenty minutes, a support inbox triaged once an hour, overnight batch runs against a fixed document set — all of these return to a cold cache and pay the write premium again. The one-hour option bills writes at twice the base input rate instead of 1.25×, while reads stay at 0.1×. The rule of thumb is to choose the TTL by the gap between calls, not by the size of the prompt: if the same prefix will be reused more than a couple of times beyond the five-minute window, the doubled write cost is cheaper than repeated cold writes.
Why teams still leave it off
Nothing about this is secret, so the reasons are structural. The quickstart examples in most SDKs do not include the marker, so it never enters the codebase. Frameworks assemble prompts dynamically on each call, which means nobody actually owns the prefix — it is an emergent property of the framework’s internals. The bill is split across services and teams, so the prefix spend is everyone’s cost and therefore no one’s project. And the write premium looks like a risk on day one, before anyone has measured a hit rate. All four reasons are organizational rather than technical, which is why the fix is usually one engineer spending an afternoon with the usage fields instead of a roadmap item.
How to switch it on and prove it is working
The switch itself is one field, set on the last block of your stable prefix:
Whether the call goes to the API directly or through OrcaRouter, the marker travels inside the request body, so nothing about your routing layer needs to change. Proof comes from the response’s usage object: cache_creation_input_tokens counts tokens written to the cache, and cache_read_input_tokens counts tokens served from it. Watch those two fields over a full day, not a single call — the first request of every session is always a write, so a five-minute sample tells you nothing. If reads stay at zero across repeated calls, something in front of the model is mutating the prefix: a rewritten system block, reordered JSON, or that timestamp. Fix the prefix and the reads appear.
The takeaway
If you are running any workload against the Anthropic API with a prompt longer than about a thousand tokens that repeats between calls — and every agent workload does — prompt caching is not an optimization, it is table stakes, and leaving it off means paying full price for tokens that could be served at a tenth of the rate. The work is one marker, an honest look at what actually sits at the top of your prompt, and a day of watching two usage fields. Turn it on before you touch anything else, because no other change available to you moves the bill this much for this little effort.
