What to inspect
Separate shared instructions from request-specific content. Compare the actual serialized prefix across repeated requests, then use provider-reported cache metrics to evaluate reuse. Prefix stability alone does not establish eligibility or a cache hit.
Worked example
Illustrative layout: shared policy and tool definitions come first; the changing customer question follows. If a timestamp or random request label appears before the shared material, compare the serialized requests before assuming the same prefix is being reused.
Copy the full prompt
Adapt the inputs to your task. Remove private data before sending anything to a model. This page copies text locally; it does not run the prompt.
Audit these three serialized prompts: [PROMPTS]. Identify the longest identical prefix and mark every changing field. Propose a layout with stable instructions first and variable request data later. Do not remove information needed for correctness. List the provider-specific cache eligibility, breakpoint and expiry rules that still need verification. Create a measurement table for cache reads, writes, total tokens, cost and latency.
Review checklist
- Compare serialized requests, not just templates.
- Keep necessary dynamic context accurate.
- Verify eligibility in current provider documentation.
- Measure hits and total cost on repeated requests.
Keep the resource
Download the complete note ↓Markdown · explanation, example, prompt and checklistDownload the prompt ↓Plain text · ready to adaptOpen the full-size visual ↓SVG · scalable reference diagramDocumentation & scope
This is an original workflow template with an illustrative example. It does not report completed model tests or measured performance. Provider APIs can change; check the linked documentation for your exact integration.