Prompt caching saves money when the prefix is reused
Prompt caching economics depend on repeated use of stable input. Model cache writes, reads and misses before treating a headline discount as a project saving.
By 
Paul. AI and agentic engineering
A cheaper cache read helps only when a request can actually reuse the cached input. For an AI application, the useful cost question is how often a stable prompt prefix is reused before it expires or changes. A large prompt sent once can be a poor caching candidate even when the advertised read discount looks attractive.
Looking back from November 2026, Anthropic's release-note entry for 14 August 2024 establishes the public beta of prompt caching. It does not supply a complete historical bill for an arbitrary application. The engineering decision should begin with a workload model, then use the terms applicable to the chosen model and date.
The chronology limits the arithmetic
The old announcement address now redirects to a Claude resource page displaying 14 August 2025 and an update dated 17 December 2024. The page discusses cache write and read pricing, but that mixed chronology is insufficient to reconstruct every original August 2024 condition from the current page alone.
Exact historical dollar prices and cache durations are therefore omitted here. The distinction matters: a retrospective can explain the mechanism without presenting today's documentation as a frozen launch contract. The examples below use invented accounting units, clearly separated from vendor prices. They are a proposed decision model, not measurements of an AL+ application.
Start by dividing input into the part that can remain identical across requests and the part that changes for each task. A stable instruction block followed by a changing question is a candidate arrangement. Whether a particular request qualifies depends on the provider's matching rules and applicable limits. Similar meaning is insufficient evidence of an actual cache hit.
Count the first use too
For a deliberately hypothetical example, assume sending the reusable block normally costs 100 units. Assume creating a cache entry costs 140 units and reading that block from cache costs 20 units. These figures are chosen to explain the calculation; they are not Anthropic rates from any year.
For one use, ordinary input costs 100 and the cached route costs 140. There has been no saving. For two uses of the same block, with the second qualifying as a read, the comparison is 200 against 160. Reuse changes the conclusion. With these assumptions, the cache must receive at least one successful read to repay its initial premium.
For N uses, of which the first creates the entry and all later uses hit it, compare N × 100 with 140 + (N − 1) × 20. That simplified expression excludes changing input, output generation and any other charges. Include those separately in a real estimate; a discount on one input component is not the same percentage reduction in the whole bill.
Now change the workload. If every request creates a different reusable block, each costs 140 under the hypothetical cached route. A busy application can therefore spend more even while an individual cache read remains cheap. Total request volume does not establish useful reuse of the same eligible content.
Time and prompt construction affect the result
A stream of requests spread across many customers may contain little repetition within any applicable cache lifetime. Concentrated work on the same material may behave differently. Estimate reuse by stable block and by time, rather than dividing total daily input by a theoretical cache size.
Changing the beginning of a prompt can also undermine the proposed arrangement. If every request places a timestamp, a unique identifier or customer-specific material before the shared instructions, inspect whether the intended reusable prefix still matches. These are illustrative construction risks to verify against the chosen API, not claims about a measured failure in a deployed system.
Keep business correctness ahead of hit rate. If the instructions or source documents change, the application must use the appropriate version. Preserving old content merely to maintain reuse can produce cheaper wrong answers. Give changed instructions a deliberate version and assess their costs as a new workload.
A shared prefix must also contain only material appropriate for its intended requests. Cost optimization does not justify merging customer context or removing access restrictions. The application decides what information belongs in each request before asking whether repeated processing can be avoided.
A cache hit says nothing about the answer
Caching input concerns the cost and processing of repeated context. It does not establish that the context is relevant, current or sufficient to answer the question. A successful read can repeatedly supply the same incomplete policy document. A correct answer may still require a source lookup or a human decision.
That makes this a different question from choosing retrieval instead of a long context window. First choose what information the task requires and how it is selected. Then examine whether stable portions are repeated often enough to justify caching. Combining the decisions too early can make an accounting optimization dictate the information architecture.
The strongest objection to explicit cache planning is its own implementation cost. For a low-volume application with mostly unique requests, the likely saving may not pay for extra prompt-version management and diagnosis. Ordinary requests can be a reasonable choice. The provider feature being available is insufficient reason to build around it.
Ask for workload evidence
For an AI agent project, request an estimate that separates normal input, cache creation, qualifying reads and output. Then ask which observed or proposed request pattern supports the reuse assumption. A pilot can inspect usage categories and actual charges without inventing an elaborate benchmark suite.
Treat the estimate as conditional until the application demonstrates that reuse. Keep a comparison with ordinary requests and revisit it when instructions, documents or traffic patterns change. The useful saving is the reduction in the bill for correct work, after write costs and misses, rather than the discount attached to the cheapest possible read.