PaperlayerView exact revision on arXiv

Source-linked AI summary

CuraLoc: Repository-Level Fault Localization via Planned Code Inspection

Sangeeta Warrier, Anush Sankaran, Ryen W. White

arXiv:2610.31809v2cs.LGcs.SE

TL;DR

Bug reports describe failures but often do not identify where code should change, and interactive localization can require repeated model calls. CuraLoc plans repository inspection from compact symbol descriptions; on SWE Bench Verified with GPT-5.2, it improves Func@1 over LocAgent while using fewer recorded tokens. Its evaluation remains focused on pre-existing Python symbols in SWE Bench.

  • Problem

    Repository-level localization must identify code to edit even though bug reports describe failures and interactive methods may require repeated model calls.

    Source: §1 · p. 1

  • Method

    CuraLoc selects candidate files, jointly plans starting symbols, retrieval actions, and edit hypotheses from compact descriptions, then retrieves source deterministically for final ranking.

    Source: §1 · pp. 1–2

  • Results

    On SWE Bench Verified with GPT-5.2, CuraLoc reaches 59.3% Func@1 versus LocAgent's 53.8%, while using 90.3% fewer recorded tokens.

    Source: §1 · p. 2

  • Takeaways & Limitations

    CuraLoc's results show that issue-specific code inspection can remain adaptive without iterative model-directed retrieval steps.

    Source: §6 · p. 11

    Evaluation focuses on pre-existing Python symbols in SWE Bench, measures recovery of reference edit locations rather than every valid repair, and does not test downstream repair success.

    Source: §5 · p. 10

Abstract

from arXiv · show

A bug report describes what went wrong, but rarely where the code should change. Existing repository-level localization methods often let language models iteratively decide what code to inspect next, requiring repeated model calls and substantial token usage. We investigate whether these inspection decisions can instead be planned before source retrieval. In this research, we introduce CuraLoc, which first selects candidate files and represents their symbols using compact behavioral and structural descriptions. In a single planning decision, the model jointly selects starting symbols, chooses code relationships to inspect from each, and forms hypotheses about likely edits. Deterministic retrieval collects the requested source for a final ranking informed by those hypotheses, concentrating model reasoning on choosing and comparing code rather than directing each retrieval step. We demonstrate the efficacy of our proposed approach on the SWE-Bench Lite and Verified datasets. On SWE Bench Verified with GPT-5.2, CuraLoc raises Func@1 from LocAgent's 53.8% to 59.3% while using 90.3% fewer recorded tokens, and also outperforms RepoSearcher (56.2%) and Agentless (39.6%) on Func@1. On SWE-bench Lite, CuraLoc achieves a high 83.8% Func@5 accuracy improving on Agentless by more than 15% in relative accuracy. Additionally, CuraLoc supports different model backbones, with strong localization accuracy demonstrated using both GPT-5.2 and GPT-6 Astra. These results provide evidence that repository-level code inspection can be planned effectively without iterative model-controlled navigation.

1 Introduction

CuraLoc asks whether compact code descriptions can support accurate localization by planning inspection before source retrieval. It jointly selects starting symbols and retrieval actions, then ranks edit locations using retrieved code and its hypotheses.

Motivation

  • Localization targets files and symbols that should change, since code involved in a failure may differ from code responsible for the faulty behavior.For example, inspecting a validator's callers may clarify expected behavior, while inspecting a helper's callees may clarify its transformation.Source: §1 · p. 1

Research question

  • Fixed-rule methods expand locations by predefined procedures, while interactive agents adapt inspection after retrievals but require repeated model calls.CuraLoc tests whether compact descriptions can support accurate localization without repeated navigation decisions.Source: §1 · p. 1

Contribution

  • CuraLoc plans inspection in three primary-model decisions, adapting inspected code to each issue without repeated model-controlled navigation.The model selects candidate files, then jointly chooses starting symbols, retrieval actions, and edit hypotheses; deterministic retrieval gathers source for final ranking.Source: §1 · pp. 1–2

