Assemble cached prefixes by stability

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Repeated policy/document analysis runs on a host whose prefix-cache contract has been verified. Teaching request N is request_id=r1 → policy-v2 → document-a → question-1; N+1 begins with r2. A changing ID ahead of shared material may break reuse. This article discusses assembly/checks without paid API calls.

Mechanism

Trace inputs in the final sent payload and classify stable global, session-varying and per-request content. Put stable policy/document first and unique ID/question last under the host contract, with supported explicit cache boundaries when needed. Compare adjacent rendered overlap and inspect read metrics plus eligibility/readiness. Update changed content/permissions rather than preserving stale rules for cache hits.

Bad example

Insert a fresh request_id ahead of policy and document, then add a cache marker. Since policy meaning matches, claim guaranteed cache hits and a fixed cost saving.

Good example

Under the verified host contract, assemble policy-v2 → document-a → supported shared boundary → request_id/current question. Compare final N/N+1 overlap and relevant system/tools/history changes, not just templates. Inspect eligible subsequent-request cache reads. For zero reads, check eligibility, expiry, readiness and payload differences instead of promising price or hit rate. Use synthetic inspection material without logging secrets.

Why the change matters

Caching compares the host-defined rendered region; semantic similarity or marker existence does not establish reuse. Moving variation to the tail makes stable material easier to preserve, and observed metrics determine actual reuse. A successful response alone does not prove caching.

Observable expectation

The teaching diff shows policy-v2/document-a shared while r1/r2 and questions change after the boundary. Inspect definitions/history for accidental overlap edits too.

An illustrative report may say the structure matches the contract but hits are unmeasured. Only real read records support a hit claim; zero reads require condition-aware diagnosis rather than automatic byte-drift attribution.

Limits

Keys, normalization, boundaries, lifetime and readiness vary by provider. Frozen beta/model/pricing facts are not current claims. Preserve privacy, authorization, freshness and independent reviews before optimizing; do not merge distinct sessions or reviews for cache reuse.