Source-linked AI summary

Skip the Compressor: Coding Agents Fix More Issues When They Pick Whole Files

Xiaocong Yang, Rishit Chatterjee, Himanshu Udupi, Vikram Ramavarapu, ChengXiang Zhai

arXiv:2610.21073v1cs.SE

TL;DR

Coding agents work with repositories too large to fit in context, yet issue patches need both the files to change and their exact code. The paper compares exact-file selection with retrieval and pruning at matched per-issue budgets. Across two model families, CQ2-CARE resolves more issues than the compared compressors and retrievers.

  • Problem

    At fixed context budgets, it is unclear which repository view best supports issue resolution, where agents need both the files to edit and their exact text.

    Source: §1 · p. 2, §5 · p. 8
  • Method

    CQ2-CARE uses a model to select files to change and presents them whole and verbatim, with short evidence spans, in a budget-matched test-graded comparison.

    Source: §1 · p. 2, §2 · p. 4
  • Results

    Across two model families, CQ2-CARE resolves more issues than each of three compressors and three retrievers at matched budgets.

    Source: §1 · p. 2
  • Takeaways & Limitations

    The comparison supports spending context on choosing code to show verbatim rather than pruning tokens or retrieving chunks.

    Source: §7 · pp. 8–9

    The study uses one patch call per context on Python issues from one benchmark, not a multiturn agent that can read more files or run tests.

    Source: Limitations · p. 9

Abstract

from arXiv · show

A coding agent works on repositories that can be far larger than its context window can hold. Prompt compressors and retrievers offer solutions to this problem, but patching an issue needs two things at once: the files that must change, and their code exactly as written, since the model must reproduce the lines it edits. Retrievers rank code by its similarity to the issue rather than by whether it must change, and compressors delete text to fit the budget. We show that at an equal token budget, an agent resolves more issues when the budget goes to choosing which files to show verbatim, as our simple selector CQ2-CARE does, than when it goes to pruning tokens or retrieving chunks. We fit every context to the same per-issue budget on 300 recent SWE-rebench issues and grade each patch with the benchmark's tests. 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. CQ2-CARE even resolves more issues than two methods trained for issue resolution, SweRank (by 0.7 and 1.7 points) and SWE-Pruner (by 2.0 and 7.3). Our analysis shows the defects of the baseline methods: retrievers often miss the files to edit, and compressors keep them but alter their text, so fewer patches apply. 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.

1 Introduction

Coding agents need compact repository contexts that include both the files to edit and their exact text. This section introduces CQ2-CARE and compares it with retrieval and pruning at matched budgets, finding that exact-file selection resolves more issues across two model families.

1 Introduction

  • Retrievers can rank issue-similar text above files to edit, while token compressors can alter code that patches must reproduce exactly.In the illustrated issue, retrieval misses the edit file and pruning deletes an f-string prefix.Source: §1 · p. 2, Figure 1 · p. 2
  • CQ2-CARE selects files the model identifies as needing changes and shows them whole and verbatim, without a compression model.It also adds short grep-found spans for requested definitions, callers, or strings.Source: §1 · pp. 2–3
  • The comparison tests one patch per context on 300 SWE-rebench issues, fitting each method to the selector’s per-issue context size and grading with issue tests.The study also measures gold-file recall and the share of verbatim lines, with controlled tests varying one at a time.Source: §1 · pp. 2–3
  • At matched per-issue budgets, CQ2-CARE resolves more issues with each of two model families than three compressors and three retrievers.With Claude, its lead over LLMLingua-2 is narrow.Source: §1 · p. 2
  • CQ2-CARE also resolves more issues than two methods trained for issue resolution.The supplied passage names SWE-Pruner but does not give the trained-method comparison values.Source: §1 · p. 2

2 Context as Compressed Memory

The paper models a repository context as source spans selected under a token budget, with success measured by whether a fixed model’s patch passes the issue tests. It distinguishes retrieval, pruning, and exact-file selection by what they include and preserve.