Results

  • On SWE Bench Verified with GPT-5.2, Func@1 rises from 53.8% with LocAgent to 59.3% with CuraLoc while recorded tokens fall by 90.3%.CuraLoc also has higher Func@1 than RepoSearcher and Agentless on Verified; on Lite it has higher observed symbol accuracy than Agentless and RepoSearcher at greater token consumption.Source: §1 · p. 2

Analyses

  • Component and failure analyses explain contributions from code selection, source inspection, and expansion, and identify where complete edit-set recovery still fails.Source: §1 · p. 2

2 Related Work

Prior repository-localization work includes interactive search, hierarchical localization, and graph context. CuraLoc instead plans both starting symbols and which code relationships to inspect.

Fault localization and interactive search

  • Interactive approaches let model decisions respond to investigation observations, including tool-based search, structured search, graph navigation, and priority-based exploration.RepoSearcher alternates reasoning and retrieval; ToolTrain trains models for this agent, while SHERLOC organizes iterative exploration around diagnostic hypotheses.Source: §2 · p. 2

Hierarchical localization and graph context

  • Hierarchical methods localize before patch generation, while RepoGraph supplies code relationships; CuraLoc selects a retrieval action for each starting symbol.Agentless uses hierarchical localization, RGFL adds issue-conditioned explanations [Sepidband et al., 2026], and RepoGraph supplies repository relationships [Ouyang et al., 2025].Source: §2 · p. 2

Planning and model context

  • Planning approaches separate reasoning from tool execution or schedule tool calls, and CuraLoc applies this separation to code retrieval and ranking.Compact symbol descriptions guide retrieval choices, while selected source code supports final ranking.Source: §2 · p. 3

3 Proposed Approach

CuraLoc narrows repository inspection through file selection, joint symbol-and-action planning, and source-based ranking. Each stage uses more detailed code information than the preceding stage.

3 Proposed Approach

  • CuraLoc returns up to ten ranked edit symbols from a bug report and pre-fix repository snapshot, using an AST-derived graph of symbols, locations, and code relationships.Its three primary-model decisions select files, choose symbols and retrieval actions, and rank edit locations.Source: §3 · p. 3

3.1 File Selection (S1)

  • S1 proposes files from ownership, execution, and enforcement perspectives, then ranks them by perspective votes and first appearance.The merged list contains at most 15 files and may be supplemented with bounded structural neighbors; rationales and annotations continue into S2.Source: §3.1 · p. 3

3.2 Symbol and Action Selection (S2)

  • S2 describes symbols using signatures, structural roles, relationships, and issue-independent behavioral summaries, then plans starting symbols, retrieval actions, and edit hypotheses.The RouteMap records symbol scores, issue-specific roles and rationales, issue-level hypotheses, and tuples of starting symbol, action, and likely-edit hypothesis.Source: §3.2 · p. 4

3.3 Source Retrieval and Ranking (S3)

  • S3 collects starting symbols and one-hop action-selected neighbors in round-robin order, retrieves bounded source windows, and ranks up to ten edit locations.It does not recursively expand neighbors; the final ranking prompt combines the issue, source, and RouteMap annotations.Source: §3.3 · p. 5

4 Experimental Results

CuraLoc is evaluated against three localization methods on SWE Bench Lite and SWE Bench Verified, with additional comparisons of its code-selection choices, evidence budgets, and a second model backbone. Its GPT-5.2 results show higher Func@1 than LocAgent on Verified with substantially fewer recorded tokens, while comparisons with lower-token alternatives show accuracy–computation tradeoffs.

4.1 Experimental Setup

  • The evaluation uses three runs per method with GPT-5.2 on 274 Lite and 454 Verified tasks; GPT-6 Astra comparisons use one Verified run per method.Func@k requires all reference edit symbols within the first k distinct predictions; recorded tokens include successful retained executions across contributing stages and samples.Source: §4.1 · p. 5

