Every long-context trick I have reached for in agent pipelines shares one move: delete something so the prompt fits. A paper from UIUC, Skip the Compressor, runs the comparison on 300 real GitHub issues and finds that deleting text is the expensive part. The best compressor landed about 6.3 points behind simply showing the model the right files, whole and verbatim.
Pick fewer files, then leave them alone#
The setup is one patch call per issue on 300 Python issues from the SWE-rebench leaderboard, one per repository, graded by the benchmark's FAIL_TO_PASS and PASS_TO_PASS tests. They ran GPT-5.6 and Claude Opus 5. Their method, CQ2-CARE, is almost boring:
Ask the model twice, independently, which files must change.
Keep only the files both answers name.
Add short grep-based evidence spans.
Show the selected files in full, with no compression model anywhere.
Resolution rates came out at 43.7% with GPT-5.6 and 46.7% with Claude Opus 5. With no source at all the models got 8.7% and 13.0%, so the context is doing nearly everything. A gold-file oracle reached 49.3% and 46.3%, which means the selector gets close to the ceiling.
Compressors keep the right files and still break the patch#
This is the part I would have gotten wrong. I assumed compressors lose a little information and pay for it in a few points. The paper shows the failure is more mechanical than that. Edits have to quote exact code, and a compressed file no longer contains exact code.
Patch applicability, GPT-5.6: 98.0% for CQ2-CARE against 70.7% for LLMLingua-2.
Best compressor: LongCodeZip at 37.3% with GPT-5.6, LLMLingua-2 at 40.3% with Claude.
Controlled cut: deleting 20% of tokens from every line of CQ2-CARE's own contexts cost 9.7 points.
Cost: about $0.151 per issue with GPT-5.6, against $0.199 for an uncompressed single-draw context.
The 20% deletion test is the cleanest evidence in the paper. Same files, same model, only the text is thinner, and resolution drops nearly ten points. The authors put it plainly:
Exact-file selection needs no compression model and shows every line as the repository has it, so the model can quote the code it edits.
Retrievers fail for a different reason#
File-level BM25 was the best retriever at 34.3% and 34.0%, 9.3 and 12.7 points behind. The authors blame similarity ranking: it favors tests and documentation that echo the issue text over the file that has to change. Chunk BM25 and dense retrieval put about a fifth or less of their lines in files to edit, versus about half for CQ2-CARE.
That matches what I see when an agent greps for the symbol in a stack trace and drowns in test fixtures. Ranking by relevance to the issue is not ranking by where the fix lives.
How much of the selector is the voting?#
The two-draw agreement looks like the clever bit, but the paper is candid that it is not. Agreement mainly shrinks the number of files named, and a single draw cut to the same size performs about as well. The win comes from choosing few files well. Cutting the same candidate files with LongCodeZip gave 44.7%, close to CQ2-CARE's 43.7%.
So the practical reading is narrow: budget your context in files, not in tokens per file.
What I would not carry over yet#
This is one patch call on Python issues, not a multi-turn agent like Claude Code, which can read more files on demand and recover from a bad pick. Most cells have a single sample, and a second sample flips 8.7 to 18.9% of outcomes, so small gaps are fragile. Some baselines, SweRank and SWE-Pruner among them, were added after the main results, and the planned analysis was not time-stamped. LongCodeZip also ran out of memory on 4 of Claude's 300 contexts, counted as unresolved. Contamination is possible, though the gaps did not shrink detectably on newer issues.
There is also a point about how the agent behaves downstream. A model shown whole files can copy the lines it is about to change, and the exact-quote edit format most harnesses use depends on that. A model shown a compressed file has to reconstruct the missing tokens from memory, and some of those reconstructions are wrong. The failure is silent in the prompt and loud only at patch-apply time, which is why I would track patch applicability as its own metric next to resolution rate. If it sits at 70% while your resolve rate looks acceptable, you may be losing a third of your good ideas to formatting.
It also changes how I would think about cost. The usual argument for compression is that tokens are expensive. Here the whole-file pipeline was cheaper than the uncompressed single-draw baseline, $0.151 against $0.199 per issue with GPT-5.6, because choosing few files shrinks the context more than any token-level trick does, and it needs no GPU for a compressor model. The lever is which files go in, not how hard you squeeze each one.
The directional claim survives all of that for me, because the mechanism is easy to believe.
If I were building the context stage of a coding agent today, I would drop the compressor, spend the saved budget on a second independent file-selection pass, and let the agent read whole files. My open question is whether the same holds once the agent can fetch files itself, since that is where I expect the advantage of exact text to matter even more.