If you use Claude, ChatGPT or Cursor to fix bugs, a new University of Illinois preprint has a cheap lesson: when context is tight, show the model fewer files, but whole and exactly as written.
The paper
Title: Skip the Compressor: Coding Agents Fix More Issues When They Pick Whole Files (arXiv 2610.21073, Software Engineering)
Authors: Xiaocong Yang, Rishit Chatterjee, Himanshu Udupi, Vikram Ramavarapu and ChengXiang Zhai, all at the University of Illinois Urbana-Champaign. Yang and Chatterjee are marked as equal contributors.
Date: submitted 15 October 2026 (v1, the only version so far). It is a preprint and has not been peer reviewed.
The finding in plain English
A codebase is far bigger than a model's context window, so tools must choose what code the model sees. They can retrieve chunks that resemble the bug report, compress lots of code by deleting tokens a small model rates unimportant, or pick a few files and paste them in full.
The authors gave every method exactly the same token budget per issue and graded the resulting patches with real tests. Their simple file picker, called CQ2-CARE, came out on top. In the abstract's words, "With GPT-5.6 and Claude Opus 5, CQ2-CARE resolves 43.7% and 46.7% of the issues, 6.3 points more than the best of three compressors with either model, and 9.3 and 12.7 points more than the best of three retrievers." It also edged out two methods trained specifically for issue resolution: SweRank by 0.7 and 1.7 points, and SWE-Pruner by 2.0 and 7.3.
The reason is mechanical: an edit has to quote the lines it changes. Retrievers rank code by resemblance to the bug report and often miss the file that needs the fix. Compressors keep that file but alter its text, so patches target lines that do not exist. The paper's summary: "retrievers often miss the files to edit, and compressors keep them but alter their text, so fewer patches apply."
How they did it
The test set was 300 issues from the SWE-rebench leaderboard, one per repository, all Python, created between January 2025 and May 2026. Each method built one context, the model wrote one patch as a unified diff, and the benchmark's own tests decided whether the issue was resolved.
CQ2-CARE works in three steps, as described in the full paper's method section:
Start from a file list. The model sees the issue plus an alphabetical list of file paths that share the most words with it.
Ask "which files must change?" twice. Two independent answers are compared and only the files both name are kept. Test and documentation folders are excluded.
Add grep evidence. The model may request up to four searches, such as a function definition or its callers. A plain grep finds them, and short verbatim spans from up to eight extra files are added.
The chosen files go in whole: with GPT-5.6, 1.7 selected files on average (median 1) plus spans from 6.0 more. That context's size set the budget every other method had to fit.
Baselines: three compressors (LLMLingua-2, LongLLMLingua, LongCodeZip), three retrievers (chunk BM25, dense chunk retrieval, SWE-bench's file-level BM25), and SWE-Pruner and SweRank, added after the main results.
A few results from the analysis are worth knowing:
Altered text is expensive on its own. When the authors deleted 20% of the tokens from every line of their own contexts, keeping the files the same, patches that applied fell from 98.0% to 78.7% and resolution dropped 9.7 points.
Whole files chosen badly don't help. File-level BM25 also pastes whole files, but chooses them by similarity to the issue, and it trailed by 9.3 and 12.7 points.
Asking twice adds little. A single answer trimmed to the same number of files resolved about as many issues. What matters is naming few files and naming the right ones.
It was cheaper too. The authors put the full pipeline at $0.151 per issue with GPT-5.6, against $0.199 for the uncompressed single-answer context, in API calls alone.
Why it matters
Prompt compression is often pitched as a free way to fit more code into a model. This paper shows that for editing code, the exact text matters more than the amount. The gold-file oracle, which shows exactly the files the real fix touched, resolved 49.3% with GPT-5.6, only 5.7 points above CQ2-CARE, and no more than CQ2-CARE with Claude. A model that is simply asked which files it needs gets close to perfect file knowledge.
For solo builders the approach needs no extra tooling. You need no compression model, no vector database and no fine-tuning, just a question and a paste. It also fits how current editing tools work: search-and-replace edits only land when the quoted text matches the file exactly. We covered a related cost lever in cache-stable agent context. Both point the same way: keep context stable and verbatim.
Caveats
One shot, no agent loop. The model got one context and wrote one patch. The authors did not test "a multi-turn agent that could read more files or run tests", and they note that agents able to re-open files may recover some of the losses.
Narrow scope. 300 Python issues from one benchmark and two frontier models.
Some leads are thin. With Claude, the lead over LLMLingua-2 is significant only weakly (p=0.027), and the authors call such small gaps "fragile", since a second patch sample flips 8.7–18.9% of outcomes. The lead over SweRank is under two points, and the authors say it "does not show equal performance".
A fair control. When a code-aware compressor (LongCodeZip) cut whole lines from CQ2-CARE's own chosen files, it matched it (44.7% against 43.7%). The win comes from choosing files well. Cutting whole lines afterwards, if you must, is fine.
No code yet. The paper says the team "will release code, prompts and per-issue outcomes". The Hugging Face paper page lists no repository so far.
How builders and ordinary people can use it today
The workflow below mirrors the paper's three steps and needs no new software.
The workflow
Share the issue and a file list. Paste the bug report or error plus a file list. In a terminal,
git ls-filesprints every tracked file. For a big repo, filter it, for examplegit ls-files | grep -i invoice.Ask which files must change. Ask for the smallest set, ranked. If you want the paper's safety check, ask again in a fresh chat and keep the files both answers share.
Paste those files whole. No excerpts, no "relevant parts", no AI summaries of the file. In Cursor or Claude Code, attach or @-mention the full files rather than relying on automatic codebase search.
Let it ask for evidence. If the model needs a definition or caller from another file, run
git grep -n "function_name"and paste that exact function, copied verbatim.Ask for a patch that quotes real lines. Then apply it and run your tests.
Copy-paste prompt
Step 1 of 2. Do not write any code yet.
Here is a bug report and a list of file paths in my repository.
Which files must change to fix it? Give the smallest set you are
confident about, ranked from most to least likely, one path per line.
Exclude tests and docs. Then list up to four things you would want
me to grep for (a function definition, its callers, or an exact
error string).
BUG REPORT:
[paste issue, error message or steps to reproduce]
FILE LIST:
[paste output of git ls-files, filtered if large]
---
Step 2 of 2 (send after pasting the files).
Here are the files you named, complete and unedited, followed by the
grep results you asked for. Write a minimal fix as a unified diff.
Only change lines that appear exactly in the text above, and do not
rewrite code you have not been shown.A 20-minute self-test on your own repo
Run a small version of the study on bugs you have already fixed:
Pick five past bug-fix commits. For each, note the files it touched with
git show --name-only COMMIT(replace COMMIT with the commit hash). That is your answer key.Check out the commit before each fix (
git checkout COMMIT~1) and send Step 1 of the prompt with the original bug description. Score how many of the touched files the model named, and how many extra files it added.For two of the bugs, run Step 2 twice in fresh chats. In the first, paste the named files whole. In the second, paste only snippets you think are relevant, or an AI summary of each file.
Save each diff and run
git apply --check fix.diff, then your tests. Record whether each patch applied and whether the tests passed.
If whole files win, make it your default. If the model keeps naming the wrong files, improve the file list (clearer folder names, a short README of where things live) before adding any retrieval tool. If you run an agent with its own harness, read this alongside our earlier research piece on improving an agent's harness task by task.
Sources
arXiv 2610.21073 abstract page, Yang et al., submitted 15 October 2026
arXiv 2610.21073 full HTML paper: method, Table 1, analysis and limitations