Prompt and Context Design for Cache-Friendly Claude Agents

Every token you add to an agent's context is a decision with two costs: it competes for the model's attention, and it shapes whether your prompt cache hits or misses. Most engineers optimize the first cost and ignore the second, then wonder why their agent is both unfocused and expensive. Good context design treats relevance and cacheability as the same discipline: put in what's stable and high-signal, leave out what's volatile and low-signal, and place everything where its rate of change belongs. This post is about making those choices well.

The core question: stable signal or volatile noise?

For every candidate piece of context, ask two things. Does the model actually need it to do the task well? And how often does it change? Those two axes sort everything you might include. Stable, high-signal content — the system prompt, behavioral rules, durable project facts, tool contracts — is the ideal cargo: it earns its place by helping the model and it caches beautifully because it doesn't change. Volatile, low-signal content — a running clock, verbose logs, transient status chatter dropped high in the prompt — is the worst of both worlds: it dilutes attention and it breaks the cache.

The design move is to be ruthless about the bottom-left quadrant. If something changes every turn but rarely changes the answer, it probably shouldn't be in context at all, and certainly shouldn't sit above your cache breakpoints. The goal is a context that is dense with durable signal and thin on per-turn churn.

What to put in, and where

Lead with the system prompt: the agent's role, its hard constraints, its output expectations. This is invariant and high-signal, so it anchors the top of the prompt and the front of the cache. Next come tool and MCP schemas — the model needs them to act, and they're stable within a session. Then durable project context: directory structure, key conventions, the handful of files that matter, ideally pulled from a memory file that changes only when the project genuinely does. Only after all of that does the live transcript begin, growing turn by turn at the bottom.

The ordering isn't aesthetic; it's the whole game. Because the cache matches an exact prefix, putting your most stable, highest-value content first means it forms the longest reusable segment. Every turn after the first reads that segment for pennies, and the model's attention lands on durable signal rather than scrolling past noise to find it.

flowchart TD
  A["Candidate context item"] --> B{"Helps the task?"}
  B -->|No| C["Leave it out"]
  B -->|Yes| D{"Changes every turn?"}
  D -->|No, stable| E["Place high, inside cached prefix"]
  D -->|Yes, volatile| F{"Truly needed each turn?"}
  F -->|No| C
  F -->|Yes| G["Place low, in volatile tail"]
  E --> H["Long warm cache + dense signal"]
  G --> H

What to leave out, and why

The harder discipline is exclusion. Leave out content that doesn't change the model's behavior: exhaustive logs when a summary would do, entire files when the model needs one function, boilerplate it already understands. Every excluded token is attention preserved and prefix kept lean. Long context isn't free even when it's cached — a bloated prefix still costs cache-read tokens on every turn and still gives the model more haystack to search for the needle.

Especially leave volatile values out of the stable region. A timestamp, a request ID, a per-turn activity summary injected into the system prompt feels helpful but silently rewrites the cache on every call and buys you almost nothing in answer quality. If a value genuinely must be present and genuinely changes per turn, push it to the tail near the latest message, where churn is already expected and already paid for. The system prompt is sacred ground; keep moving parts out of it.

Designing for retrieval and dynamic context

Agents often pull in dynamic context — retrieved documents, fetched file contents, search results. The design question is when and where to inject it. If a retrieved set is stable for a stretch of the conversation, inject it once in a fixed order and let it become a cached block; don't re-fetch and reshuffle it every turn, which would churn the cache for everything downstream. If it's genuinely per-turn and per-query, keep it in the tail and accept that those tokens are full-price by nature.

A useful frame is to distinguish "reference" context from "working" context. Reference context — docs, schemas, conventions — is stable, goes high, and caches. Working context — the current file under edit, the latest result, the user's newest instruction — is volatile, goes low, and doesn't. Designing the boundary between them deliberately is most of what good context engineering is.

Compaction: trimming without cold starts

Over a long session, even a well-designed context grows. The instinct to prune is right; the method matters. Don't edit or delete earlier turns in place — that cascades a cache invalidation forward and forces a costly rewrite of everything after the edit. Instead, when the transcript gets heavy, summarize the older portion into a compact new block and append it at the end, then continue from there. You pay one deliberate rewrite and gain a leaner ongoing prefix, rather than paying repeatedly for a context that grew without bound. The principle from start to finish is the same: build context append-only, keep the stable part stable, and spend your tokens on durable signal. Do that and your agent stays both sharp and cheap, turn after turn.

Frequently asked questions

How do I decide what goes in context?

Score each item on two axes: does it help the task, and how often does it change. Keep stable, high-signal content high in the prompt where it caches; push genuinely-needed volatile content to the tail; drop anything that's both volatile and low-signal entirely.

Why is putting a timestamp in the system prompt a problem?

Because the system prompt sits inside the cached prefix, and a timestamp changes every turn. That single changing value invalidates the cache for everything below it, forcing a full rewrite while adding almost nothing to answer quality. Keep per-turn values in the volatile tail.

Should I just put everything in the 1M-token window since Claude can hold it?

No. Even cached tokens cost something to read each turn, and a bloated context dilutes the model's attention. Large capacity is a tool for the rare case that needs it, not a license to skip curation. Dense, stable context beats exhaustive context.

How do I trim a long conversation without a cold start?

Summarize the old portion into a new block appended at the end, rather than editing history in place. Editing the past cascades a cache invalidation forward; appending a summary costs one rewrite and leaves you with a smaller, cheaper prefix going forward.

Bringing agentic AI to your phone lines

Sharp context design is what lets an agent stay on-topic and fast during a live conversation. CallSphere's voice and chat agents carry a dense, stable context through every call, using tools mid-conversation and booking work around the clock. Listen in at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.