A freight desk assistant may read the same operating instructions for every shipment while the shipment record changes on every request. That is a useful place to investigate prompt caching. The engineering question is how much of each request really stays identical, how long it stays reusable, and whether the extra cache-write cost earns its way back.
Consider a fictional assistant with a 6,000-token prefix containing reviewed tools and operating instructions. Each shipment adds 1,000 fresh input tokens. We will compare four requests, using arithmetic rather than an API benchmark. No customer savings or latency measurement is claimed.
Put current business records after the reusable prefix
Claude caches prompt prefixes. Its documented order is tools, system, then messages. An explicit cache boundary can end the stable material before a changing suffix. The default lifetime is five minutes, with a one-hour option; successful reuse refreshes the entry. Minimum cacheable length depends on the model. Check actual cache usage instead of assuming a marker created an entry. Claude: cache boundaries, lifetimes and minimums
REUSABLE PREFIX
tool definitions: shipment-read-v2
instructions: exception-review-v4
explicit cache boundary
FRESH REQUEST SUFFIX
shipment_id: S-204
source_version: 18
current carrier event + observation timeFor this design, I would fetch the latest shipment version for every decision that needs it. A tariff update produces a new policy version and a changed prefix. Keep that change visible even if it causes a miss. Preserving an obsolete rate sheet to improve a cache-hit chart would defeat the purpose of the assistant.
Place the case ID and request timestamp in the changing suffix. Keep tool ordering deterministic. A useful pilot log stores a fingerprint of the reusable prefix and its policy version, so an operator can distinguish a deliberate update from accidental request churn. The application still checks access to every source it reads.
Calculate both writes and reads
The standard Claude Sonnet 5.5 API rates checked on October 19, 2026 are USD 2 per million ordinary input tokens, USD 2.50 for five-minute cache writes, USD 4 for one-hour writes and USD 0.10 for cache reads. The example excludes output, tools, regional modifiers and other pricing options. These API rates do not describe Claude subscription allowance consumption. Claude: current model and prompt-cache pricing
With four uncached requests, the illustrative input cost is 28,000 × 2 / 1,000,000 = USD 0.0560. If all later requests hit a five-minute cache, its prefix costs one 6,000-token write and three reads. The four changing suffixes cost 4,000 ordinary input tokens. Together that is 0.0150 + 0.0018 + 0.0080 = USD 0.0248.
| Request timing | Five-minute input cost | One-hour input cost |
|---|---|---|
| Minute 0, 2, 4, 6; each later request hits | USD 0.0248 | USD 0.0338 |
| Minute 0, 10, 20, 30; five-minute entries expire | USD 0.0680 | USD 0.0338 |
| No caching, either timing | USD 0.0560 | USD 0.0560 |
The one-hour entry costs more to create. In the short burst it loses to the five-minute option, even though both reuse the prefix. Across ten-minute gaps it wins in this example because the five-minute plan pays four writes. Every amount in the table assumes the stated hit pattern; an actual hit count must come from the response, not from the expected schedule.
The gaps are measured between request starts. Claude documents that a cache lifetime begins at the start of the request that writes or reads it. A slow response uses part of that lifetime. Schedule a realistic test with the same generation lengths and pauses that the desk expects. Claude: when the cache lifetime starts
Separate a changed prefix from an unavailable entry
Claude cache diagnostics can compare consecutive requests using diagnostics.previous_message_id. It reports the earliest detected divergence, such as a changed system prompt or tools. The comparison describes request structure; usage.cache_read_input_tokens tells you whether input was actually read from cache. An inconclusive comparison is not evidence of a hit. Claude: diagnostics and actual cache reads
In the fictional desk, suppose a developer adds “current time” before the boundary. The stable-prefix fingerprint now changes on every request. Lengthening the lifetime would leave that defect in place. Move the changing value after the boundary, keep the same model and request configuration for the experiment, and rerun the paired requests.
If the reusable request matches and reads still disappear, investigate elapsed time and the chosen model’s cache requirements. Preserve the observed usage and diagnostics together. First requests and deliberately changed policy versions belong in a separate bucket from unexpected misses, or the dashboard will make normal cold starts look like regressions.
Review cost per completed case
| Test | Record | Decision it supports |
|---|---|---|
| Cold request followed by an identical reusable prefix | Write, read and uncached token counts | Did caching occur? |
| Change only the shipment suffix | Read count and source version in the answer | Can current facts coexist with reuse? |
| Change the policy version | New write and correct revised policy | Does freshness survive optimization? |
| Repeat with short and ten-minute gaps | Actual input charges and request-start times | Which lifetime suits this workload? |
| Slow response or operator pause | Observed misses and completion latency | Does the desk’s real timing match the model? |
Compare equivalent completed cases: the same source evidence, accepted answer criteria and output limits. Include retries and requests that an operator rejects. A cheaper model call that creates more review work can increase the cost of resolving the shipment. Track correction time alongside the API charge, and keep the business-quality threshold unchanged between cache variants.
Start with one stable instruction bundle and one representative workflow. Use a full busy period that includes policy changes and quiet gaps. Select a cache lifetime from that trace, then repeat the comparison when the model or request layout changes. For cached answers stored by the application, review access revocation separately; prefix reuse and replaying a saved answer need different controls. Read: permissions and application answer caches
