Optimize prompt caching around approved instruction revisions, not around a requirement that the prompt never change. Keep reusable content consistent across requests, place changing task context deliberately and test how a required instruction update reaches the agent. A lower cache-hit rate during a genuine revision can be an expected consequence of sending the right content.
For developers operating recurring business agents, the danger is an optimization target that rewards the wrong behavior. A team may remove a needless timestamp from the beginning of every request and improve reuse. That is useful. Keeping an obsolete classification rule in place merely to preserve the same prefix is a different decision.
Our proposed approach separates avoidable prompt churn from necessary changes. Track the approved instruction revision, inspect what the application actually sends and evaluate both task correctness and cache behavior. The test plan below is a recommendation, not a report of a caching experiment we ran.
A prompt cache is not a stored answer
Prompt-prefix caching reuses processing of repeated input content. It should not be confused with an application returning a previously saved answer to a similar question. This article concerns the former.
Anthropic’s current prompt-caching documentation describes matching identical prompt segments through a cache breakpoint. It recommends placing the breakpoint at the end of a stable prefix when later content varies. It also exposes separate usage fields for cache reads, cache creation and uncached input. These are vendor-documented behaviors for the relevant API, not independently measured results from this publication.
A cache hit therefore tells you something about reuse of the submitted input. It does not establish that the submitted policy is current, that the user supplied the right facts or that the generated answer is supported. If an application keeps sending an outdated rule, efficient processing of that rule does not repair it.
Conversely, changing a request-specific document after the reusable prefix need not mean the entire request is new. Keep the concepts distinct when diagnosing a result: which input changed, which part was reused and whether the new output follows the applicable instructions.
Research supports measurement, not a universal savings forecast
Lumer and colleagues’ January 2026 preprint, Don’t Break the Cache, compares caching strategies on multi-turn DeepResearch Bench agents using web-search tools. The PwC-affiliated researchers measured API cost and time to first token, with a long system prompt and controlled cache-boundary conditions.
Their results show that strategy choice affects latency as well as cost; full-context caching was not the best latency choice in every evaluated configuration. Time to first token measures when the response starts, rather than when the research task is completed.
Those findings concern their particular models, prompts, request patterns and experimental controls. They do not supply a savings estimate for your service or validate the instruction-update workflow proposed here. We have not replicated them. The implication we draw is to compare configurations on representative traffic and separate input-processing gains from total task performance.
Classify the change before trying to prevent it
Anthropic engineer Thariq Shihipar’s April 2026 account of building Claude Code around prompt caching describes stable content before changing content, and accidental cache breaks caused by detailed timestamps and nondeterministic tool ordering. It also discusses passing some updates in later messages. This is vendor practitioner experience from a particular agent harness, not a universal contract for all assistants.
For a business workflow, decide what kind of change you are looking at before removing it:
| Change | Proposed response |
|---|---|
| Tool definitions appear in a different order despite no functional change | Make serialization deterministic and check that the resulting request is equivalent. |
| A request-specific identifier or timestamp appears before reusable instructions | Move it to the appropriate changing context when doing so preserves its meaning and authority. |
| The current task or retrieved source changes | Send the new information; verify that the answer uses it. |
| An approved rule or actual tool definition changes | Deliver the required revision through the supported authoritative mechanism, accepting affected cache rebuilding where necessary. |
| An input is removed only to improve the hit rate | Check whether the task still has the information it needs before accepting the optimization. |
These are design recommendations. The correct location of an instruction depends on the application’s instruction hierarchy and runtime. Do not move a controlling rule into ordinary task data simply because that location is more convenient for caching.
Nor should an older engineering article’s advice about keeping tools stable become a reason to retain access that should change. Verify current product capabilities and enforce actual tool permissions in the application. A prompt layout is not an access-control mechanism.
A hypothetical classification-rule revision
Imagine a fictional internal agent that drafts service-ticket classifications. Its reusable instructions include an approved category list and examples. Request-specific ticket text follows those instructions. Revision A directs a particular kind of request to General Support; revision B introduces a dedicated Access Support category for that same case.
For this example, the application deliberately places the category rule inside the cached prefix. A release that replaces revision A with revision B changes that portion of the input. The team should expect the affected prefix to need new processing rather than treat the resulting miss as a regression to eliminate.
The acceptance case is a ticket whose expected classification changes between the two revisions. Inspect the constructed request to establish that revision B’s actual rule is present. A revision label alone is insufficient if the old text remains underneath it. Then verify that the output uses the new category.
If the application supports a different, authoritative update mechanism, evaluate that mechanism instead of assuming every revision must replace the original prefix. What matters is that the current rule reaches the agent without an unresolved contradiction. Appending a low-priority note that conflicts with a controlling instruction is not a dependable substitute for updating the controlling instruction.
This scenario is invented. It establishes what to test; it does not claim a particular provider produced the correct classification or a measured cache miss.
Test reuse and revision as separate cases
Build a small proposed acceptance set before optimizing a recurring agent:
- First request for an instruction revision. Confirm that the application sends the approved content and record observed cache writes or reads. Do not assume a new session must be cold if the deployment can reuse an existing prefix.
- Repeated eligible request. Hold the reusable content and relevant configuration constant, then inspect the provider’s actual usage reporting. Record timing as well as whether the intended task succeeds.
- Changed task input. Keep the reusable revision fixed but change a ticket or source document. Verify that the new answer reflects the changed input rather than merely reproducing an earlier result.
- Changed controlling instruction. Use a case whose expected answer changes under the new revision. Verify both the constructed request and the resulting behavior, while recording the cache impact.
- Request after reuse is unavailable. Check that the workflow remains correct when caching is absent or no longer available. Caching should improve operation without becoming a prerequisite for answering correctly.
A cache miss is not automatically evidence of an application defect. Eligibility, timing, configuration and provider behavior matter. Likewise, a high reuse rate is not sufficient evidence of a sound release. Record what the service reports and investigate unexpected changes rather than inferring cache behavior from response speed alone.
Keep the operating record small and useful
For each comparison, retain the instruction revision, model and configuration, prompt-layout revision, cache usage, request latency, completion time and task acceptance result. These are proposed operational fields, not an API schema.
Use the provider’s current accounting rules when calculating cost. Include cache creation, reads, uncached input, output and any other charges applicable to the workflow. A lower input-processing bill can coexist with extra retries or more review work, so compare the completed path rather than one favorable request.
You can usually investigate deterministic ordering and revision delivery without retaining unrestricted copies of confidential prompts in general-purpose logs. Use approved diagnostic storage and access controls when full request inspection is necessary. Keep the record sufficient to explain the change without expanding data collection merely for a cache dashboard.
Our guide to review dates for facts in agent memory addresses whether remembered assertions remain valid. Here the separate engineering responsibility is ensuring that the application sends its intended current inputs while optimizing their processing.
Start with one recurring workflow and one instruction revision. Establish a correctness baseline, remove accidental variation and verify reuse from usage data. Then make a deliberate instruction change and show that the workflow adopts it. That second check makes the optimization reviewable when the business rules inevitably evolve.