Context engineering is deciding what enters a model working memory and what stays out. For coding agents that means the project memory file, which files get read, how much command output comes back, which tool definitions load, and when to clear. It matters more than phrasing because everything in the window is re-sent on every turn, and because irrelevant context measurably degrades output rather than merely costing extra. Four of the six things in a typical window are under your direct control.
- The question is what the model can see, not how you phrased the request.
- Everything in the window is re-sent every turn. Waste compounds quadratically.
- More context is not better. Irrelevant context competes for attention and stale context actively misleads.
- A lot loads before you type anything: system prompt, project memory, skill listing, tool names, git state.
- Naming the files in your prompt is the cheapest technique and the most effective.
/clearcosts nothing./compactis itself a large request.
What is actually in the window
Before your first character reaches the model, a coding agent has already loaded several thousand tokens you never see. Knowing the list is most of the skill, because it tells you which levers exist.
A typical coding session, and who controls each part.
| Content | Typical size | Controlled by |
|---|---|---|
| System prompt and tool definitions | A few thousand tokens | The harness |
Project memory (CLAUDE.md / AGENTS.md) | 500 to 5,000, every turn | You |
| Skill and command listings | One line each, at startup | You, by pruning |
| MCP tool names | Names at startup, schemas on demand | You, by disabling servers |
| Environment and git state | A few hundred tokens | The harness |
| Files the agent read | 1k to 20k each | You, via prompts |
| Command and test output | 200 to 10,000+ per run | You, via scoping |
| The conversation | Grows every turn | You, via clear and compact |
Why more is not better
The intuition that a bigger context window means better answers is wrong in a specific and repeatable way. Four separate things go wrong, and only one of them is money.
- Irrelevant material competes. A model attending to 180k tokens where 20k were relevant is distributing attention across a great deal of noise.
- Stale context actively misleads. A bug you fixed forty minutes ago is still in the conversation, and the agent will reason about it as though it were current.
- It costs on every turn. Not once. Every single turn, for the rest of the session.
- It is slower. More tokens to process before the first output token appears.
There is a fifth failure, and it is subtle
A conversational constraint can be summarised away. Claude Code auto mode treats a boundary you state in chat, such as "do not push until I review", as a block signal, and Anthropic notes that the boundary is re-read from the transcript on every check, so compaction can remove the message that stated it. Their own advice is that a hard guarantee needs a deny rule in settings, not a sentence in the conversation. The same logic applies to any constraint you care about: if it must survive an hour of work, put it in a file, not in a message.
The arithmetic that makes it worth doing
Context waste does not add. It multiplies by the number of turns after the point at which you added it.
A 2,000-token block of dead weight added at turn 1 of a 30-turn session.
| Where it lands | Times re-sent | Tokens billed |
|---|---|---|
| A one-off question | 1 | 2,000 |
| Turn 25 of 30 | 6 | 12,000 |
| Turn 1 of 30 | 30 | 60,000 |
| Project memory file, every session | Every turn, forever | Unbounded |
Caching softens this considerably. On the Anthropic API, as of August 2026, a cache read costs 0.1x the base input rate, so a stable prefix is re-sent at a tenth of list price. Two caveats keep it from being a free pass. Cache writes cost more than plain input (1.25x at the five-minute TTL, 2x at the one-hour TTL), so churning your prefix is worse than never caching it. And the cache expires: for Claude Code as of August 2026 the lifetime is one hour on a subscription and five minutes on an API key, a cloud provider, or once you are drawing on usage credits.
Eight techniques that work
| # | Technique | Why it works |
|---|---|---|
| 1 | Name the files and symbols | Removes the exploration phase, which is the most expensive part of any task |
| 2 | Clear between unrelated tasks | Stops paying for and reasoning about stale material |
| 3 | Keep project memory short and surprising | It is sent every turn; obvious lines are pure waste |
| 4 | Scope command output | Run one test file, not the suite |
| 5 | Filter noisy output in a hook | A grep for ERROR turns a 10k-token log into a few hundred |
| 6 | Delegate verbose work to a subagent | The logs stay in its window; only a summary comes back |
| 7 | Move workflow instructions into skills | Skills load on demand; memory-file lines load always |
| 8 | Compact at task boundaries | A clean thing to summarise produces a clean summary |
The project memory test
For every line in a CLAUDE.md or AGENTS.md, ask: would a competent engineer new to this repository get this wrong? If no, delete it. The agent already knows what your framework does; it does not know that your integration tests need Postgres 16 exactly. Anthropic suggests keeping the file under about 200 lines for the same reason.
The same file, two ways.
| Waste | Worth its tokens |
|---|---|
| "This is a TypeScript project using React" | "src/legacy/ is generated. Edit the .proto, then make gen." |
| "Write clean, maintainable code" | "Errors wrap with %w. Bare returns fail review." |
| "We value good test coverage" | "make test takes 6 minutes. Use go test ./internal/x/... while iterating." |
| "Follow the existing style" | "Do not add dependencies without asking. The lockfile is reviewed." |
Two commands people confuse
/clear drops the conversation and starts fresh
cost: nothing. use it between unrelated tasks
/compact summarises the conversation into a shorter form
cost: a large request, because it reads what it summarises
use it mid-task, when you need continuity
/context shows what is currently occupying the window
use it before you guess at what to pruneMeasuring whether it worked
Context engineering is unusually measurable, which distinguishes it from most advice about working with models. Every signal below comes out of data the CLIs already write to disk.
| Signal | Means |
|---|---|
| Cost per task falling | Fewer exploration turns. It worked |
| Cache read share rising | Stable prefix. Good hygiene |
| One repo costing 3x its peers | That repo is hard to navigate. Fix its memory file |
| Input tokens climbing across similar tasks | Context creep. Clear more often |
| Cache write share rising | You are churning the prefix. Something volatile moved to the front |
| Edit rejection rate rising | Something recently added to context made things worse |
Questions people ask
Deciding what enters a model working memory and what stays out. For coding agents that means project memory files, which files get read, how much command output returns, which tool schemas load, and when to clear the conversation.
Prompt engineering is about phrasing a request. Context engineering is about what the model can see when it reads that request, which for agents matters considerably more because the window is re-sent on every turn.
No. Irrelevant material competes for attention, stale context actively misleads, everything in the window is re-paid for on every turn, and more tokens means slower time to first output.
Context has accumulated enough irrelevant material to compete with the part that matters, and old decisions you have since reversed are still being reasoned about. Clearing between unrelated tasks fixes it immediately.
Naming the specific files and symbols in your prompt. It removes the exploration phase, which is the most expensive part of any agent task and the main driver of turn count.
Anthropic suggests under about 200 lines for CLAUDE.md. It is sent on every turn, so anything the agent could have inferred is pure waste and dilutes the lines that matter. Move long workflow instructions into skills, which load on demand.
Clear between unrelated tasks: it costs nothing. Compact mid-task when you need continuity: it costs a large request, because the model has to read the whole conversation to summarise it.
Much less than they used to. Claude Code defers MCP tool schemas by default, so only names load at startup and schemas arrive on demand. Run /context to see actual consumption rather than pruning servers on the basis of older advice.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.