Per-request values above your static content
A cache prefix ends at the first byte that changes. Anything after it pays full price forever.
Prompt caching matches a prefix. The provider hashes your prompt from the beginning and reuses the longest run that is byte-identical to a previous request. The moment it reaches something that changed — a timestamp, a user name, a retrieved document — matching stops.
So a single dynamic value near the top of a prompt disables caching for everything below it. Today's date on line three can cost you the cache on four thousand tokens of instructions, examples and tool documentation that never change.
The fix is ordering, not deletion. Put everything static first — role, rules, examples, schemas — then the cache breakpoint, then the per-request material. It is usually a ten-minute change to a template and one of the largest single savings available.
A useful habit: treat the top of your prompt as immutable and append-only. If you find yourself interpolating a variable into it, ask whether that variable could move to the user message instead.
Today's date is 2026-08-10.
<4,000 tokens of static rules and examples>
User question: {{q}}<4,000 tokens of static rules and examples>
[cache breakpoint]
Today's date is 2026-08-10.
User question: {{q}}Check your own prompt
The analyser checks this pattern along with the other 25, prices each finding against your request volume, and hands back a rewritten prompt. It runs in your browser — nothing is uploaded.
Run the analyserMore on caching
- A cacheable prompt, uncachedReading a cached prefix costs a tenth of sending it again. This prompt qualifies.
- A one-hour cache for a five-minute workloadLonger cache lifetimes cost more to write. They only pay back if you actually reuse them.