2 Context as Compressed Memory

  • A context step maps the issue and repository to source spans within budget B; a fixed model uses that context to write a patch graded by the issue’s tests.Resolution rate is the mean of the binary resolved outcome across issues.Source: §2 · p. 3
  • Chunk retrieval ranks repository units against the issue and packs the highest-ranked units verbatim, using a whole-line prefix of the next unit if needed.Units can be top-level definitions, line windows, or whole files.Source: §2 · p. 3
  • Token pruning deletes tokens, lines, or code blocks that a scoring model rates least useful to shorten a larger candidate context.The rate is chosen so the resulting context is approximately budget B.Source: §2 · p. 3
  • Exact-file selection predicts files to edit and shows them whole and verbatim, then adds short evidence spans from other files.Size caps can limit what fits.Source: §2 · p. 3
  • Gold-file recall measures how many gold-patch files appear in the context, while verbatim-line share measures whether context lines match their named repository files.The gold patch is used only to compute recall after the fact; the model does not see it.Source: §2 · p. 3
  • CQ2-CARE selects files named by two independent model answers, falls back to a third answer if needed, and can add grep-found evidence spans.It uses a path inventory and caps evidence coverage at eight files.Source: §2 · p. 4

3 Experiments

The experiments compare budget-matched context methods on recent SWE-rebench issues, then show that selecting whole files verbatim resolves more issues than drop-in baselines and approaches the gold-file oracle.

3.1 Data

  • The study uses the first 300 eligible issues, created from January 2025 to May 2026, from a pinned SWE-rebench revision.Candidates were sampled one per repository; 328 of 340 passed checks that the gold patch resolves the issue and an empty patch does not.Source: §3.1 · p. 4

3.2 Setup and Baselines

  • All methods share a pipeline and differ only in the context step; the comparison uses the same prompt and grader, and scores patches that fail to parse or apply as unresolved.Baselines include three compressors, chunk and dense retrieval, file-level BM25, SWE-Pruner, and SweRank; comparisons are paired by issue.Source: §3.2 · p. 5

3.3 Main Results

  • 43.7% with GPT-5.6 and 46.7% with Claude Opus 5: CQ2-CARE exceeds the best compressor by 6.3 points with either model and the best retriever by 9.3 and 12.7 points.Its leads over the baselines are significant, although the narrowest—LLMLingua-2 with Claude—has p = 0.027.Source: §3.3 · p. 5
  • The gold files resolve 5.7 points more than CQ2-CARE with GPT-5.6 and no more with Claude, so selecting a few whole files recovers most of the oracle benefit.The comparison is at the budget a compressor would use.Source: §3.3 · p. 5

4 Analysis

The analysis attributes baseline losses to different failures: retrievers omit files to edit, while compressors alter text needed for applicable patches. Controlled tests, robustness checks, and ablations examine these trade-offs and CQ2-CARE across settings.

4.1 Retrievers Miss Files, Compressors Alter Text

  • Chunk BM25 and dense retrieval place a fifth or less of lines in target files, versus half for CQ2-CARE; compressors alter text, reducing patch applicability.SweRank shows every gold-patch line on 39% of GPT-5.6 issues, versus 70% for CQ2-CARE.Source: §4.1 · p. 6, Figure 2 · p. 6

4.2 Controlled Tests

  • Deleting 20% of each line’s tokens cut patch applicability from 98.0% to 78.7% and resolution by 9.7 points; whole-line cuts of candidate files let LongCodeZip resolve 44.7%, versus CQ2-CARE’s 43.7%.The compressor-on-candidate-files test is a control, not a competing baseline; it inherits CQ2-CARE’s file choice.Source: §4.2 · pp. 6–7, Figure 2 · p. 6

4.3 Robustness

  • Across 25%, 50%, and 75% budgets, no compressor or retriever reached exact-file contexts; baselines still trailed CQ2-CARE with search/replace edits and a second patch sample.Compressors miss the ±2% budget window on a quarter to a third of issues, usually by landing under budget; patch resampling moved selected rates by at most 2.0 points.Source: §4.3 · p. 7, Figure 3 · p. 7

