Everyone I know who builds coding agents is trying to shrink tool output. Truncate the build log, summarize the grep, compact the context. A paper on TurnCost re-scores 600 public agent trajectories and says we are optimizing the wrong thing: turn count explains 84% of the variance in log trajectory cost, mean observation size explains 4%.
The authors, Pramod Kumar and Raj Kumar Pandey, did not run new agents. They took 150 trajectories each from four cells (OpenHands and SWE-agent, crossed with Qwen3.5-122B-A10B and Minimax-M2.5) in the public Open-SWE-Traces corpus, built from SWE-rebench-V2, which spans nine languages. They simulated prefix caching from the transcripts and re-priced everything.
Your bill is a count of turns, not a count of tokens#
The observations people complain about are rarer than they feel. Median tool output is 118 to 286 tokens. The giant build log that motivates most compression work shows up around the 99th percentile (5,194 to 28,604 tokens depending on the cell).
Then there is caching. In a loop, the whole prefix is re-sent every turn, and it is almost always a cache hit.
98.1–99.0% of input tokens were cache hits under near-ideal caching.
Flat input pricing overstates loop cost by 6.5× to 7.8×, mean 7.14×.
The overstatement grows with loop length: 5.33× under 40 turns, 7.99× above 130.
At 90%, 75% and 50% cache efficiency it falls to 4.0×, 2.4× and 1.45×.
That last line matters. If your provider or your harness breaks the cache, all of this changes. I would check my own cache hit rate before believing any cost model, including this one.
An oracle compressor saves half, and a dumb truncator gets most of the way there#
The paper gives compression its best case: an oracle that shrinks every observation to 5% of its size saves 47.8–60.3%. Real methods land well below that. Deterministic truncation matched or slightly beat out-of-band delegation to a summarizer in all 20 cell and threshold combinations, with the largest gap at 0.17 percentage points. In-band swapping saved 14.7% at a 200-token threshold and 0.4% at 5,000.
So the fancy summarizer sub-agent buys you roughly nothing over cutting the output off. I find that easier to believe than most results in this area, because the summarizer itself costs turns.
Cheap-model delegation has a break-even you can compute#
The authors derive a closed-form condition for handing turns to a cheaper model. In the simple limit it reduces to the weak model's input price divided by the strong model's cached-read price. With their worked example ($3.00 list, $0.30 cached, $0.15 weak), delegation pays off once more than 0.5 turns remain. Use list price instead of the cached price and you understate the threshold by 10×.
Delegation raised cost in half of the evaluated settings, close to where the formula predicted. If you route work to a small model in a Claude Code style sub-agent setup, price it against cached reads, not the rate card.
Truncation with a hint changes what the agent does next#
One detail I liked: truncation markers appeared in only 518 of 56,164 observations (0.92%), but they touched 367 of 600 trajectories. After a guided truncation, with a recovery hint, 76.9% of next actions narrowed the query. After bare truncation it was 44.0%. No agent repeated the identical command. Telling the agent how to ask for less is cheap and apparently works.
Why this fits how agent loops actually behave#
Think about what a long run looks like. The agent reads a file, edits, runs a test, reads another file, edits again. Each step is small. The trouble is that every step is also a new full-prefix read, and the thing at the end of the run is a very long chain of those. The paper's decile table shows the median cost per turn is tiny, 0.005 in normalized units, while the median trajectory cost climbs from 0.138 in the cheapest decile to 0.978 in the most expensive. Edit observations average 787 tokens against 294 for reads and executions combined, so edits are the fat ones, but they are not where the money goes.
It also reframes what a good harness does. A stop condition that fires one turn earlier, or a plan that avoids a second exploratory pass over the same module, is worth more than a clever compactor. That is a spec and prompting problem as much as an infrastructure one.
What I would not conclude from it#
The authors are straightforward about the limits, and they matter here.
The turn-count association is partly mechanical.
Cost is a sum over turns, so some correlation is guaranteed. They argue the exponent above 1 (1.23) and the negative observation-size slope go beyond that, and I buy it, but R² of 0.844 is not a causal claim. They also say they do not show turns can be removed without hurting task success. The only quality evidence is a 60% vs 58% pass rate from a prior method. The corpus drops runs that hit the iteration cap, which cuts the right tail of turn counts. Costs are normalized, not dollars, and only open-weight models are covered.
What I am changing#
I will log turns per task and cache hit rate before I touch another compression feature. If the expensive runs really are the long ones with small observations, the lever is plan quality: better specs, tighter stop conditions, fewer exploratory reads. My bet is that the next round of agent cost work stops asking how to shrink observations and starts asking which turns never needed to happen. The paper's own line on why: removing a redundant turn also removes every later re-read of it.