4.2 Localization Accuracy and Token Consumption

  • 59.3% Func@1 for CuraLoc versus LocAgent’s 53.8% on SWE Bench Verified, with 90.3% fewer recorded tokens.CuraLoc also reports 56.2% Func@1 for RepoSearcher and 39.6% for Agentless.Source: Table 1 · p. 5, §4.2 · p. 6
  • 83.8% Func@5 for CuraLoc versus RepoSearcher’s 78.3% on SWE Bench Lite, at 1.55× RepoSearcher’s recorded tokens.Against Agentless, CuraLoc’s Func@1 is 64.4% versus 46.8% at 1.71× its recorded tokens; the Func@1 difference from RepoSearcher is statistically unresolved.Source: Table 2 · p. 6, §4.2 · p. 6

4.3 Code Selection and Inspection

  • Replacing model-guided symbol selection with file-rank and source-order selection lowers Func@1 from 67.2% to 42.3%, despite the same candidate pool and evidence-symbol count.Selected evidence contains all reference edit symbols on 90.5% of tasks for CuraLoc versus 54.0% for the replacement; source-based ranking also reaches 67.2% versus 55.8% for the description-based ranking, without neighborhood expansion.Source: §4.3 · p. 8, Table 3 · p. 8
  • Adding related code raises Func@10 from 83.9% to 87.6%, with 11 paired gains and one loss, while aggregate Func@1 is unchanged.Across three Verified runs, 93.9% of CuraLoc’s Func@10 failures involve a reference edit symbol not selected for S3; when all reference symbols are selected, final ranking recovers the complete set in 98.4% of executions.Source: §4.3 · pp. 8–9

4.4 Evidence Breadth and Source Depth

  • Increasing candidate-file settings from F = 10, T = 3 to F = 15, T = 5 raises development Func@1 from 65.5% to 67.5% at 27.9% more S2+S3 tokens.With S2 fixed, L = 60 gives 67.2% Func@1 versus 65.0% at L = 30 and 66.8% at L = 100; Func@5 and Func@10 remain unchanged.Source: §4.4 · p. 9, Figure 4 · p. 9

4.5 Additional-Backbone Evaluation

  • With GPT-6 Astra on SWE Bench Verified, CuraLoc exceeds LocAgent and Agentless at every reported function cutoff and in MRR, while matching RepoSearcher’s 87.4% Func@5.CuraLoc’s Func@1 is 62.4% on the 370 tasks absent from Lite, versus 61.9% for RepoSearcher, 59.5% for LocAgent, and 56.8% for Agentless; total tokens are 138.9K including GPT-5.4-mini summaries, versus LocAgent’s 95.3K.Source: §4.5 · pp. 9–10, Table 4 · p. 10

5 Discussion

CuraLoc plans issue-specific inspection within a fixed decision schedule, but the accuracy–token tradeoff varies by backbone. Its evaluation measures recovery of reference edit locations for pre-existing Python symbols, not every valid repair strategy or downstream repair success.

5 Discussion

  • With GPT-5.2, CuraLoc improves both Func@1 and token use over LocAgent; with GPT-6 Astra, its higher accuracy comes with more total tokens when summary generation is included.Source: §5 · p. 10
  • Model-guided selection improves code coverage at the same symbol count, while source inspection with final ranking improves description-stage predictions; expansion recovers edit locations without changing paired Func@1.Longer snippets do not consistently improve ranking, and seeing reference implementations does not ensure their recovery in the final ranking.Source: §5 · p. 10
  • Evaluation covers pre-existing Python symbols in SWE Bench and measures reference-location recovery, so transfer to other languages, repositories, and downstream repair success remains unestablished.Reference patches identify one observed fix, although valid fixes may modify different code.Source: §5 · p. 10

6 Conclusion

CuraLoc plans repository inspection before source retrieval and ranks edit locations after deterministic retrieval. The conclusion reports improved SWE Bench Verified Func@1 over three baselines with GPT-5.2 and identifies broader transfer and downstream repair as future tests.

6 Conclusion

  • CuraLoc plans starting symbols and relationship-specific retrieval from compact descriptions, then retrieves source deterministically for a final edit-location ranking.On SWE Bench Verified with GPT-5.2, it improves Func@1 over all three baselines while using 90.3% fewer recorded tokens than LocAgent.Source: §6 · p. 11

AI use statement

  • The authors used generative AI across method and prompt refinement, experiment design, implementation, analysis, literature discovery, figure preparation, and manuscript drafting and editing.They report verification through tests, artifact reconciliation, source checks, and author review.Source: AI use statement · p. 11

