If your coding agent has to fit a repository into a fixed token budget, a new study says the budget is better spent picking a few files and showing them whole than squeezing more code in with a prompt compressor or a chunk retriever. At equal per-issue budgets on 300 recent SWE-rebench issues, a simple file selector called CQ2-CARE resolved 43.7% of issues with GPT-5.6 and 46.7% with Claude Opus 5, ahead of every drop-in compressor and retriever the authors tested.
The paper is Skip the Compressor: Coding Agents Fix More Issues When They Pick Whole Files by Xiaocong Yang, Rishit Chatterjee, Himanshu Udupi, Vikram Ramavarapu and ChengXiang Zhai of the University of Illinois Urbana-Champaign, posted to arXiv (cs.SE) with a date of October 15, 2026. The mechanism it identifies is simple: retrievers often miss the file that has to change, and compressors keep that file but alter its text, so the model's patch quotes lines that do not exist.
The problem: an edit has to quote the code
Trimming context makes agents cheaper, and models use the middle of a long input less reliably than its ends. Prompt compressors delete the tokens a small model scores as least useful, which the authors say costs little when the output is an answer or a summary. A patch is different. To fix an issue, the context has to contain two things at once:
- the files the fix must edit, and
- their code exactly as written, because the model must reproduce the lines it changes.
Figure 1 of the paper shows both failures on one issue from the twine repository, a report that some error messages lack the f of an f-string. A BM25 chunk retriever filled the budget with the repository's GitHub issue templates, which share the report's wording, and never showed the file to edit. LLMLingua-2 kept the right file but deleted the f prefixes and quotation marks, so the model's patch rewrote a line that does not exist and failed to apply. Shown twine/sdist.py whole and verbatim, the same model wrote the fix.
The paper tracks two numbers for every context: gold-file recall (the share of files the reference patch modifies that appear in the context) and verbatim lines (the share of context lines that match the real file).
How CQ2-CARE builds a context
CQ2-CARE uses the same model under test for every call and never shows it the whole repository:
- The model sees a path inventory: the repository paths that share the most words with the issue, listed alphabetically.
- It is asked, in independent samples, "which files must change?" The selector keeps the files that two answers both name, excluding tests and documentation. If none remain, it falls back on a third answer.
- The model then requests at most four typed searches, such as a definition or its callers. Grep adds short spans from up to two new files per search, until the evidence covers eight files.
- The chosen source files go in whole, followed by the evidence spans, under size caps.
With GPT-5.6, a context held 1.7 selected files on average (median 1) plus spans from 6.0 more files. That realized context size becomes the token budget every other method must fit for that issue: a mean of 13.8K tokens with GPT-5.6 and 27.1K with Claude Opus 5.
The setup
- Data: 300 Python issues from the SWE-rebench leaderboard, one per repository, created between January 2025 and May 2026. Each was checked to be resolved by its gold patch and not by an empty one.
- Models: gpt-5.6-sol at medium reasoning effort and Claude Opus 5, each used for every call in its run.
- Grading: one patch per context, graded with the SWE-rebench fork of the official harness. Patches that fail to parse or apply count as unresolved.
- Baselines: three compressors (LLMLingua-2, LongLLMLingua, LongCodeZip), three retrievers (chunk BM25, dense chunk retrieval with CodeRankEmbed, and SWE-bench's file-level BM25), and two methods trained for issue resolution (SWE-Pruner and SweRank), which were added after the main results.
The authors chose SWE-rebench over SWE-bench Verified, citing work that found models can often name the files to edit on the older benchmark from the issue text alone.
The results
Issues resolved, at the same per-issue budget (GPT-5.6 / Claude Opus 5), from Table 1:
- CQ2-CARE: 43.7% / 46.7%
- SweRank (trained retriever of whole functions): 43.0% / 45.0%
- SWE-Pruner (trained line pruner): 41.7% / 39.3%
- LongCodeZip: 37.3% / 36.0%
- LongLLMLingua: 35.0% / 29.0%
- LLMLingua-2: 30.0% / 40.3%
- BM25, whole files: 34.3% / 34.0%
- BM25, chunks: 29.0% / 34.0%
- Dense retrieval, chunks: 22.7% / 33.7%
- Gold files (upper bound): 49.3% / 46.3%
- Issue only, no source: 8.7% / 13.0%
That is 6.3 points more than the best of the three compressors with either model, and 9.3 points (GPT-5.6) and 12.7 points (Claude) more than the best of the three retrievers. All of these leads are statistically significant in the paper's tests. The narrowest, over LLMLingua-2 with Claude (p = 0.027), is weak, and the authors call it fragile. Against the trained methods, SWE-Pruner trails by 2.0 and 7.3 points, significantly only with Claude, and SweRank is within two points (0.7 and 1.7).
Two more details matter. Whole files alone are not enough: file-level BM25 also shows whole files, but chooses them by similarity to the issue, and trails by 9.3 and 12.7 points. And the model's own file choice comes close to the truth. Gold files resolve 5.7 points more than CQ2-CARE with GPT-5.6, and no more with Claude.
Why the baselines lose
Retrievers miss the files to edit. With GPT-5.6, chunk BM25 and dense retrieval put a fifth or less of their context lines in the files the fix modifies, against about half (51.7%) for CQ2-CARE. They showed no file to edit at all on 26.2% and 27.5% of issues, against 3.4% for CQ2-CARE (of the 298 issues whose gold patch modifies an existing file).
Compressors keep the files but change the text, and patches stop applying. The fewer lines a compressor keeps verbatim, the fewer patches apply (GPT-5.6):
- CQ2-CARE: 100.0% of lines verbatim, 98.0% of patches apply
- SWE-Pruner: 91.7% verbatim, 93.0% apply
- LongCodeZip: 96.8% verbatim, 89.7% apply
- LongLLMLingua: 67.1% verbatim, 84.0% apply
- LLMLingua-2: 17.5% verbatim, 70.7% apply
Patches that do not apply account for 28 of the 48 issues that CQ2-CARE resolves and LLMLingua-2 does not. In a 100-issue check with search/replace edits instead of diffs, quotes taken from compressed contexts often matched no unique location in the real file: on 45 issues for LLMLingua-2, against 4 for CQ2-CARE.
The controlled tests
The main comparison mixes two effects: compressors differ in which files they keep and in how they alter them. Two post-hoc tests change one factor at a time, with GPT-5.6 on all 300 issues:
- Altering text, same files: deleting 20% of the tokens of every line in CQ2-CARE's own contexts lowered patch applicability from 98.0% to 78.7% and resolution by 9.7 points (p < 0.001). A second patch sample of the intact contexts resolved exactly as many issues.
- Same files, different cut: when the compressors cut CQ2-CARE's own candidate files instead of the larger context, LongCodeZip resolved 44.7% against 43.7% for CQ2-CARE. LLMLingua-2 came within 3.0 points when its scores chose whole lines, and trailed by 7.3 when they chose tokens.
The authors read this as a rule, not a ranking: choose the candidate files well, then cut whole lines if anything must be cut.
What actually makes the selector work
The two-sample agreement step is not the trick. Agreement raises file-localization F1 to 0.613 from 0.430 for a single draw, but mostly because it names half as many files. A single draw cut to the same number of files reaches 0.600 and resolves about as many issues with both models. What matters, the paper says, is choosing few files. When budget allows, more whole files help: the union of two draws resolved 4.0 points more at 2.3K more tokens. The grep evidence step added 3.0 points, short of significance (p = 0.068).
It is also cheaper. Against the uncompressed single-draw context, CQ2-CARE used 0.68 times the tokens with GPT-5.6 and 0.73 times with Claude. The whole pipeline cost $0.151 per issue with GPT-5.6 in API calls, against $0.199 for the single draw and $0.168 to $0.177 for the compressor contexts, because those first build the uncompressed context. It needs no compression model: LongLLMLingua and LongCodeZip spent a median 34 to 37 seconds of GPU time per issue, and LongCodeZip ran out of memory on 4 issues at 48 GB on Claude's larger contexts.
Caveats
The authors list these limitations:
- One patch call per context on Python issues from one benchmark. A multi-turn agent that can reopen files or run tests may recover some of the losses; they leave that to future work.
- The budget is CQ2-CARE's own realized size, so the comparison runs at its operating point; a 100-issue sweep of other budgets kept the same ordering.
- File-level BM25, the controlled tests, SWE-Pruner and SweRank were added after the main results. SweRank may have trained on other pull requests from the same repositories, and its small gap does not show equal performance.
- Most cells have one patch sample, and a second sample flips 8.7% to 18.9% of outcomes, so small gaps are fragile.
- The issues may overlap the models' training data, though the gaps do not shrink detectably on newer issues.
The authors say they will release code, prompts and per-issue outcomes.
Why it matters
Chunk retrieval, similarity ranking and token pruning are common drop-in ways to fit code into a prompt, and they are the ones this paper tested. If you use them, it suggests two cheap checks. Measure how often your context contains the file the fix touches, and measure how much of your context is byte-for-byte the real file. If either is low, the paper's results suggest you are paying for tokens that make patches worse. For background on the tools tested here, see our explainers on prompt compression with LLMLingua and BM25 and dense hybrid retrieval, and our comparison of agent benchmarks including SWE-bench.
The result is narrow by design: single-shot patches, Python, one benchmark. But the failure it documents, a model editing a line that a compressor rewrote without noticing the text was altered, is worth testing for in any agent that edits code from a compressed view of it.
