Squeez: Task-Conditioned Tool-Output Pruning for Coding Agents
| Authors | Ádám Kovács |
| Year | 2026 |
| HF Upvotes | 8 |
| arXiv | 2604.04979 |
| Download | |
| HF Page | View on Hugging Face |
Abstract
Coding agents repeatedly consume long tool observations even though only a small fraction of each observation matters for the next step. We study task-conditioned tool-output pruning: given a focused query and one tool output, return the smallest verbatim evidence block the agent should inspect next. We introduce a benchmark of 11,477 examples built from SWE-bench repository interactions and synthetic multi-ecosystem tool outputs, with a manually curated 618-example test set. We fine-tune Qwen 3.5 2B with LoRA and compare it against larger zero-shot models and heuristic pruning baselines. Our model reaches 0.86 recall and 0.80 F1 while removing 92% of input tokens, outperforming zero-shot Qwen 3.5 35B A3B by 11 recall points and all heuristic baselines by a wide margin.
Engineering Breakdown
Plain English
This paper tackles a concrete problem in coding agents: they spend computational budget reading tool outputs (like search results, file contents, logs) when only tiny fragments actually matter for the next action. The authors built a 11,477-example dataset from real SWE-bench interactions and created a pruning model that identifies the minimal relevant snippet from each tool output given the agent's current query. Their fine-tuned Qwen 2B model achieves 0.86 recall and 0.80 F1 while cutting input tokens by 92%, outperforming a 17.5× larger zero-shot baseline by 11 recall points—demonstrating that task-conditioned pruning dramatically reduces computational waste without sacrificing accuracy.
Core Technical Contribution
The core contribution is task-conditioned tool-output pruning framed as extractive summarization: given a focused agent query and a potentially massive tool output, identify and return the smallest contiguous verbatim evidence block that the agent needs to process. This differs from prior work in two ways: (1) it's query-specific rather than generic summarization, and (2) it preserves exact text excerpts rather than generating paraphrases, which is critical for agents that need to reference exact line numbers or code spans. The authors also contribute the first large-scale benchmark (618 manually curated test examples) specifically for evaluating pruning quality in agent workflows, which enables proper measurement of precision-recall trade-offs in a way prior heuristic methods couldn't quantify.
How It Works
The system treats pruning as a token classification task: given a query (the agent's current request) and a tool output (unstructured text like file contents or search results), the model predicts which span of tokens forms the minimal relevant evidence block. Input is formatted as [query][SEP][tool_output], and the model (Qwen 3.5 2B fine-tuned with LoRA) outputs start and end token indices identifying the answer span. Training uses 11,477 examples from SWE-bench repository interactions augmented with synthetic multi-ecosystem outputs (different file formats, error logs, API responses) to ensure diversity. At inference, the model runs in seconds per tool output; the pruned span is extracted and fed to the downstream agent, replacing the full output. The LoRA approach keeps model size tiny (2B parameters) while matching larger models, making it practical to embed in agent inference loops.
Production Impact
In production coding agent systems, tool outputs are frequently enormous: a repository file search might return thousands of lines, stack traces contain verbose context, API responses include nested metadata. Pruning reduces downstream LLM context load directly, which translates to 3–4× faster inference per agent step and proportionally lower compute cost on vision-and-language models that scale quadratically with context length. Integration is straightforward: insert the pruning model as a post-processing filter after tool execution and before agent reasoning—it's decoupled from the agent itself. The trade-off is that you must maintain a separate 2B model checkpoint and handle tokenization consistently, adding ~50–100ms latency per tool call; in practice this pays off when your main agent runs on a 70B+ model. The 92% token reduction also translates to cheaper API calls if you're forwarding to external LLMs, and reduced memory pressure on constrained deployments (edge devices, resource-limited containers).
Limitations and When Not to Use This
The approach assumes tool outputs are naturally sparse—i.e., most of the content is noise. In domains where outputs are uniformly information-dense (e.g., structured JSON APIs, tightly formatted logs), pruning provides minimal benefit. The model is trained on SWE-bench interactions, which skews toward code search and file navigation tasks; generalization to entirely different tool types (image search, scientific databases, web scraping) is untested. The paper doesn't address streaming tool outputs or tools that return hierarchical/tree-structured data; the span extraction approach works only for sequential text. Finally, recall of 0.86 means roughly 14% of relevant information is being pruned away—in high-stakes applications (security scanning, medical code review), this false-negative rate may be unacceptable without careful calibration of the recall threshold.
Research Context
This work sits at the intersection of agent efficiency and extractive summarization. It builds on the insight that coding agents waste compute on irrelevant context (prior work showed context length is a bottleneck in agent reasoning), and applies extractive QA techniques (identifying answer spans in passages) to the tool-output domain. The benchmark extends SWE-bench, a widely-used evaluation suite for software engineering agents, making this a natural incremental advance. The research direction this opens is task-conditioned filtering more broadly: other agent types (web agents, database agents, scientific assistants) likely face similar problems and could benefit from similar lightweight pruning models. It also hints at a potential research avenue in making agents more aware of output relevance during tool design itself—e.g., tools could expose selectivity features that let agents request only relevant fields.
:::tip Subscribe Get weekly breakdowns of papers like this in AI Letters - the newsletter for engineers building production AI systems. :::