Under flat per-token pricing, trimming old turns out of an agent's history made 26 of 42 setups cheaper. Under a pricing model that bills cached prefixes at a tenth of the normal rate, it made zero of them cheaper. Every coding agent I know of runs on a provider with prompt caching, so the second number is the one that matters.
That is the headline of The Hidden Costs of Forgetting, a study of trajectory deletion in software engineering agents by Vallecillos-Ruiz, Bouzenia, Pradel and Moonen. Earlier work showed you can randomly delete 75% of the tokens in older turns without hurting resolve rates. This paper asks why that works and whether it actually saves money. It does the first and mostly not the second.
Forgetting is surprisingly harmless, if you wait two turns#
The setup is large for this kind of paper: 42 reduction configurations, 9,400 runs, two agents (Mini-SWE-agent with a single shell tool, and Trae agent with structured viewer and editor tools), both on DeepSeek-V4-Flash over a fixed 100-task SWE-bench Verified subset. Configurations vary what is deleted (reasoning, tool output, or both), how finely (whole turns or tokens), how much (25 to 100%), and when.
The when matters most. With a two-turn delay, 37 of 42 evaluations showed no significant drop in tasks solved against baselines of 72.6 and 74.6. Deleting immediately broke 19 of 42, and one Trae configuration dropped to 5 solved tasks. Deleting all the reasoning text from old turns was often fine. The agent, it seems, mostly needs the last couple of turns of thinking and can live without the rest.
The agent quietly goes back for what you took away#
Accuracy staying flat hides what the agent does to compensate. It re-reads the files and outputs you deleted.
Baseline re-fetch rate: 19 per 100 reads for Mini-SWE-agent, 9 per 100 for Trae agent.
Deleting tool output pushed re-fetch ratios up to 7.5× with the delay and 10.6× without it.
Deleted outputs were re-fetched 1.5 to 5 times as often as retained ones.
Re-fetches reached back a median of 6 to 12 turns, well past the two-turn delay.
So the agent is treating its context as a cache of the repository and refilling it from disk. That is a reasonable behavior, and it is exactly why end-to-end resolve rate is a poor metric for context management. A pass rate that holds can sit on top of runs that got longer: delayed deletion lengthened runs significantly in 21 of 42 evaluations, all of them involving tool output deletion.
There is a second wrinkle. The two agents behaved differently. Mini-SWE-agent, with one shell tool, re-reads files through cat and grep, so its re-fetches are cheap to detect and cheap to do. Trae agent has a structured viewer, and its worst configuration, turn-level deletion of everything at 100%, lost 32 solved tasks. The same deletion policy is not the same policy across harnesses, which is a good reason to test it on yours rather than trust a number from someone else's setup.
Shorter prompts, bigger bill#
This is the part I would put on a sticky note. The authors price runs with input, cached input and output at 1 : 0.1 : 5, and bill only the longest prefix identical to the previous prompt at the cached rate. Deleting something from an old turn rewrites the prompt from that point forward, so everything after it is re-billed at full price.
Under a caching-aware pricing model, none of these 42 evaluations yields lower estimated costs
Total token counts did fall in 31 of 42 delayed evaluations, by up to a third. Full-price input tokens rose in all 42, from about 1.25× to nearly 10×. Twenty-six evaluations came out significantly more expensive, and the worst case was roughly 5× baseline. Token count and cost point in opposite directions.
There is also an easy mistake hiding here: comparing the flat-pricing result to the cached one and thinking the paper found a trade-off. It did not. Under flat pricing the savings were small and mixed, with only six evaluations significantly cheaper and three significantly more expensive. Caching just removed the rest of the benefit. If your provider bills cached input at 0.05 to 0.5 of the normal rate, which is the range the authors cite across providers, the sign of the result does not depend on where in that range you sit.
What I would not conclude from it#
One open-weight model, two agents, 100 public-repo tasks, one run per configuration, random deletion only. The authors say as much. They also note their caching model ignores cache-write premiums, minimum prefix lengths and expiry, and call the estimate a lower bound on real cost, which makes the case against deletion stronger rather than weaker. What I cannot tell from this is whether learned selection or summarization escapes the penalty. Summarization still rewrites the prefix, so I doubt it, but nobody has measured it here.
What changes in how I build#
I used to think of context pruning as free money. Now I would treat the prefix as an asset. Append-only histories, stable system prompts and tool definitions at the front, and compaction done rarely and in big steps instead of trimming every turn. If I do prune, I would measure dollars per resolved task under the provider's real cache pricing, and I would log re-fetch rate next to pass rate.
One concrete test I would run this week: take a Claude Code style loop, log the cached and uncached input tokens per turn, and replay the same tasks with and without a rule that drops old reasoning. If the uncached share jumps, the rule is costing you. The paper gives me a clear prior on what that experiment will show, and it is cheap enough to check instead of assume.
My prediction: the next round of context-management papers will report cost under caching, and a lot of the published savings will quietly disappear.