4.4 Ablations of CQ2-CARE

  • Agreement raises localization F1 to 0.613 from 0.430, but a single draw capped to the same file count reaches 0.600 and resolves about as many issues; the evidence step adds 3.0 points, short of significance.Against the uncompressed single draw, CQ2-CARE uses 0.68× the tokens with GPT-5.6 and passes the planned non-inferiority test; with Claude, it uses 0.73×, but the token-ratio upper bound narrowly misses its margin.Source: §4.4 · pp. 7–8

5 Discussion

The discussion argues that context budgets should prioritize selecting the right files and preserving their text, while noting limits to the comparisons and the need to study multiturn agents. It also recommends evaluating context methods with equal budgets and benchmark tests.

5 Discussion

  • Choose candidate files well and show their code verbatim; if context must be cut, cut whole lines.The discussion links verbatim text to locatable edits and notes that retrieval can miss files while pruning alters text edits must quote.Source: §5 · p. 8
  • LongCodeZip matched CQ2-CARE when given the same candidate files, so the results do not establish that selection beats a code-aware compressor starting from those files.LongCodeZip used 6.8 GPU-hours on 300 issues; CQ2-CARE adds one localization call and requires no compression model.Source: §5 · p. 8
  • A full agent loop is needed to measure whether rereading files recovers compression losses enough to offset extra turns and tokens.A model may not notice altered text; in Figure 1 it rewrote a line that does not exist in the file.Source: §5 · p. 8
  • Context methods should be compared end to end, at equal budgets, using benchmark tests rather than localization scores or exit codes alone.Agreement between two localization samples raised file-level F1, but a single sample limited to the same number of files resolved about as many issues; exit-code grading credited empty patches on 4 of 6 issues.Source: §5 · p. 8

6 Related Work

Related work spans prompt compression, code retrieval, and agent-memory systems. This paper compares context methods at fixed per-issue budgets and examines how their choices affect issue resolution.

6 Related Work

  • Prompt-compression research removes tokens or sentences judged uninformative, while RECOMP compresses retrieved documents; on long-context QA and summarization, extractive chunk selection often outperforms pruning and abstractive summarization (Jha et al., 2024).The paper reports the same ordering for issue resolution and identifies altered edit text as a cost specific to that task.Source: §6 · p. 8
  • Coding-agent memory work includes repository contexts selected by perplexity, execution-derived contexts, pruning, and learned retrieval of whole functions (Shi et al., 2025; Jia et al., 2026; Wang et al., 2026; Reddy et al., 2026).The passage notes that SWEzze compares methods around fault locations already found by Agent-less, while SWE-Pruner's attribution of losses is framed as a hypothesis.Source: §6 · p. 8
  • This study fixes the budget per issue, lets each method choose which files enter context, and uses controlled tests to measure both missed-file and altered-text failure modes.The repository is framed as the coding agent's long-term memory, with the prompt containing a selected part of it (Sumers et al., 2024; Packer et al., 2024).Source: §6 · p. 8

7 Conclusion

The paper compares context methods at equal per-issue budgets on 300 test-graded issues across two model families. Showing selected whole files verbatim resolves more issues than pruning tokens or retrieving chunks, with the reported losses tied to missed files and altered text.

7 Conclusion

  • The conclusion frames the context budget as best spent choosing which code to show verbatim and in whole lines.The paper's comparison covers methods for filling a coding agent's context budget.Source: §7 · pp. 8–9
  • Showing a few whole files verbatim resolved more issues than pruning tokens or retrieving chunks, and about as many as a trained retriever of whole functions.The comparison used equal per-issue budgets on 300 test-graded issues with two model families.Source: §7 · p. 8
  • Retrieval often misses files to edit, while token pruning alters text that patches must quote; controlled tests showed each loss costs on its own.The conclusion recommends spending the context budget on choosing which code to show, kept verbatim and in whole lines.Source: §7 · p. 9

Limitations

The limitations concern the single-turn Python benchmark setting, comparison design, diagnostic estimator, and precision and contamination risks.

