RSCH-001Published
Context Management in Coding Agents
Larger context windows did not make coding agents proportionally more reliable. The engineering problem is deciding what the agent should see, when it should see it, and what that context costs.
Who this is for. For software and agent engineers working on multi-step repository tasks. Assumes comfort with tests, CI, APIs and production trade-offs.
The finding in 60 seconds
The context window is an attention budget, not a bucket.
Chroma tested 18 models across eight lengths and found performance generally degraded as input grew, with non-uniform, model-specific curves S. Correct but irrelevant tokens can still reduce performance.
Subtraction beats addition, and the evidence is lopsided.
5K tokens of targeted retrieval beat a 100K summary P. Masking matched summarisation at lower cost S. Fewer tools beat more tools S. A first audit should test for waste before changing strategy.
Compression damage shows up as unreliability before it shows up as lower accuracy.
Compressed agents become intermittent: they solve a task, then fail the same task on a rerun S. Teams measuring single runs conclude compaction is free until production disagrees.
The cache can flip the sign of an optimisation.
In the worked price model, a 24% token cut that made the prefix dynamic raised cost 6.9× C. Token count alone is not a cost model.
There is a stopping point.
About 16 hours of sequenced work, most of it deletion, covers the large majority of the benefit. Past the stop rule, your binding constraint is somewhere else.
Choose your path
Pick the entry point that matches the time you have. Every path ends with something you can do.
Recommended for working engineers
The 71-minute engineer core
8 chapters carry the complete argument from mechanism to measurement to an operating plan. The remaining chapters are evidence, catalogs and reference material to open when the decision in front of you needs them.
- 1Why more context can hurt coding agentsWhat is context, mechanically, and when does adding more make coding agents less reliable?10 min
- 2Anatomy of a coding agent's contextWhere do the tokens in a coding agent's context actually go, and which parts can you control?6 min
- 3Choosing your methods: a 55-minute procedureGiven my own agent and workload, which method should I adopt first, and in what order after that?5 min
- 4Retrieval: how code should enter contextShould code enter context by grep, embeddings, the symbol graph or agentic search, and what does the evidence actually say?9 min
- 5Compaction, offload and memoryHow do compaction, offload and memory lose information, what does that cost in measured terms, and what should you do with your wiki?15 min
- 6The tool surface: MCP, skills and progressive disclosureHow much context do tools, MCP servers and skills consume, and what does a healthy tool surface look like?8 min
- 7Evaluating a context changeHow do you prove a context-management change helped, with what statistical design, and at what cost?9 min
- 8Your optimisation planGiven everything so far, what exactly should I do, in what order, and when should I stop?9 min
Why this research exists#
When a coding agent fails on a real repository, the transcript often looks reasonable. The decisive fact may be behind a compaction boundary, displaced by unused tool definitions, or contradicted by a signature the agent invented earlier.
Those failures are quiet, and they are mostly context failures. This research asks what should be in a coding agent's context at each step, what should not, who decides, and how you would know the decision was right.
One constructed first-measurement example looks like this:
One 152K-token mid-session context (illustrative)
- System prompt9,000 · 6%
- Tool definitions38,000 · 25%
- Instruction files6,500 · 4%
- Skill descriptions1,800 · 1%
- Retrieved code22,000 · 14%
- Tool results58,000 · 38%
- Agent messages12,000 · 8%
- User turns1,700 · 1%
- Summaries3,000 · 2%
View data
| Segment | Tokens |
|---|---|
| System prompt | 9,000 |
| Tool definitions | 38,000 |
| Instruction files | 6,500 |
| Skill descriptions | 1,800 |
| Retrieved code | 22,000 |
| Tool results | 58,000 |
| Agent messages | 12,000 |
| User turns | 1,700 |
| Summaries | 3,000 |
Everything else in this research follows from taking that picture seriously: measure first, delete what is dead, shape what is loud, make every loss reversible, and stop when the numbers say your constraint has moved elsewhere.
The learning path
Five parts, one arc: understand the problem, learn the methods, measure them, make the hard calls, then act. Each chapter answers one question.
- Part I
Understand the problem
What context is mechanically, when more of it makes agents less reliable, and where the tokens actually go.
- Part II
The methods
The ten methods that survive scrutiny, how to choose among them, and the four surfaces where context is spent.
- 3Ten methods that survive scrutinyWhich context-management methods survive scrutiny, why does each work, and what does each cost?23 min
- 4Choosing your methods: a 55-minute procedureGiven my own agent and workload, which method should I adopt first, and in what order after that?5 min
- 5Retrieval: how code should enter contextShould code enter context by grep, embeddings, the symbol graph or agentic search, and what does the evidence actually say?9 min
- 6Compaction, offload and memoryHow do compaction, offload and memory lose information, what does that cost in measured terms, and what should you do with your wiki?15 min
- 7Sub-agents and isolationWhen does splitting work across sub-agents help, when does it destroy the task, and how can you tell in advance?8 min
- 8The tool surface: MCP, skills and progressive disclosureHow much context do tools, MCP servers and skills consume, and what does a healthy tool surface look like?8 min
- Part III
Measure it
How to prove a context change worked, what to track, and what context really costs once the cache is priced in.
- Part IV
Decide and avoid
The hard calls with no clean answer, the ways context management fails, the traps that look like hygiene, and real cases.
- 11Twenty-five hard callsWhich context decisions have no clean answer, and how do you decide them for your own situation?12 min
- 12Forty-four failure modesHow does context management fail, what is the tell for each failure, and how do you contain it?8 min
- 13Sixteen antipatternsWhat looks like good context hygiene but is not, and how do you tell the difference?8 min
- 14Eight case studiesWhat do these decisions look like on real, documented incidents, including ones where the change made things worse?10 min
- Part V
Act on it
A sequenced 16-hour plan, a scored diagnostic, daily habits and the tooling landscape.
- 15Your optimisation planGiven everything so far, what exactly should I do, in what order, and when should I stop?9 min
- 16The diagnostic: score yourself, get one actionWhere does my team stand on context management today, and what is the single next thing to do?4 min
- 17Sixty-two habits that compoundWhat small, daily practices pay for themselves, and when does each one apply?6 min
- 18The tooling landscapeWhich open-source tools, plugins and local MCP servers improve context use, and which are worth adopting?8 min
- Part A–B
Reference
Copyable templates and the full list of falsifiable lessons.
Reference
How to read the evidence
Every non-obvious number carries a label. Click any label to see its source rules.
- Sourced — A study, paper, or first-party engineering write-up with a stated method
- Practitioner-reported — A credible operator or project account without a published method
- Derived — Follows from a labelled claim by stated reasoning, not independently measured
- Composite — A constructed illustration, not a real incident