paper web signal

SWE-Pruner Pro Uses Agent's Own Signals to Cut Tokens 39%

TL;DR

  • The coding agent already encodes which lines of tool output matter, so a separate pruning classifier is not required.
  • A small head reads the agent's internal representations and outputs a keep-or-prune label per line, with a length-aware embedding per tool output.
  • Across two open-weight backbones and four multi-turn benchmarks, the method saves up to 39% of prompt and completion tokens while preserving task quality.

A quiet paper on arxiv this week is worth a slow read if you deploy coding agents in anger, because it undercuts a small industry that has quietly grown up around them, the bolted-on context managers.

The authors, working on a system called SWE-Pruner Pro, argue that the coding agent already knows which lines of a tool's output matter and which are noise. You do not need a separate classifier reading over the agent's shoulder. You can attach a small head to the agent itself, feed it the agent's own internal representations plus a length-aware embedding keyed to each tool output's line count, and get a keep-or-prune label for every line the tool spat back.

The numbers they report are the kind that get budget conversations started. Across two open-weight backbones and four multi-turn benchmarks, the technique saves up to 39% of prompt and completion tokens while preserving task quality. On MiMo-V2-Flash, the SWE-Bench Verified resolve rate does not just hold, it climbs by 3.8%, and long-context Oolong accuracy goes up by 2.2 points. The claim, if it holds up outside the paper's setup, is that pruning does not have to be a tax on capability. A shorter, cleaner context can actually make the model easier to reason for.

Why this matters if you are not writing training code: the running-cost picture for coding agents has been getting worse as tool-heavy loops burn tokens on file listings, stack traces, and shell dumps the model does not need. If the agent can flag its own dead weight, the case for external context management shrinks and the cost per resolved issue drops for anyone running agent stacks at scale.

The honest caveat is that this is one paper on two open-weight backbones, with inference overhead described as 'bounded' rather than in absolute latency, and no visibility into how the approach handles tool-output distributions it has not seen in training. What the abstract does not tell you is whether the same internal signal is present in closed frontier models, or how quickly the length-aware embedding degrades when a production tool set changes.

If it generalizes, the winners are the teams already running agent stacks in production and the open-weight community that can copy the recipe without waiting for a vendor to ship it.