Writing system prompts that cache reliably

Structure the prompt around what stays the same

A system prompt written for readability alone — instructions and context interleaved in whatever order made sense to write — often isn't structured for caching at all, because caching depends on a stable prefix, and stability is a property of order, not just content. Writing a system prompt that caches reliably means deliberately front-loading everything that never changes and pushing anything that varies as late as possible, even where that's not the most natural order to write in from a pure readability standpoint.

The subtle content that invalidates a cache without looking dynamic

Some of the most common cache-breaking content doesn't look dynamic at a glance. A version string that increments on deploy, a build timestamp included "for debugging," an environment name that differs between staging and production but is otherwise static within each — all of these sit quietly inside what looks like a stable system prompt and invalidate the cache on every deploy or every environment switch. Audit a system prompt specifically for anything that changes on a release cadence, not just anything that obviously changes per request.

Serialisation order matters as much as content

Where a system prompt embeds structured data — a list of available tools described inline, a set of configuration values — the serialisation has to be deterministic for the resulting text to be byte-identical across requests. Dumping a dictionary or object without an explicit, stable key order can silently produce different byte output on every request even when the underlying data hasn't changed at all, which invalidates caching for reasons that have nothing to do with the actual content changing.

Personalisation without breaking the whole prefix

A system prompt that needs some genuinely per-user content doesn't have to abandon caching entirely — separating the universal, shared instructions from the personalised portion, and placing a cache breakpoint after the shared section rather than at the very end of the whole prompt, lets you cache the larger stable portion even though the personalised part can never be shared across users. Treating the whole system prompt as one all-or-nothing cacheable unit is a common reason personalisation and caching seem incompatible when, structured correctly, they aren't.

Testing cacheability the same way you'd test correctness

A system prompt's caching behaviour is worth testing explicitly and automatically — send the same request twice and confirm the second one shows a cache read — rather than assumed correct because the prompt was written with caching in mind. Prompts drift over time as they're edited for other reasons, and a change made for an unrelated purpose can quietly reintroduce dynamic content ahead of a breakpoint that used to be stable.

Code review is where a cache-breaking change usually sneaks in

Once a system prompt is caching reliably, the biggest ongoing risk isn't the original design — it's a later, unrelated edit that reintroduces dynamic content without anyone thinking of it as a caching change at all. Adding a timestamp for a logging purpose, or a request id for tracing, feels like a small, safe addition to whoever's making it, and rarely gets flagged in review as something that touches caching unless reviewers are specifically primed to look for it. Calling out, in your own team's review conventions, that edits to the cached portion of a system prompt need a caching-specific check is a cheap habit that prevents a class of regression that otherwise tends to go unnoticed until a bill looks wrong.

See a working prompt-caching implementation guide for the request-structuring mechanics this builds on, and why your prompt caches on one model and not another for the model-specific half of getting caching to actually work in production.