Reproducibility statement

  • The reproducibility statement points to sections and appendices documenting the method, evaluation cohorts, statistical analysis, token accounting, interventions, and configuration sweeps.Source: Reproducibility statement · p. 11

A Method Implementation Details

The implementation constructs repository representations, compact symbol capsules, and a validated RouteMap, then retrieves prioritized source deterministically for final ranking. Its policies constrain symbol admission, neighborhood expansion, rendering, and output handling.

A.1 File Scoping and Supplementation; A.2 Structural Inventory and Capsules

  • File scoping ranks proposed files by perspective votes, truncates the union, and may supplement seeds with structurally neighboring files; the semantic inventory links symbols through calls, inheritance, overrides, and membership.Capsules carry symbol identifiers, descriptions, graph context, and summaries while the Stage 2 prompt receives capsules rather than raw source bodies.Source: §A.1 · p. 13, §A.2 · p. 13

A.3 Issue-Independent Behavioral Summaries

  • Behavioral summaries are issue-independent and selected from opening docstrings, cache entries, or an auxiliary model, with generated descriptions capped at 400 characters.The summarizer reads at most 100 source lines per symbol; tasks fail if fewer than 95% of symbols needing generated summaries receive them.Source: §A.3 · p. 14

A.4 RouteMap Validation

  • Stage 2 requests symbol relevance, ordered starting points with actions, and global causal hypotheses; validation discards unadmitted SIDs and rejects RouteMaps without valid starting points.A nonempty valid starting-point list outside the requested count is accepted and recorded diagnostically.Source: §A.4 · p. 14

A.5 Neighborhood and Prompt Ordering

  • Each starting point selects a one-hop action-specific neighborhood, and evidence is ordered across starting points round-robin rather than exhausting one neighborhood.Actions cover same-class methods, callees, callers, and related base or overriding implementations; selected neighbors must be in the admitted inventory.Source: §A.5 · pp. 14–15

A.6 Source Rendering and Fallbacks; A.7 Budget Enforcement and Output Handling

  • Source rendering uses a 60-line primary slice with explicit truncation markers, while budget enforcement retains the longest fitting priority-ordered prefix without backfilling.The final ranking uses one call for up to ten edit symbols restricted to those represented in the prompt.Source: §A.6 · p. 15, §A.7 · p. 15

B Graph Role Definitions; C Edge Resolution Confidence

D LLM Role Taxonomy

  • Stage 2 assigns eight issue-conditioned roles, including entry point, behavior definer, invariant enforcer, state provider, concrete owner, base contract, and companion.Source: D LLM Role Taxonomy · p. 16

E Capsule Format Example

  • The capsule example distinguishes public filter and exclude methods through their summaries while showing both call a shared helper.The excerpt preserves stored symbol identifiers and graph-consistent calls, while omitting caller lists, helper summary, and other fields.Source: E Capsule Format Example · pp. 16–17

F Evaluation Protocol Details

The evaluation uses shared SWE Bench Lite and Verified task sets with normalized, exact symbol matching and metrics requiring complete edit-set recovery at each cutoff. GPT-5.2 comparisons aggregate three runs, while the GPT-6 Astra comparison uses one Verified run per method.

F Evaluation Protocol Details

  • Evaluation covers 274 scoreable SWE Bench Lite and 454 Verified instances with pre-existing function- or class-level labels, and reference patches are withheld during localization.The gold files are those containing labeled symbols, and all methods use the same task sets.Source: F Evaluation Protocol Details · p. 17
  • Predictions and gold labels are normalized to file-qualified symbol identifiers and matched exactly, without fuzzy, substring, or partial-symbol credit.Duplicate predictions are removed while preserving their first occurrence.Source: F Evaluation Protocol Details · p. 17
  • Func@k requires all gold symbols among the first k distinct predictions, while MRR credits the first matching gold symbol even when a multi-symbol edit set is only partly recovered.Finalized execution failures count as misses.Source: F Evaluation Protocol Details · p. 17
  • Main GPT-5.2 comparisons average metrics from three completed runs, while the additional GPT-6 Astra comparison uses one SWE Bench Verified run and includes tokens from all contributing stages and samples.The GPT-5.2 methods retain their stated inference configurations, so these are same-primary-model comparisons rather than matched sampling budgets.Source: F Evaluation Protocol Details · pp. 17–18

