Most multi-turn coding agents struggle with long tool outputs: they raise latency and token cost, yet relevance varies line-by-line. SWE-Pruner Pro's surprising insight is that a coder LLM already encodes relevance internally while reading tool output — you don't need a separate classifier. Tapping those internal activations lets the agent decide, per line, whether to keep or prune with minimal extra compute.
Key Findings
- Core mechanism: attach a lightweight head to the agent's internal representations to predict keep/prune labels for each output line; include a length-aware embedding keyed to the tool output's line count to normalize across different output sizes.
- Empirical impact: across two open-weight backbones and four multi-turn coding benchmarks, the method reduces prompt+completion tokens by up to 39% while maintaining task performance; on MiMo-V2-Flash it increases the SWE-Bench Verified resolve rate by +3.8% and long-context Oolong accuracy by +2.2 points.
- Efficiency and deployment: pruning happens inside the agent (no external classifier), yielding bounded inference overhead and tighter alignment between pruning decisions and the agent's semantic understanding of the output.
Who it's for & Trade-offs
- Great fit if you run or fine-tune open models for coding assistants and need to reduce token costs and latency without losing task accuracy; useful for multi-turn tool-heavy workflows where many output lines are auxiliary.
- Look elsewhere if you only have black-box access to closed-source LLMs (no activation hooks), if tool outputs must be preserved verbatim for auditing, or if your task depends on rare, late-occurring lines that aggressive line-level pruning might remove.
- Practical note: the approach requires access to internal activations and some calibration per backbone; although inference overhead is bounded, teams must weigh the engineering cost of integrating the pruning head versus running an external filter.