If you look at the requests a typical business application sends to Claude, most of the tokens are identical from one request to the next: the system prompt, the policy documents, the examples of good output, the tool definitions. Only a small tail at the end changes, such as the customer's question or the document being processed. Prompt caching is the feature that recognizes this pattern and stops billing you at the full input rate for content the platform has already seen. For teams optimizing Claude spend, it is usually the first lever worth pulling, and it is available on all four third-party platforms: Amazon Bedrock, Google Vertex AI, Microsoft Foundry, and Claude Platform on AWS.
How the mechanism works
When you mark part of a prompt as cacheable, the platform stores the processed form of that prefix for a short window. On subsequent requests that begin with the same prefix, the platform reuses the stored work instead of reprocessing those tokens from scratch. You are billed for reading from the cache at a reduced rate compared with fresh input tokens, and there is a modest premium the first time a prefix is written into the cache. The exact rates and cache lifetimes vary by platform and change over time, so check your provider's current pricing page rather than relying on remembered numbers.
Two properties matter for planning. First, caching works on prefixes: everything up to the cache marker must match exactly, byte for byte, for a request to hit the cache. A single changed character early in the prompt invalidates everything after it. Second, cache entries expire if unused, so the savings depend on request frequency. A steady stream of traffic against the same prompt keeps the cache warm; a request every few hours may not.
What the repetition actually costs you
A worked example makes the stakes concrete. Assume an internal assistant that sends a 50,000-token prefix with every request: a system prompt, your product documentation, and a set of worked examples. Assume 1,000 requests per day on Claude Sonnet 5 at the list input price of $3.00 per million tokens.
Without caching, that prefix alone costs 50,000 tokens × 1,000 requests = 50 million input tokens per day, or $150 per day, roughly $4,500 per month at 30 days, before you count a single user question or output token. That entire line item is spent reprocessing text the model has already seen a thousand times that day. With caching, the bulk of those reads are billed at the reduced cached rate instead, which is why teams with long, stable prompts often find caching moves their bill more than any prompt-shortening exercise could.
Making your prompts cacheable
Most caching failures are self-inflicted. The common culprits are dynamic content injected near the top of the prompt: timestamps, request IDs, the user's name, or retrieved documents that differ per request. Each of these breaks the prefix match and forces a full-price reprocess. The fixes are mechanical:
Move anything per-request to the end of the prompt. Remove timestamps and IDs from prompt text entirely; they rarely help the model. If you use retrieval (RAG), keep the instructions and examples in the cacheable prefix and append retrieved passages after the cache boundary. Standardize prompt templates across services so that different features of your application share the same prefix where possible; shared prefixes mean shared cache hits.
Then verify. Every response includes usage figures that distinguish cached reads from fresh input tokens, so your logs can report a cache hit rate per feature. If the hit rate is low, diff two consecutive prompts from the same feature; the first differing byte tells you exactly what to fix.
Where caching fits in your cost program
Caching reduces the price of input tokens you were going to send anyway. It does not reduce output tokens, which are several times more expensive per token, and it does not fix a prompt that is simply longer than it needs to be. Treat it as one layer of a stack: trim genuinely unneeded content first, cache the stable remainder, and route routine work to a cheaper model tier where quality allows. The combination compounds, because tiering multiplies against an already-reduced input bill.
Where to go next
See Cutting Costs with Model Tiering for the next lever in the stack, and Estimating Your Monthly Claude Bill for the worksheet method these examples are built on. The feature matrix shows what else each platform supports.