Keeping the Prefix Stable

Put what doesn't change in front, what changes behind. Because the cache only works on the prefix, the size of what's lost is decided not by the size of the change but by the change's position.

Problem

A long conversation keeps going, yet the preamble gets rebuilt every single turn. The cause isn't the conversation's content — it's touching the preamble every turn. Add one tool, fix one line in an instruction file, switch models — all small operations, but as long as the position is early, the long conversation behind it becomes a cache miss in its entirety. The content hasn't changed a single character from last time, yet reuse doesn't kick in, and the effective cost just goes up (Official, see in Practice). And the person who made the change can't see when or what they broke.

Context

Applies when:

• The conversation is long and the preamble is large — system instructions, tool definitions, and resident instruction files occupy the head of every request
• The same preamble runs for many turns — the cache only pays off when there's something to reuse it against
• The cost is at a scale worth caring about

Does not apply when:

• A one-shot request. There's nothing to reuse against
• The preamble genuinely needs to change. Keeping a wrong instruction alive just to protect the cache defeats the purpose
• Exploratory work that starts without knowing what it will use. As described below, the official docs' first recommendation — lock in settings up front — simply can't be honored

Boundary with neighboring patterns:

• Session Boundary Design — a direct tension. That pattern says "not cutting means breaking"; this pattern says "cutting means rebuilding." The official docs recommend both at once (see in Practice)
• Read-and-Discard Isolation — expelling volatile matter into a separate context is that pattern. The official docs cite that pattern as a recommendation for this one (see in Practice)
• Resident Context Inventory — reducing what's in the preamble is that pattern; not moving it is this pattern. The act of reducing itself breaks the preamble once
• Matching Thinking Depth to the Task — switching depth is an operation that breaks the preamble (see in Practice)

Solution

Why this works. Everything comes down to the cache working only on prefix match. What gets matched isn't a set — it's a sequence. The question isn't "does it contain the same things" but "is it in the same order, at the same position." Matching follows from the front, and stops at the first point of divergence. Everything behind that point stops being reused, even if it hasn't changed by a single character from last time (Official, see in Practice).

Two counterintuitive things follow from this.

First, a small change can cost more. Fixing one line of an instruction is, in itself, a small operation. But if that line sits early, it drags the long conversation behind it along as collateral damage. The loss is decided not by the size of the change but by its position. The same one-line fix, made near the end, loses almost nothing. The estimate "a small change should have a small impact" runs backward here.

Second, reordering isn't harmless. Same content in a different order is a different sequence. Add nothing, remove nothing, just swap positions, and that becomes a divergence point (the official docs name "a reordered tool definition" as an example of something that breaks the cache; see in Practice).

So the practice isn't "don't change anything." That's impossible — instructions get fixed, files get attached, terminals emit output. The practice is "push whatever changes toward the back." You can't stop change, but you can design where it happens. Order your input by frequency of change, put what doesn't move at the head and what moves at the tail, and the divergence point necessarily moves later.

One more thing, about naming. Whether the preamble stays stable is decided not by the mechanism but by the history of your own operations. The mechanism works on its own — you don't have to invoke anything to make it apply. What breaks it is you. So what this pattern can say isn't "make it apply" but "don't break it" — and not breaking it requires knowing what breaks it.

Trade-offs

Advantages

• Reusing the same preamble lowers the effective cost. The official docs state that "Prompt caching lowers the effective cost of a request by reusing tokens from a previous one" (Official, see in Practice). What goes down is the reusable-token portion, not the conversation's content — the larger the preamble and the longer the conversation, the more stability pays off.
• The preamble not moving is itself a premise other patterns rely on. When tracking what's actually taking effect, a preamble that changes every turn makes it impossible to isolate whether it was the instructions, the model, or the tools that changed. Stability is also the ground for observation.

Costs

• The pressure to fix the preamble makes what needs fixing harder to fix. Fixing an instruction, cleaning up tools, taking inventory of resident content — all of them break the preamble. Keeping a wrong instruction alive to protect the cache is perverse. This pressure is created by this pattern itself and isn't resolved by this pattern alone — the call of what to fix and when to rebuild a broken cache has to come from outside it.
• "Lock in settings up front" doesn't sit well with exploratory work. The official docs' first recommendation is "Lock in settings before you start" (Official, see in Practice). Work you can start only once you already know what you'll use can honor this; work that begins exploring before the model or tools are decided cannot. Forcing compliance when you can't comply means running to the end with the wrong settings.

GitHub Copilot in Practice

What this section's Official quotes actually cover

Everything below describes the VS Code surface. This is the only surface this catalogue could confirm from primary sources — how caching is handled on other surfaces (github.com / Copilot CLI / cloud agent) has not been checked, and so nothing is claimed there. Not having checked isn't the same as it being absent — what can be said here is only "this is how it's written for this surface."

The mechanism — the cache only applies to the prefix

Source: Cache Explorer (retrieved 2026-07-16) Official:

The cache only applies to the matching prefix of a request. As soon as the content of two consecutive requests diverges, everything after that point is a cache miss. Small changes early in the prompt, such as a reordered tool definition or a modified instruction, break the cache for the rest of the request.

The cache applies only to the matching prefix of a request. The moment two consecutive requests' content diverges, everything after that point is a cache miss. And what's named as the thing that breaks it is "small changes early in the prompt" — with a reordered tool definition and a modified instruction given as examples. The three points made in Solution — that it's a sequence, that position decides the loss, and that reordering isn't harmless — are written here in a single sentence.