G Statistical Analysis

The analysis uses paired task and repository resampling to assess uncertainty, adjusts joint accuracy–token comparisons across nine tests, and reports cohort-specific token accounting. It also documents seed sensitivity and limits on what the analysis supports.

G Statistical Analysis

  • Paired task bootstraps resample task IDs while retaining all three executions and use the same sampled IDs across methods and metrics.The 95% percentile intervals describe uncertainty across benchmark instances conditional on recorded executions, not the full variability of future model runs.Source: G Statistical Analysis · p. 18
  • Repository resampling preserves task weighting within sampled repositories, but its small repository count limits inference to sensitivity to the observed repository mix.The analysis does not assess performance on unseen codebases; Figure 5 compares task- and repository-bootstrap intervals, with intervals unadjusted for multiple comparisons.Source: G Statistical Analysis · p. 18, Figure 5 · p. 19
  • Joint accuracy–token comparisons require both multiplicity-adjusted lower bounds to exceed zero to support strict dominance.Nine comparisons produce 18 objective bounds, with lower-tail probability 0.05/18; unavailable Agentless token bounds retain their adjustment slots but yield no token or dominance conclusion.Source: G Statistical Analysis · pp. 18, 20
  • Seed checks preserve CuraLoc’s dominance over LocAgent on full SWE Bench Verified, while two other classifications are not seed-stable.The task-bootstrap Func@1 bound for CuraLoc versus RepoSearcher on SWE Bench Verified and the repository-bootstrap File@10 bound for RepoSearcher versus Agentless on SWE Bench Lite reach zero with the second seed.Source: G Statistical Analysis · p. 20

H.1 SWE Bench Verified Cohorts

  • The 454 scoreable SWE Bench Verified instances divide into 370 absent from SWE Bench Lite and 84 shared instances, by task rather than repository.The non-overlapping cohort is not an unseen-repository evaluation, and the overlapping cohort is included for completeness rather than as independent generalization evidence.Source: §H.1 · p. 20

H.2 Recorded Token Accounting

  • Recorded token averages use retained executions producing final predictions and include CuraLoc’s summary generation and all three primary stages.For GPT-5.2, three-run stage averages on SWE Bench Verified were 30.5K tokens for file selection, 43.1K for summary generation, 30.4K for symbol and action selection, and 21.7K for final ranking; Agentless token comparisons on this benchmark are unavailable for prompt-limit tasks.Source: §H.2 · pp. 20–21

H.3 Selection, Inspection, and Final Recovery

This analysis distinguishes explicit coverage of reference edit symbols from final recovery, using method-specific coverage definitions. Many CuraLoc failures coincide with incomplete selected-symbol coverage, while complete coverage does not guarantee recovery for either method.

H.3 Selection, Inspection, and Final Recovery

  • Coverage is method-specific: CuraLoc counts selected symbols before its final input-budget limit, while LocAgent requires complete reference implementations in tool outputs across two retained trajectories.CuraLoc’s selected symbols need not have their complete implementations displayed; LocAgent’s coverage is a union across trajectories, not proof that one model context contained all implementations simultaneously.Source: §H.3 · p. 22
  • Coverage records are not interchangeable measurements of final-model context, and LocAgent inspection coverage is unknown for 23, 24, and 31 tasks across the three runs.Those tasks remain in the accuracy denominator.Source: §H.3 · p. 22
  • Of CuraLoc’s 278 failed task–run executions, 261 have incomplete selected-symbol coverage (93.9%); 1,077 of 1,094 executions with complete selection coverage recover the reference edit set within ten predictions (98.4%).Incomplete coverage includes missing reference symbols in the S2 candidate set or complete candidate coverage but incomplete source selection.Source: §H.3 · p. 22
  • LocAgent has 182 failures despite complete source exposure, or 64.1% of its 284 failures, distinguishing code exposure from complete final recovery.Another 36 failures have unknown exposure.Source: §H.3 · p. 22
  • CuraLoc succeeds on three, one, and three tasks despite incomplete explicit selected-symbol coverage, so recorded coverage is not an absolute ceiling on localization accuracy.LocAgent has 13, 11, and 18 successful tasks with unknown coverage across the runs.Source: §H.3 · p. 22

