A coding agent resends its whole working history to the model on every turn: what it was thinking, what commands it ran, and every file and test log those commands returned. The history grows as the agent works, and so does the bill. The obvious fix is to trim the old parts, and earlier research had found that randomly throwing away most of an agent's older history barely changed how many tasks it finished. That result has been taken as permission to compress.

A team at Simula and CISPA ran a more systematic test. They varied what gets deleted (the agent's reasoning, the output of its tools, or both), how much, in what pieces, and how soon, across 42 configurations on two open-source agents and real GitHub issues. Then they looked at what the agents did afterwards and what each run would have cost.

Part of the earlier result was reproduced. Wait a couple of turns before deleting anything and most configurations solved about as many tasks as the untouched agent. Delete content the moment it is produced and success dropped sharply. In the worst cases one agent repeated the same directory listing until it hit its turn limit.

The agents that kept succeeding did extra work to get there. When an agent lost a file it had read, it went back and read the same file again. Outputs that had been deleted were fetched again far more often than ones that were kept, while re-reading of kept content stayed at its normal rate. The work did not go away. It moved into extra turns, so runs got longer even when the final score held steady.

"Selective re-fetching shows why successful execution after deletion does not establish that the removed content is unnecessary."

The cost results run the other way. Priced as though every input token costs the same, trimming looked like a saving in 26 of the 42 delayed configurations. Priced the way major providers actually bill, where the repeated start of a prompt is cached and charged at a steep discount, not one configuration came out cheaper than leaving the history alone, and most were significantly more expensive. The reason is mechanical. A cache only matches a prompt up to its first changed word, so rewriting an old turn throws away the discount on everything after it. In the untouched runs, cached input was already about half of the total bill. That is the money deletion puts at risk.

"We find that token counts and flat pricing overstate what deletion saves, so a compression approach should be evaluated against the uncompressed agent with its prefix cache."

The study has limits, and the authors list most of them. The costs are estimates rebuilt from logs on self-hosted hardware, not invoices. The pricing model assumes every cache lookup hits and ignores the premium some providers charge to write to the cache, and the authors say plainly that this does not establish how much more expensive deletion would be with any particular provider. It used one model and a modest sample of tasks. The deletion was also random. The study could not establish whether the smarter approaches products actually ship, such as summarising history or compacting it once every so often, escape the same trap. The authors expect any rewrite to pay the same penalty, but that is a prediction, not something they measured.

That gap is where this finding is most likely to be over-read. It does not show that context compaction is a mistake. Agents on long tasks still run out of room, and one infrequent rewrite is a different thing from rewriting the history on every turn. What it does show, on this evidence, is that the number vendors usually quote for compression, the share of tokens saved, is the wrong number. A tool can send a third fewer tokens and still cost more, which suggests token savings alone should never settle the question.

For a team paying for agents, the practical step is to read the bill the way the provider writes it. Track how much input is served from cache, not just how many tokens went out, and treat any feature that edits history as something to measure before turning on. When a vendor claims a percentage saving from context management, ask whether it was measured with caching switched on, and whether tasks took more turns to finish. Judging an agent on success rate alone is how the longer, costlier runs stay invisible.

Sources

  1. Vallecillos-Ruiz, F., Bouzenia, I., Pradel, M., Moonen, L., "The Hidden Costs of Forgetting: A Study of Trajectory Deletion in Software Engineering Agents" — https://arxiv.org/abs/2610.35496