Limitations

  • The study tests one patch call per context on Python issues from one benchmark, not a multiturn agent that can read more files or run tests.Source: Limitations · p. 9
  • Comparisons use the context's realized size and the method's operating point; SweRank may have trained on other pull requests from the repositories, so its small gap does not show equal performance.File-level BM25, controlled tests, SWE-Pruner in single-turn mode, and SweRank were added after the main results.Source: Limitations · p. 9
  • The estimator uses the gold patch and is diagnostic; its inside-function coverage choice was made after seeing SweRank's result and needs testing on an unseen method.Source: Limitations · p. 9
  • Most result cells have one patch sample, and a second flips 8.7–18.9% of outcomes, making small gaps fragile; issues may overlap training data or repositories used during CQ2-CARE development.The gaps do not shrink detectably on newer issues.Source: Limitations · p. 9

Ethics Statement

The paper reports its evaluation used public open-source repositories and issues, with no human subjects or personal data. A randomly selected issue illustrates that one compressor changed code that other methods preserved verbatim.

Ethics Statement

  • The evaluation used public open-source repositories and issues, involved no human subjects or personal data, and ran generated patches only in isolated sandboxes.The authors say they will release code, prompts, and per-issue outcomes.Source: Ethics Statement · p. 9

A A Random Example

  • In the illustrated cabinetry issue, LongLLMLingua and LongCodeZip preserved the shown code region verbatim, while LLMLingua-2 altered it.The example was selected by salted hash from issues where the contexts shared a non-test Python file.Source: A A Random Example · p. 11
  • LLMLingua-2 dropped import keywords and punctuation and changed leading whitespace, so most shown lines no longer matched the source exactly.Source: A A Random Example · p. 11

B Implementation Details and Compute

The implementation compares budget-matched context methods using consistent model calls and official benchmark grading. It also documents operational constraints, planned and post-hoc analyses, and localization results against an uncompressed single draw.

B Implementation Details and Compute

  • CQ2-CARE keeps files named by two independent model answers and adds grep-found evidence spans, while the study uses consistent model calls and official SWE-bench grading.Contexts are budgeted with headers included; grading checks the benchmark’s FAIL_TO_PASS and PASS_TO_PASS tests.Source: B Implementation Details and Compute · p. 12

C What Went Wrong and What We Learned

  • Budget matching uses a fixed rate-setting grid and records misses; model-based compressors also faced memory failures, including four failed LongCodeZip contexts for Claude.Budget knobs are coarse, and the authors did not rerun compressors with other settings.Source: C What Went Wrong and What We Learned · pp. 13–14

D Planned and Post-hoc Analyses

  • The written analysis plan was not time-stamped, so the authors do not claim preregistration; file-level BM25 and several analyses were added post hoc.The dated design for the 300-issue corruption test was written before requests were sent.Source: D Planned and Post-hoc Analyses · p. 14

E Localization of the Variants

  • Against the uncompressed single draw, CQ2-CARE uses 0.68× the tokens with GPT-5.6 and is noninferior, with a 0.94 resolution ratio.The resolution ratio’s lower bound is 0.878, above the planned 0.85 margin.Source: E Localization of the Variants · p. 14

F Details of the Second-Model Run

In the Claude Opus 5 run, CQ2-CARE resolved more issues than the uncompressed single draw while using fewer tokens, though it narrowly missed the planned token-ratio margin. Heavy deletion also produced many unparsable patches in one compressor condition.

F Details of the Second-Model Run

  • Claude’s patches applied less often overall than GPT-5.6’s, and LLMLingua-2 context patches applied more often than LongLLMLingua’s, though the cause of the broader applicability difference was not isolated.Applicability was 83.3% for Claude on CQ2-CARE contexts versus 98.0% for GPT-5.6; LLMLingua-2 applicability was 80.7% for Claude and 70.7% for GPT-5.6.Source: F Details of the Second-Model Run · p. 14
  • Claude’s CQ2-CARE resolved 46.7% of issues versus 43.0% for the single draw at 0.73× the tokens, but missed the planned token-ratio margin.The token ratio’s upper bound was 0.757 against the 0.75 margin; the gold-file oracle resolved 46.3%.Source: F Details of the Second-Model Run · p. 15
  • On LongLLMLingua contexts, 36 of Claude’s 300 answers failed to parse, including 31 placeholder or empty patches; 35 of those issues had well-formed LLMLingua-2 patches.Source: F Details of the Second-Model Run · p. 15

