CuraLoc finds bugs in repositories with a single plan and uses 90% fewer tokens

Researchers on Sangeeta Warrier's team have proposed CuraLoc, a method for repository-level bug localization. It replaces a long chain of model calls with a single code-inspection plan. On SWE-bench Verified with GPT-5.2, the system reached 59.3% Func@1 versus LocAgent's 53.8%, and used 90.3% fewer recorded tokens. The preprint appeared on arXiv on 22 October 2026, and a second version followed on 26 October.

Why a bug report is a poor guide to where the fix belongs

A bug report describes a symptom: what broke and under what conditions. It almost never says where exactly the code needs to change. That is why bug-fixing agents have a separate localization stage, in which they must find the files and functions worth editing among thousands of candidates.

Most existing methods solve this iteratively. The model looks at the repository structure, picks a file, reads it, decides where to go next, and repeats. Each step means another LLM call and another batch of tokens in the context. The bill grows quickly, and quality depends on whether the agent takes a wrong turn onto a false trail at the third or fifth step.

The CuraLoc authors test a different hypothesis: decisions about what to inspect can be planned in advance, before any source code is loaded.

One plan instead of a chain of steps

The CuraLoc pipeline has several stages. First, the system selects candidate files and describes their symbols (functions, classes, methods) with compact behavioral and structural summaries. The source code itself does not reach the model at this stage.

Next comes a single planning decision. In one call, the model does three things:

• selects the starting symbols;
• determines which relations from each of them are worth checking (calls, dependencies, and other structural relationships in the code);
• formulates hypotheses about which edits are most likely.

After that, a deterministic search takes over. It collects the requested source code without involving the model. The model then performs a final ranking based on the hypotheses it has already formulated. Its reasoning goes into selecting and comparing code, not into steering every step of retrieval.

What the benchmarks showed

The authors tested the method on SWE-bench Lite and SWE-bench Verified. The main metric on Verified is Func@1, the share of cases in which the correct function ranks first. For Lite, the paper reports Func@5, where the correct function lands in the top five.

Comparison on SWE-bench Verified with GPT-5.2 by Func@1:

• CuraLoc: 59.3%;
• RepoSearcher: 56.2%;
• LocAgent: 53.8%;
• Agentless: 39.6%.

On token use, CuraLoc spends 90.3% fewer recorded tokens than LocAgent. This is no minor optimization: instead of dozens of model calls, the entire navigation collapses into a minimal number.

On SWE-bench Lite, CuraLoc scored 83.8% Func@5. Relative to Agentless, that is an improvement of more than 15%.

The authors also showed that the method is not tied to a single model. CuraLoc delivers strong localization accuracy with both GPT-5.2 and GPT-6 Astra.

What you can take away from this

The main takeaway for agent developers is that autonomous model navigation through a codebase does not always justify its cost. If you move some decisions into a deterministic layer and leave the model the tasks where it is strong (hypotheses about edits and comparing candidates), you can gain on both accuracy and cost in bug localization.

For teams building their own coding agents, this is a reason to revisit the token budget for the search stage. Localization comes before patch generation and determines whether the patch will be sensible at all. A cheap and robust first stage makes the entire fix cycle cheaper.

There are also limitations that the setup and the metrics themselves point to. All results come from SWE-bench Lite and Verified, which are Python repositories with known issues. How the approach behaves on closed monorepos and in other languages remains to be tested separately. But for the task of "finding the function from a bug report," CuraLoc makes a strong case for planning over wandering.

The paper is published in the Machine Learning section with a cross-listed Software Engineering (cs.SE) category, DOI 10.48550/arXiv.2610.31809.