The effect on cost

Source: VS Code — Language models (retrieved 2026-07-16) Official:

Other factors also affect credit consumption, such as thinking effort (higher effort produces more thinking tokens), context window size, and tool usage. Prompt caching lowers the effective cost of a request by reusing tokens from a previous one.

Prompt caching lowers the effective cost of a request by reusing tokens from a previous one. This is as far as the official docs go on cost. This catalogue doesn't claim a reduction rate or an effect on response speed — the confirmed evidence goes only as far as the mechanism above and this one sentence.

Five official recommendations

The Cache Explorer page lists five recommendations for not breaking the cache Official (same source and retrieval date as above):

• Lock in settings before you start: Switching the model, reasoning effort, context size, or the enabled tools and MCP servers during a session rebuilds the cache. Choose them upfront, or use auto model selection, which switches models only at cache boundaries.
• Keep instructions stable: Changing instructions files or custom agent definitions mid-session breaks the cache.
• Add volatile context late: Place content that changes often, such as file attachments or terminal output, later in the conversation.
• Isolate exploration in subagents: Run research in a subagent to keep the parent session prompt stable.
• Start fresh after a break: Caches expire after inactivity. Start a new session or run /compact to rebuild from a short summary instead of the full history.

The third, "Add volatile context late," is this pattern's own distinctive practice. Put what changes often — attachments, terminal output — later in the conversation, the official docs say. Solution's "push what changes toward the back" shows up here directly as a recommendation.

Four of the five point toward other patterns (or warn against them)

The remaining four correspond one-to-one with patterns this catalogue draws up separately. A single concern — the cache — produced official recommendations that trace this catalogue's own taxonomy from the outside.

Official recommendation (verbatim above)	Corresponding pattern	Direction
Isolate exploration in subagents	Read-and-Discard Isolation	Same direction — isolation keeps the parent session's preamble stable
Start fresh after a break	Session Boundary Design	Tension resolves — once a break intervenes, there's no cache left to protect
Lock in settings before you start	Matching Thinking Depth to the Task	Opposing direction — switching reasoning effort rebuilds the preamble
Keep instructions stable	Resident Context Inventory	Opposing direction — taking inventory moves resident instructions

"Isolate exploration in subagents" gives a direction to the relationship between isolation and caching. The official phrasing is "Run research in a subagent to keep the parent session prompt stable," naming keeping the parent session's preamble stable as isolation's purpose. Expel exploration into a separate context, and the volatile matter it produces never touches the parent's preamble. Isolation works in the cache's favor — the two don't compete.

"Start fresh after a break" is where the tension with Session Boundary Design resolves. At first glance the two collide head-on — that pattern says "cut a long conversation," this pattern says "cutting rebuilds the preamble." Yet the official docs recommend both at once. The reason is right there in the text too: "Caches expire after inactivity." Once a break intervenes, there's no cache left to protect. With nothing to lose, cutting there costs little. The text also names /compact, and even if you do rebuild, it's "rebuild from a short summary instead of the full history" — from a short summary, not the full record.

The tension resolves once you look at the condition. Protecting the cache has value while the conversation continues, and none once a break has intervened. There was never a need to argue "cut or continue" as a general question.

One reminder — as noted at the top, every quote so far is from the VS Code surface, as far as this catalogue could confirm. How caching is handled on other surfaces (github.com / Copilot CLI / cloud agent) hasn't been checked, and not having checked isn't proof of absence. What can be said here is only "this is how it's written for this surface."

Also Known As

Name	Source
Prompt caching	Primary — the name VS Code's official docs give to the mechanism that reuses tokens from a previous request to lower effective cost (source: in Practice section above)
Prefix match / matching prefix	Primary — the same official docs' term for where the cache applies: "the matching prefix of a request." Names the matching method, not the mechanism (source: in Practice section above)
Keeping the Prefix Stable	Descriptive — this catalogue's descriptive name; no primary source uses it

The official Prompt caching is the name of a provider-side mechanism. This pattern is your own practice, and points at something different. Repurposing the mechanism's name for the practice reads as "caching is automatic, so there's nothing for me to do." In fact it's the opposite — what breaks it is what you do. That's why the name here is phrased in the negative: there's no way to make it apply, only countless ways to break it.

Related

• Read-and-Discard Isolation — works in the same direction. Isolating exploration into a subagent keeps the parent session's preamble stable. The official docs cite this as a recommendation for this pattern ("Run research in a subagent to keep the parent session prompt stable"; see in Practice). What that pattern expels from the main context is, from this pattern's view, volatile matter that would break the preamble. The same operation is justified for different reasons
• Session Boundary Design — tense, but the official docs state both hold. That pattern says "not cutting means breaking"; this pattern says "cutting means rebuilding." It resolves because "Caches expire after inactivity" — once a break intervenes there's no cache left to protect, and cutting there costs little (see in Practice). Which one applies depends on whether a break has intervened
• Resident Context Inventory — the preamble's main content is resident matter. Reducing it is that pattern; not moving it is this pattern. A direct tension — the official docs recommend "Keep instructions stable" (see in Practice), and taking inventory violates that by definition. The tension doesn't disappear, but inventory-taking is a one-time event, and a broken cache can just be rebuilt
• Matching Thinking Depth to the Task — switching depth is an operation that breaks the preamble. The official docs name reasoning effort as a target of "Lock in settings before you start" (see in Practice). Depth is cheapest when decided before you start
• If reading just one more next: Resident Context Inventory — once you want to count what's sitting in the preamble, read this next