H.4 Ablation Protocol and Diagnostics

The diagnostics compare interventions against a fixed SWE Bench Lite CuraLoc reference and separate changes to evidence selection, summaries, neighborhood expansion, and guidance. These interventions can change context as well as rankings, so they do not isolate ranking over identical evidence.

H.4 Ablation Protocol and Diagnostics

  • The fixed reference achieves 67.2% Func@1 and 87.6% Func@10 on the 274 SWE Bench Lite instances; interventions are evaluated separately, not cumulatively.The comparison is between complete guidance formulations, not rankings over identical context.Source: §H.4 · pp. 22, 24
  • The reference file-scoping output achieves 74.1% File@1 and contains all gold files within its top ten on 269 of 274 tasks (98.2%).The selection-stage row is an offline readout of saved S2 rankings; comparison with full CuraLoc combines neighborhood expansion, source evidence, and final ranking.Source: §H.4 · p. 23, Table 8 · p. 24
  • Replacing model-guided S2 selection with source-order selection produces net losses of 68 Func@1 and 89 Func@10 successes.Symbol counts are matched, not token counts; all gold symbols occur in the explicit evidence set on 148 tasks, compared with 248 for full CuraLoc.Source: §H.4 · p. 23, Table 8 · p. 24
  • Removing generated, cached, and docstring-derived summaries yields a net loss of seven Func@1 tasks while reducing recorded S2+S3 tokens from 51,985 to 37,927 per task.At Func@1, the intervention gains six tasks and loses thirteen; its stage-specific token totals exclude S1 and summary generation.Source: §H.4 · p. 23, Table 8 · p. 24
  • Removing neighborhood expansion leaves Func@1 with one gain and one loss, while Func@10 has one gain and eleven losses.S3 tokens decrease from 22,892 to 6,545 per task; the combined S2+S3 total is reconstructed using retained S2 usage, not a fresh execution of both stages.Source: §H.4 · p. 23, Table 8 · p. 24
  • The relevance-guided variant has 11 fewer Func@1 successes and 13 fewer Func@10 successes than the reference.It recomputes all three stages with issue-surface, execution-path, and dependency-context perspectives; the formulations may differ in selected files, evidence identities, and token use.Source: §H.4 · pp. 23–24

I Hyperparameter Sweep Details

The sweep selects file and source-depth settings on SWE Bench Lite while distinguishing replicated configuration averages from single-run alternatives. The reported alternatives expose accuracy–token trade-offs and source-depth sensitivity.

I Hyperparameter Sweep Details

  • The file-policy sweep varies F ∈ {5, 10, 15} and T ∈ {1, 3, 5} with L = 60, while the source-depth sweep fixes F = 10 and T = 3.The selected file-policy setting averages three development runs, whereas each alternative has one; the L = 60 source-depth row reuses a fixed reference result.Source: I Hyperparameter Sweep Details · p. 24, Table 9 · p. 25
  • F = 10, T = 5 improves Func@10 by 1.2 percentage points at 10.8% more tokens, while F = 15, T = 5 improves Func@1 by 2.1 points and Func@10 by 0.5 points at 27.9% more tokens.Compared with the selected Stage A mean, F = 5, T = 3 saves 19.3% of stage tokens while reducing Func@1 by 1.2 points and Func@10 by 1.3 points.Source: I Hyperparameter Sweep Details · p. 25, Table 9 · p. 25
  • Reducing source depth L from 60 to 30 saves 7.7% of S3 tokens, while increasing it to 100 adds 4.2%; Func@5 and Func@10 remain unchanged.S2 outputs and the ordered evidence-symbol set are fixed in this source-depth sweep.Source: I Hyperparameter Sweep Details · pp. 24–25

Related papers

Loading 2610.31809v2…