G Details of the Analyses

The analyses compare CQ2-CARE with retrieval, compression, and reference contexts, including controlled tests of text corruption and budget effects. Results include a range of baseline gaps and rate-sweep comparisons across context sizes.

G Details of the Analyses

  • On the 177 issues where candidates exceeded the budget, token-level LLMLingua-2 trailed by 13.0 points, while LongCodeZip differed by 0.6 points.The candidate files averaged 16.1K tokens, compared with 20.1K for the single-draw context.Source: G Details of the Analyses · p. 15
  • The retrieval comparisons include BM25 over code chunks and files, dense chunk retrieval, and SweRank’s retrieve-and-rerank selection of whole functions.The reference contexts include gold files shown whole and verbatim, and an empty context.Source: G Details of the Analyses · p. 16
  • Across baselines, CQ2-CARE leads LongCodeZip by 9.0 points and chunk BM25 by 19.0; averaged over both patch samples, its leads are 6.3 points over LongCodeZip and 14.7 over LLMLingua-2.Source: G Details of the Analyses · p. 16
  • In the rate sweep, LongCodeZip reached at most 37.0% resolution, while exact-file contexts resolved 41.0–44.0% between 11.9K and 15.1K tokens.LLMLingua-2 reached 32.0% and chunk BM25 25.0% at about 13K tokens.Source: G Details of the Analyses · p. 16

H The Trained Methods and the Estimator

The estimator predicts held-out context performance accurately overall, while its error analysis attributes retriever and compressor deficits to different failures in showing changed lines. Tests on trained methods expose a post-hoc adjustment that still needs evaluation on an unseen method.

H The Trained Methods and the Estimator

  • Two-draw agreement improved localization F1 by +0.184 over a single draw, but a single draw cut to the same size was within 0.013.SweRank’s files are taken in ranked-function order, while SWE-Pruner retains the single draw’s localization.Source: Table 7 · p. 17
  • SWE-Pruner fell within the estimator’s prediction intervals, but SweRank resolved 5.3 and 7.5 points more than predicted; the κfn revision was post hoc and still needs an unseen-method test.The revision counts changed-line coverage only inside functions or methods and changes neither the fit nor its main-study prediction accuracy.Source: H The Trained Methods and the Estimator · pp. 17–19, Table 13 · p. 20
  • SWE-Pruner and SweRank contexts fit within ±2% of budget on 256/300 and 289/300 GPT-5.6 issues, respectively, while their within-window gaps to CQ2-CARE resembled the all-issue gaps.The reported gaps were 1.6 and 1.0 points with GPT-5.6, and 7.0 and 1.1 points with Claude, for SWE-Pruner and SweRank, respectively.Source: H The Trained Methods and the Estimator · p. 17
  • 11/11 GPT-5.6 contexts and 8/9 Claude contexts fell within the estimator’s 95% prediction intervals, with RMSEs of 3.3 and 5.1 points, respectively.Across all 33 GPT-5.6 settings, RMSE was 3.9 points.Source: Table 11 · p. 18, Table 9 · p. 18, H The Trained Methods and the Estimator · p. 18
  • Retriever deficits were attributed mainly to missing changed lines, while compressor deficits involved altered text and missing lines; methods resolved alike when every changed line appeared verbatim.Figure 5 groups unresolved issues by what the context shows of the gold patch’s changed lines; Figure 6 decomposes predicted gaps by estimator variables.Source: H The Trained Methods and the Estimator · p. 19, Figure 5 · p. 21, Figure 6 · p. 22

I Additional Tables

  • The appendix reports that whether gold files fit the budget does not separate the methods, and includes offline checks by issue date and within-issue regression.It also provides per-context details, estimator predictions for unseen trained methods, and tables of estimator variables and issue-level failure categories.Source: Table 9 · p. 18, Table 14 · p. 20, Table 15 · p. 21
Loading 2610.21073v1…