A coding agent is a model plus a harness: a plan it can revise, a set of actions it can take, and a policy for what to throw away when the window fills. Hold the model fixed and ablate the harness over 176 matched settings, and the scaffolding is worth 35.7 points of solve rate at a 32k budget and 2.7 at 128k. The awkward part is the sign: the plan and the curated toolkit that rescue a small model quietly cost a large one time and money.
Harnesses are normally compared whole — one vendor's agent against another's — which tells you nothing about which part did the work. This study takes one lightweight harness apart instead and varies three components independently: whether the agent keeps an explicit plan it can rewrite, what actions it is given, and what happens to the transcript as the window fills.
Everything else is fixed: four models spanning a 30B, a 120B and a 550B in one family plus a mid-size model from another, 500 human-verified repository issues, 89 end-to-end command-line tasks, and context budgets from 32k to 128k tokens. Step through the knobs.
Read the grid before the results: a claim about harnesses that holds for one model at one budget is not a claim about harnesses. Every finding below is a crossover, not a ranking.
The first knob is the one with the largest effect and the shortest shelf life. With no management at all, the agent simply keeps appending tool output until the window overflows and the run dies — at a 32k budget that is how 78.7% of repository-issue runs end. Give it any management policy and the overflow failures go to zero at every budget tested.
Flip the budget and watch the gap collapse.
So most of what context management buys at a tight budget is not smarter recall — it is not dying. The managed runs also get much longer room to work: median trajectory length at 32k goes from 20–30 turns unmanaged to 50–180 managed, without the agent behaving differently in kind. If you are running a 128k window on a mid-size codebase, this whole component is worth under three points and you should spend your attention elsewhere.
Five policies were compared, from doing nothing through to a staged combination. The interesting result is not which scores highest — on success they are close — but which gets there cheapest, and how little the clever-sounding option gets used.
The staged policy — elide stale tool output at a soft threshold, call the summariser only at a hard one — posts the lowest mean cost in seven of eight model-and-benchmark panels while matching the others on success. Meanwhile the recoverable archive, where elided content is stashed and the agent can ask for it back, is dead weight: across 64 settings that offered it, 56.3% never called it once, the median call count is zero, and it is worth 0.36 points over plain elision on average and −1.12 on terminal tasks. Stronger models essentially never reach for it.
Here is the finding that breaks harness advice copied between projects. An explicit plan and a curated file-editing toolkit are scaffolding: they constrain what the model has to invent. For a small model that is worth a lot of solved tasks. For a strong model the same scaffolding mostly costs turns and tokens, and the shell it was being protected from turns out to be the cheaper interface.
Pick a model and read both knobs.
The mechanism shows up in the trajectories. Planning keeps a weak model moving long enough to reach its first edit — and multiplies its turn count by nearly four on repository issues — while for a strong model it mostly trims the aimless verification that happens after the edit is already right, which is where the roughly 30% cost saving comes from. A shell lets a capable model pack several operations into one command, cutting tool calls by about a third and re-patching of the same file from 4.6 attempts to 1.5; the same shell leaves a weaker one wandering, with a third of its repository runs ending without a single edit.
Two dials decide most of it: how much window you can afford per run, and how strong the model driving it is. Set them and the paper's own crossovers give you a default configuration — then re-run this the next time you change models, because the answer moves with them.
None of this is a ranking of agent products. It is a reminder that three of the knobs you already own move the numbers by more than most model swaps do, in directions that depend on which model you swapped to.