Improving Code Localization with Repository Memory
Authors: Boshi Wang
Weijian Xu
Yunsheng Li
Xuemei Gao
Yujia Xie
Huan Sun
Dongdong Chen
Venue: ICLR 2026 Poster (2026)
Keywords: Code Localization
Large Language Models
Agent Memory
Primary area: foundation or frontier models, including LLMs
TL;DR: We improve code localization by augmenting language agents with repository memory built from commit history, and show that such memory could significantly boost performance on SWE-bench benchmarks.

Abstract: Code localization is a fundamental challenge in repository-level software engineering tasks such as bug fixing. While existing methods equip language agents with comprehensive tools/interfaces to fetch information from the repository, they overlook the critical aspect of *memory*, where each instance is typically handled from scratch assuming no prior repository knowledge. In contrast, human developers naturally build long-term repository memory, such as the functionality of key modules and associations between various bug types and their likely fix locations. In this work, we augment language agents with such memory by leveraging a repository's *commit history* - a rich yet underutilized resource that chronicles the codebase's evolution. We introduce tools that allow the agent to retrieve from a non-parametric memory encompassing recent historical commits and linked issues, as well as functionality summaries of actively evolving parts of the codebase identified via commit patterns. We demonstrate that augmenting such a memory can significantly improve LocAgent, a state-of-the-art localization framework, on both SWE-bench-verified and the more recent SWE-bench-live benchmarks. Our research contributes towards developing agents that can accumulate and leverage past experience for long-horizon tasks, more closely emulating the expertise of human developers.

Published as a conference paper at ICLR 2026
IMPROVING CODE LOCALIZATION WITH REPOSITORY MEMORY
Boshi Wang" Huan Sun
Weijian Xu o Dongdong Chen
Yunsheng Li
Mei Gao
Yujia Xie
*hhe Ohio State University wang. 139300osu. edu
Microsoft
ABSTRACT
Code localization fundamental challenge in repository-level software engi- neering tasks such as bug fixing. While existing methods equip language agents with comprehensive tools/interfaces to fetch information from the repository, they overlook the critical aspect of memory, where each instance is typically handled from scratch assuming no prior repository knowledge. In contrast, human develop- ers naturally build long-term repository memory, such as the functionality of key modules and associations between various bug types and their likely fix locations. In this work, augment language agents with such memory by leveraging a repository's s commit history-a a rich yet underutilized resource that chronicles the codebase's evolution. We introduce tools that allow the agent to retrieve from non-parametric memory encompassing recent historical commits and linked is- sues, well as functionality summaries of actively evolving parts of the codebase identified via commit patterns. We demonstrate that augmenting such memory can significantly improve LocAgent, state-of-the-ar art localization framework. on both SWE-bench-verifee and the more recent WWEE-bnnc--ive benchmarks. Our research contributes towards developing agents that can accumulate and leverage past experience for long-horizon tasks, more closely emulating the expertise of human developers.
INTRODUCTION
Repository software engineering tasks, such as bug fixing, are a promising application for Large Language Model (LoMe-powered agents (Jimenez et al. 2024). A crucial first step in these tasks is code localization:
identifying the specific files and code segments that need to be modified to resolve the issue at hand. Existing methods mainly focus building powerful toolsets that help agents
navigate and reason over code relationships (Liu et al.) 2025 Yu et al., [025 Ouyang et al. 2025 Chen al. 20256; Ma et al. 2025). A leading framework LocAgent (Chen et 2025b). which parses codebases into directed heterogencous graphs that capture code structures and dependencies,
enabling effective search for relevant entities.
Despite steady progress, current approaches share a key limitation: they treat every problem as fresh puzzle, solved from scratch assuming no prior knowledge of the repository. Human developers, by contrast, accumulate and leverage long-term repository memory over time-this includes cached understanding the purpose of core and actively evolving modules, and various associations between recurring bug patterns and their likely fix locations. This accumulated memory is what allows developers to grow into experts codebase.
The importance of such memory is also clear when looking at failure cases of existing localization frameworks. To illustrate, consider a failure case LocAgent on bug in the djjang repository from SWE-bench, as illustrated in Figure 2 The example is about djjngo's migration system, which generates migration programs from a user-defined schema. Here, the challenge is to find where import statements for certain base classes are synthesized, since the bug stems from missing imports in the generated program. Without prior knowledge of the repository, an agent must embark on a
Work done intern Microsoft.

---

Published as a conference paper at ICLR 2026
Issue Description
Missing Import statement in generated migration Erron 'models' not defined)
Given the following contents of models.py: from djjngo, db impori models
class modici ToxtHoldy.
Recent history commits
Liteeeeattdd
peramettr..
Thought
?po Maintainal import order to nigration willer iitrenggntins meer
Action
SewroCGnnviif mignation file wissing impert
oftee dunggud megatteeccettte.....
Tooling
atstemeso))
ponsbaly ormaer auports.
Observation
fonuf intt... wtw.iaansssrlllaagg.......
fyan djung eiseetrationn
>_
SearchCommit
the poutieitty of ctrculer imports. (cauf die diveiigraiinnnee pevtaainiiiiiiio pas.alleerrpp........... pl
ExamineCommit
Summary of actively evolving files
Thought
ViewSummary
Action
Viles Ujang miciiie diffus gurry promatur for Ojange's GRM (CHjun Seutiooaa Migping!...
ViewSormary ielpeetttteeeeerittttaaar
Phanaratingiic "ivee divesgnations?
>_ SearchSummary
Observation
This prosidu miditaave
aponut Suqust Fongey
(+ existing tools)
modiale prosider various snialtor classes answer Pythox obyests mis
This wodlie porkids wansu se srltttrr disses conoent Pyshan obfects vnio remsiaed firm auiakic mugntiin fio relans rppsictttiinn the abyect necunery repar distmuuts...
Localization
a) Constructing Repository Memory
b) Integration Agentic Frameworks
Figure I: An overview of repository memory design. (a) We construct the memory by leveraging recent commit history of the repository. This involves creating searchable database of past commits and their linked issues, and identifying frequently edited files to let LLMs generate high-level functionality summaries. (b) The memory accessed by the language agent via a set of tools that perform search based custom queries and support closer examination of individual memory entries. Details
3
complex investigation, carefully tracing data/control flows and function calls across different folders and files find the source of the In this example, while the agent successfully located some initial key entities, it eventually failed to complete the reasoning chain and stopped prematurely.
Experienced developers would likely approach the problem differently. They could draw episodic memory of past issues/codebase changes related to the migration system, or recall from semantic memory the modules that potentially responsible for handling such imports within the codebase. These memories could provide strong priors for the investigation, guiding the search/reasoning to more efffectively reach the error source.
How can we equip agents with such kind of memory? We propose to leverage the repository's commit history-a natural record of its past evolution. particular, new problems are often connected to some past changes, where the related commit patches and linked issue contents could provide valuable data source for approximating the episodic memory. Commit statistics could also naturally reveal which parts of the codebase are most active, making them prime candidates for building semantic memory. Returning to the example Figure 2 we find that even simple keyword search ("migration". "import") over the commit messages retrieves many related history patches in the django migration system, such as problems with circular imports and nested classes. Likewise, analyzing commit frequency highlights the target file module under active development, and a pre-computed summary of its functionality imnctoonlity-managinng object-to-string conversion and import statements could provide strong signal of its relevance to the issue.
Building on these intuitions, we design two simple memory mechanisms to augment existing frame- works:
2

---

Published as a conference paper at ICLR 2026
Loctliaation LocAgent
Description
Action: owppe___ecccpaapoo..p. www.ieeeeeeeeeeeeece areinanggeeee................... (..))
Klaving impoct staxement in generated maggeass (NandEErre: came cudes is con deinel))
Oburvation...
Eiven the following conters molekky
The makem stone command will genenoe the folowwng migratann fil:
Action: art Lnttllen aormannnnnninnnnnennnnn... "...)
Oburration:
from durgeuah di mosill
imsert ap3.mados dyngs ruggetturu Mignsiinniignnnnii Migrstieet
abutrect
onfwntt sigratin, Sintshangui di enir megistinn Jisttely.....
hauer (ayp darprrdaeeeddeli sendel Myatoo,, Madell
dlos MyMos Misiss MyJisckaaiii nuse Agynddlgetaary...oo Jay Trac)
Namserrrn name 'mdidi not defined
witte sigadtenttmmrtiigtiiinn siff pociade Asader)
Hlstoor Commits (keyword search) odruss Flodt
Suppedulbeing cxpttally speiiit migusios maisit
(iiminttarrlladdrryy deongstersigeeneee Jbiunntttann/viiiiggg sfrcect Maved djongeal mipullen..ntt....... Rabus pouthalyy cinaaii inpoes. lone iik ey, atl/siigniim//eeniiiii po dbtiggniioneeete py!
Migratas Wiider dgar origgiey)
ax7d774 Expicotly inperted regranen spencioou in sptintzer. [Bboegguiinnggginnnnnll 150trga] Flon vedilnattoo of of clanss regranio
LocAgent localization
for opersmen is anfiengntiorrpppnn speraticee
sperasion ieparts OfersnieeVVierrreeennttt jesitleed
Source Code of target file(s) (chimignntionnirrrttttrrr
imperta oww.oooogmtttsnnnnngoooooo
dase Setkerisken (Budoquunnceeniita
dou tysdesshheeluueeetttae sstalle//ee
senallee vsluah:
def Semmetunt
futeryyaalut
7M6s abe lettle"
special
(nokk Mudel 'sakk. Medk""
Buckonznsdenstta Badkeiiilar araalngeell
ayddersaseeetttooeeeeeeeeeee do Srmmstittt
(9oe(looe), bys//itex)) for uld strig iepart is upscol rnture rring artimpert))
for New sqteelse
acralizer jelatad jrtallee_fistagiiueen
tiee arrog nen, ieports setainer alented genatoy))
LLM summary: Thr madale prosii arr arilleer clusr comrt ebject isto artaltee from cattable aignation fire The avdall reclden has dis Hauderiater oxd serialier implenzuss suommry report suppings alliwin say regimatiis vage
oien Dypceershan/dduee (underssaanr
petalio Kaly. Ground localization
aring dan reguty of typ-
Figure (Left) Localization trajectory of a failure case of LocAgent on SWE-bench-verified (django_ dijagoo-jj- While the agent successfully traces some initial key entities, it fails to reason in greater depth and granularity to pinpoint the error source, resulting in wrong localizations. (Right) The original issue description (top), accompanying history commits obtained via simple keyword search on commit messages (middle), the source code and L.LM-generated functionality summary of the ground truth target file containing the error source (bottom).
Episodic Memory of Past Commits. We crawl and preprocess the commit history and linked data, and provide tools for agents to 1) search this corpus via custom queries that are matched with the commit messages, and 2) examine the details of individual commits, such as linked issues and commit patches. The episodic memory allows agents to reference past codebase changes to aid in resolving the current issue.
Semantic Memory of Active Code Functionality. We identify the most active parts of the codebase by analyzing commit frequency to find the most frequently edited files. For these key files, we use LLM to generate high-level summaries of their functionalities. This creates compact knowledge base of the most dynamic parts of the codebase, which the agent can query to understand the purpose of potentially relevant modules.
Experiments show that augmenting LocAgent with these memory components could significantly im- prove localization performance, where we observe strong gains on both SWE-bench-verified (Jimenez ct al. 2024) and the more recent SWE-bench-live (Zhang et al. 2025) benchmark.
To summarize, we make the following contributions:
We identify the lack of long-term memory as a critical limitation in current language agents for repository-level software engineering tasks such as code localization.
We propose to leverage commit history a natural and rich source for building repository memory, and introduce two simple memory mechanisms-epissee memory of past commits and semantic memory of active code functionality- that integrate easily into existing frameworks.
We show that these mechanisms yield substantial improvements in code localization, highlighting the value of incorporating long-term memory into agent workflows.
3

---

Published as a conference paper at ICLR 2026
2
RELATED WORK
2.1 CODE LOCALIZATION IN REPOSITORY-LEVEL SOFTWARE ENGINEERING TASKS
Existing methods for code localization could be broadly categorized into three types: 1) retrieval- based, 2) agentic approaches and 3) procedural approaches.
Retrieval-based methods represent the most conventional approach, leveraging lexical or semantic matching rank code snippets based their proximity to the query (Wang al. 2025b). Recent advances have focused on improving the quality of code embeddings, often through contrastive learning objectives (Li al. 2022; Wang al.) 2023] Zhang et al. [2224]] Suresh et al., (025)). Among these, CoRNStack (Suresh et al. 2025) represents the current state of the art, achieving strong performance through large-scale training coupled with rigorous data filtering and hard negative mining strategies.
Agentic frameworks. Agentic approaches augment LLMs with the ability to interact with an external environment to gather information via a set of tools/interfaces. where the major focus has been to improve the comprehensiveness of the tool designs YYang et al. 2024 Cognition 2024 Orwall 2024
Zhang al., 2024b; Chen et al., 2025b; Wang et al. 2005al] Yu et al. 2025| Ouyang al. 2025 Ma
ctt al. 2025 Liu et al., (025). Notably, LocAgent (Chen et al. 2025b) is a SoTA agentic framework for code localization. It parses codebases into heterogeneous graphs capturing code structures and various kinds of dependencies (e.g., import, invoke and inherit relationships), which allows LLM agents to more effectively comprehend and navigate through the codebase.
Procedural approaches directly employ LLMs to perform localization in a pre-designed proce- dure (Zhang et al.) 2023 Wu al., 2024 Xia et al. 2025 Liang al., (024). which avoids the complex setups of agentic approaches. The most representative and high-performing method is Agent- less (iia et al. 2025), which performs localization by prompting LLMS with the issue description and a concise representation of the repository's 's file and directory structure.
2.2 JUST-IN-TIME SOFTWARE DEFECT PREDICTION
Our work shares basic intuitions with the field of Just-in-Tine Time Software Defect Prediction (JiT-SDP), which aims predict the likelihood that a specific code change (e.g., commit) is defective immediately after submission (Zhao et al. 2023). JiT-SDP leverages historical data as code churn, diffusion, developer experience, and commit message metadata-to assess risk (Kamei et al. 2012 Yang et al., 2015). While JiT-SDP focuses predicting the introduction of bugs based evolutionary patterns, our framework utilizes similar historical signals (commit history and file activity) to help agents localize and fix reported bugs. Specifically, adopt the intuition from JiT-SDP that "hotspots" (frequently modified files) and historical commit contexts are strong indicators of where defects and their solutions reside.
2.3 MEMORY-ENHANCEL LANGUAGE AGENTS
Our work is connected with the broader literature on enhancing language agents with memory or experience (Qian et al., 2024 Chen et al. 2025a Wang et al.) 2024 2025c Zheng al., 2025). The most related work arguably [hen et al. (2025a), which distills procedural knowledge from an agent's past success and failure trajectories to facilitate online moblemm-ollving. Orthogonally, our approach leverages commit histories to construct a repository-speciff memory, providing knowledge that is grounded in the codebase's 's evolution rather than the agent's 's individual experience.
REPOSITORY MEMORY
To bridge the gap between memoryless agents and experienced developers, we tap into the repository's commit history-a rich, structured chronicle of its evolution. We structure this historical data into two complementary memory stores, designed to be lightweight and easily integrated into existing agentic frameworks. The first, episodic memory, captures the narrative of specific past changes. The second, a semantic memory, distills high-level functional knowledge about the codebase's most dynamic areas. An illustration of this design provided in Figure
4

---

Published as a conference paper at ICLR 2026
3.1 EPISODIC MEMORY OF PAST COMMITS
Memory Construction. This memory captures concrete entries of past problems and their solutions. We build a structured corpus from the repository's recent commit history, storing the code patches and also the rich metadata surrounding them: commit messages, timestamps, and links to associated issues. The corpus only includes commits made prior the issue to be resolved (to avoid contamination). We further filter this datastore to remove issues that have overlapping text with the test instance and commits that are linked to these issues, to prevent leakage.
Memory Interfaces. The agent interacts with this historical database through a dedicated interface, allowing to query for past events that are related to its current task:
SearchCommi t (query, top_k): This tool performs case-based retrieval. The agent can issue a query, which could be derived from the given bug report or current problem-solving state, to find semantically related historical commits. We use BM25 for matching the query against the commit messages, as it is highly effective for the semi structurddd keyword-rind nature of commit messages. The interface returns ranked list of the top-k relevant commits, including their unique IDs (commit SHAs), messages, and modified files the commit patch.
ExamineCommt t (id): : Once a potentially relevant commit identified, this tool allows the agent to "zoom in" and retrieve its full context based on its ID, including the complete code patch (in diff format) and any linked issues, providing a comprehensive view of the original problem and its corresponding solution.
By using these tools, the agent can ground its reasoning in historical precedent, leveraging past solutions powerful exemplars to aid in its understanding of the codebasc/problem and guide its investigation.
3.2 SEMANTIC MEMORY OF ACTIVE CODE FUNCTIONALITY
Memory Construction. While episodic memory provides specific examples, semantic memory offers a generalized, high-level understanding of the codebase. The rationale that files frequently modified in the recent past are "development hotspots" areas that are either central to the repository's functionality or are undergoing active change. Research in defect prediction has long established that high code churn and frequent modifications correlate strongly with defect proneness (Nagappan & Ball 2005; Zhao et al. 2023), making these files prime candidates for the agent's 's attention. We first analyze the commit history to identify the top-k most edited files, where is much smaller than the total amount of files in the codebase. Then, for each of these files, we use an LLM to read its source code and distill its functionalities into high-level natural language summary (details in Appendix(A) A). This process creates compact semantic knowledge base that maps critical files to their core responsibilities, focusing exclusively on the most dynamic parts of the repository.
Memory Interfaces. The agent accesses this knowledge base again through simple query interface:
ViewSummary (file_name): This retrieves the cached summary for specific file (if exists in the memory), allowing the agent to quickly understand file's purpose without needing to read its entire source code.
Sear SharchhSummazy (query, top_k): This allows the agent perform keyword-based search over the entire collection of file summaries. It returns the top-k most relevant (file, summary) pairs, helping the agent to locate modules that are related to the issue or current exploration intent.
The semantic memory provides the agent with crucial architectural context, biasing search towards more promising areas and preventing it from getting lost in the vast, irrelevant or stable parts of the codebase.
3.3 INTEGRATION WITH LOCAGENT
The memory tools are designed to be modular and be straightforwardly integrated into existing agentic frameworks. In this work, we integrate them into LocAgent, a state-of of-tee----h--rrr localization framework that operates based on the ReAct paradigm (ao al. 2023). A Locwgeet-powered agent
5

---

Published as a conference paper at ICLR 2026
iteratively eycles through "Thought, Act. Observation" loop. In the "Act" step, it synthesizes API call to one of its available tools, whose execution feedback is returned to the agents via the next "Observation" entry. For context, LocAgent's core tools allow it to navigate a heterogeneous graph representation of the codebase:
SearchEntity: Searches the codebase for entities matching keyword query, typically serving as an entry point for exploration.
TraperseGraph: Performs multi-hop, type-aware breadth-first search from starting entity to explore code relationships, which include 1) basic contain relationships between folders and files, 2) invoke relationships between functions and classes, 3) import relationships from files to functions/classes, and 4) the inherit relationship between classes.
Retri intrriiveEniiii tt:: Fetches the full source code and detailed information for a specific code entity (e.g., a file, class, or function).
Our integration simply expands the action space with the memory-based tools, as illustrated in Figure [ Intuitively, the memory-based tools could nicely complement the existing toolset in LocAgent. For example, an agent can now use memory search tools to fetch related commits or files, combined with concrete examination of individual entries when necessary, to form an experience- based hypothesis. can then use LocAgent's ' tools to perform a more detailed investigation of the code entities surrounding these candidates. This creates a powerful synergy between high-level, nemory-guided direction and lowelevel, structural code analysis.
4 EXPERIMENTS
4.1 SETUP
Datasets. We evaluate our approach on two benchmarks: SWE-bench-veriffed (Jimenez et al. 2024), which contains 500 examples from 12 repositories, and the more recent SWE-bench-live (Zhang et al.) 2025) benchmark. For SWE-bench-live, we use a high-quality subset created from the intersection of its "lite' and 'verified' splits, filtering for instances requiring five or fewer files to be modified. This results in 130 examples across 62 repositories.
Baselines. We compare method, RepoMem, against several state-of-the-art methods in different types of approaches:
CodeRankEmbed (Suresh et al. 2025 leading retrieval-based method leveraging large-scale training with careful data filtering and hard negative mining.
Agentless (Xia et al. 2025). a leading procedural method that prompts LLM with repository
structure.
LocAgent (Chnn al. 2025b), state-of-the-ane art agentic framework for localization as discussed earlier, which our RepoMem method is built directly upon. This also allows for a direct comparison of the impact of integrating repository memory.
Evaluation Metrics. We evaluate file-level localization performance via Accuracy @k (following prior work (Chen et al. (2025)), defined as the percentage of examples where the set of top-k predicted files completely covers the ground-truth files.
Implementation Details. All experiments use GPT-4o (2024-05-13) as the backbone LLM. For memory construction, we consider the 7,000 commits prior to the given issue's base commit, and identify the top 200 most frequently edited files for constructing the semantic memory. While we employ a fixed window size straightforward heuristic, the rich literature in JIT-SDP suggests that more sophisticated filtering strategies- -such as time-decay, developer experience filtering, or co-change history (Zhao al. (023)) could further optimize memory efficiency and relevance. We leave the exploration of such domain-informed strategies to future work. Additional discussions on memory construction provided in Appendix A
4.2
MAIN RESULTS
Table presents the main experimental results. We include additional results in Appendix B Re- poMem consistently outperforms baselines on both benchmarks. On SWE-bench- verified. RepoMem achieves Acc 5 of 76.5% 16.5% 4.9% absolute improvement over the strong Loc LocAgent baseline. The

---

Published as a conference paper at ICLR 2026
Table 1: Main results code localization benchmarks. RepoMem significantly outperforms all other methods across both benchmarks, demonstrating the effectiveness of incorporating repository memory. Both episodic and semantic memory components contribute positively, with their combination yielding the best performance.
wer-eeech-verffiedd
EWE-bench-lie 3cc@3
Methods
Acc@1
Acc@:3
Acc@
Acc@
A
Embed (Suresh et al.
2025)
29.6
26.2
44.6
$2.3
Agentless (Xia ct al. 2025)
53.3
67.8
71.4
40.0
60.0
62.3
LocAgent (Chen ct al. 2025b)
64.8
70.4
71.6
59.2
60.8
63.1
RepoMem (episodic-only)
67.8
72.4
74.3
60.0
61.5
64.6
RepoMem (semantic-only)
65.0
71.0
72.8
56.9
61.5
63.9
RepoMem
68.6
74.5
76.5
60.8
63.9
66.2
Table Per-repository performance comparison (Aco@5) on SWE-bench-verifee Repositories are sorted by the average number of historical commits available, where "others" is the union of repos with less than 10K commits. Our method sees strong gains in repositories with rich commit histories but can be hindered in those with limited or irrelevant history.
Repo
malplotlib
sympy
astropy
django
scikit-learn
sphinx
pytest
others
Examples
34
73
22
231
32
44
18
46
Avg. Commits
43.9K
39.8K
31,2K
29.2K
25.
17.2K
12.4K
4.5K
LocAgent @
76.5
69.9
86.4
72.3
93.8
47.7
61.1
67.4
RepoMem
(+5.9)
(+2.7)
(+0.0)
(+7.4)
(+3.1)
59.1 (+11.4)
77.8 (+16.7)
54.3 (-13.1)
gains are also consistent on the more diverse SWE-bench-live dataset. Ablating on the effect of each memory, using only episodic memory ('episodic-only provides a significant boost over LocAgent, demonstrating the value of referencing past commit history. Similarly, using only semantic memory (' ('semantic-only') also improves performance by helping the agent focus on actively developed parts of the codebase. The best results are achieved when both memory components are combined, indi- cating that they provide complementary information: episodic memory offers concrete solutions to similar past problems, while semantic memory provides high-level architectural context for the agent to leverage.
Table provides breakdown performance by repository on SWE-bench-verified sorted by the average number of historical commits available. The results reveal clear correlation: repositories with a rich commit history benefit the most from RepoMem. This strongly supports our hypothesis that commit history is valuable source for memory building. Conversely, for the "others" group which consists of repositories with limited history, performance degrades. This is likely because the memory contains too little relevant information, and the agent's exploration of this sparse history can be more distracting than helpful.
4.3 ANALYSIS
We perform series of analyses of RepoMem on SWE-bench-verified, to gain deeper insights into the effect of integrating repository memory.
Shift in Agent Behavior. The introduction of memory drastically alters the agent's problem-solving strategy. As shown in Figure agents equipped with the memory significantly reduce their reliance on exhaustive exploration tools (TraverseGraph) and direct code inspection (Ret eveënt ty). This reflects a strategic shift from brute-force navigation to more targeted, hypothesis-driven investigation, where the agent integrates its accumulated repository knowledge form hypotheses, and performs detailed exploration/ verification exploration/verification leverating the original LocAgent tools process that more closely mirrors experienced human developer's workflow.
Efficiency Analysis. We find that integrating the memory introduces a strategic effetctfecs trade-off instead of uniform overhead. First, shown in the cross-comparison in Table 3] the additional expenditure is primarily allocated to solving difficult problems the most sigmficant cost increase occurs in examples where LocAgent fails. This indicates that overall, method
7

---

Published as a conference paper at ICLR 2026
4.0
LocAgent RepoMem
3.5
&Callfrragge
2.5
2.0
1.5
1.0
0.5
0.0
Paviratrmph
Savcafmiity
SnatiCimmt
CominrCamed Commll
wirestemmay
Figure 3: Tool use distribution for LocAgent vs. RepoMem. The introduction of memory-based tools drastically alters agent behavior. RepoMem significantly reduces its reliance exhaustive exploration tools like TraverseCraph and direct code reading (RetrieveEntiee ity), indicating strategic shift from brute-force navigation to more targeted, hypothesis-driven investigation guided by memory.
Table 3: Cross-comparison of LLM API cost (LA: LocAgent, RM: RepoMem). Each cell shows the average cost per example for LocA- gent + RepoMem. The largest cost increase occurs in the bottom two quadrants, which are examples where LocAgent fails. This indicates that the additional cost is primarily a strategic in- vestment to improve accuracy on difficult tasks.
Table 4: Impact of retrieval method for mem-- ory interface on the performance of django repository. Sparse retrieval using BM25 with a custom LLM- tokenizer outperforms both a standard tokenizer and strong dense retrieval model (GritLM-7B).
django/django Acc
Retrieval Methods
Acc
Acc
RM Succeeds
RM Fails
Dense retrieval
65.8
71.9
73.6
LA Succeeds
S0.58 $0.68
$0.59
$0.66
BM25 (whitespace)
67.1
74.5
77.9
BM25 (LLM)
70.1
76.6
79.7
LA Fails
S0.54
$0.89
$0.59
$0.87
strategically invests additional resources to solve challenging problems that the baseline cannot, rather than spending wastefully on problems that could already be solved without resorting to the memory.
More interestingly, the cost impact is highly variable at the instance level. Figure 4 shows seatter plot of per-example costs, again cros-compariig the two methods. While the average cost increases, the plot reveals high variance across the examples. For many problems, RepoMem is significantly cheaper than LocAgent (points far below the diagonal), likely because the memory provided more direct hint to the solution. For some others, it could instead be much more expensive (points far above the diagonal), likely on problems where the memory proved fruitless and only added overhead and distractions. This heterogeneity highlights that average cost can be misleading metric, and the efficiency of our memory augmented agent is highly dependent on the relationship between the current problem and the repository's history.
These findings also suggest promising future direction: training agents to be more strategic about when to use memory tools. An agent that could first assess problem's novelty might learn to rely on memory for issues that are related the past experience, while defaulting first-principle explorations for unprecedented ones, optimizing the cost-effectiveness trade-off.
Retrieval Methods for Memory Interfaces. Here, we investigate the choice of retrieval method for our memory interfaces. We compare three approaches on the djjngo repository, with results shown in Table 4 Here, we use the strong GritLM-77 7B model for dense retrieval (Muennighofi et al., (025). Our default method in the main results uses BM2 with LLM-based tokenizer that recognizes code entity names, which outperforms standard whitespace tokenization. More notably, sparse retrieval methods significantly outperform dense retrieval. We hypothesize this is due the unique vocabulary
8

---

Published as a conference paper at ICLR 2026
LA Correct RM Wrong
Wrong
LA Woog
RM Wrong
RepoMem (S)
2 LocAgent ($)
Figure 4: Per-example cost comparison (LA: LocAgent, RM: RepoMem). This scatter plot shows the LLM API cost for each example. where the and y coordinates correspond to the cost of LocAgent and RepoMem, respectively. Points below the diagonal line indicate RepoMem was cheaper, while points above indicate it was more expensive. The high variance reveals that the efficiency impact of integrating memory is problem-dependee some tasks but incurs overhead on others, nuance missed by average cost metries.
it provides significant savings on
of code-related utterances in software repositories-ffr example, entities like 'Migration Cretrttionriter" Writer' and 'Operation Writer' may be semantically close but are functionally very distinct. Sparse retrieval methods, which rely on exact keyword matches, excel at handling this "rigid" vocabulary. Similar phenomena are also observed in prior work, e.g., SSciavolino et al. (202T) finds that dense retrievers could drastically underperform sparse methods in entity-centric question-ann answerrin.....
Error Analysis. We conducted a small-scale analysis of the failure cases of RepoMem to better understand its limitations. As expected, the primary failure mode occurs when memory retrieval yields little useful information about the issue, problem stemming from either the novelty of the issue or shortcomings the retrieval methods. such instances, the agent receives irrelevant information that can pollute its reasoning context and distract it-a well-know challenge for LLMs (Shi et al. (003)). This can lead to performance worse than the baseline, as observed in repositories with sparse histories (Table 2). These findings highlight promising directions for future work, such designing/trainine better memory interfaces and developing mechanisms that enable the agent to dynamically decide whether rely the memory instead fall back on first-principles reasoning (as discussed earlier).
5 CONCLUSION
In this work, we take an initial step toward addressing key limitation of current language agents for software engineering: their lack of long-term repository memory. We propose simple yet effective solution that leverages the rich contextual information embedded repository's s commit history. By building two complementary memory stores- episodic memory of past commits and linked issues, and a semantic memory of active code functionality-wwe enable agents to draw on past knowledge when tackling future tasks. Our experiments show that this memory-augmennt substantially improves code localization performance on established benchmarks. Further analysis reveals shift in agent behavior toward more experience guided strategy that better reflects human expertise. Overall, this work underscores the importance of incorporating long-term memory into agent workflows, paving the way for more capable and experienced software engineering assistants.
approach

---

Published as a conference paper at ICLR 2026
ETHICS STATEMENT
All authors of this paper have read and adhered to the ICLR Code of Ethics. Our research is built upon publicly available datasets, which are derived entirely from open-source software repositories. The study does not involve human subjects, and our data processing steps do not introduce any new ethical concerns regarding privacy, bias, or fairness. The proposed methods are designed for software engineering assistance and do not present foresecable risks of misuse negative societal impact.
REPRODUCIBILITY STATEMENT
We have made every effort to ensure our work is reproducible, Our experiments are conducted on the public SWE-bench-verifeer and SWE-bench-live benchmarks. The methodology for constructing the episodic and semantic memory components is detailed in [ and the implementation details are provided in $4.1 To further facilitate replication, we provide comprehensive documentations, examples, and prompts used for our agent in Appendix [[add Appendix The source code for our framework and experiments will also made publicly available upon publication.
REFERENCES
Adrian Bachmann, Christian Bird, Foyzur Rahman, Premkumar Devanbu, and Abraham Bernstein. The missing links: bugs and bug-fix commits. In Proceedings of the eighteenth ACM SIGSOFT international symposium on Foundations software engineering, pp. 97-106, 2010.
Silin Chen, Shaoxin Lin, Xiaodong Gu, Yuling Shi, Heng Lian, Longfei Yun, Dong Chen, Weiguo Sun, Lin Cao, and Qianxiang Wang. Swe-exp: Experience-driven software issue resolution, 2025a.
URL htttt:::///tttitt
wttpr///bbb///7... 23361
Zhaoling Chen, Robert Tang, Gangda Deng, Fang Wu, Jialong Wu, Zhiwei Jiang, Viktor Prasanna, Arman Cohan, and Xingyao Wang. LocAgent: Graph-guided LLM agents for code localization. In Wanxiang Che, Joyce Nabende, Ekaterina Shutova, and Mohammad Taher Pilehvar (eds.), Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 8697-8727, Vienna, Austria, July 2025b. Association for Computational Linguistics. ISBN 979-8-89176-251-44 doi: 1/2186655///22222.acllloooo
URL https
4267
Cognition.
Introducing devin.
a og/
intuciii devin 2024. Blog post.
Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R Narasimhan. SWE-bench: Can language models resolve real-world github issues? In The Twelfth International Conference on Learning Representations, 2024. URL [tRppttts////peeeeeee
htt.//oorumiidd:/ ByNQM66
Yasutaka Kamei, Emad Shihab, Bram Adams, Ahmed E Hassan, Audris Mockus, Anand Sinha, and Naoyasu Ubayashi. A large-scale empirical study of just-in-time quality assurance. IEEE Transactions Software Engineering, 39(6):757-773, 2012.
Xiaonan Li, Yeyun Gong, Yelong Shen, Xipeng Qiu, Hang Zhang, Bolun Yao, Weizhen Qi, Daxin Jiang, Weizhu Chen, and Nan Duan. CodeRetriever: A large scale contrastive pre-training method for code search. In Yoav Goldberg, Zornitsa Kozareva, and Yue Zhang (eds.), Proceedings of the 2022 Conference on Empirical Methods in Natural Language Processing, pp. 2990-, Abu Dhabi, United Arab Emirates, December 2022. Association for Computational Linguis- tics. doi:
URL htR/:ttsss//alllaaooooooo.ooo
emnlp ma in.inn.n 1877
Ming Liang, Xiaoheng Xie, Gehao Zhang, Xunjin Zheng, Peng Di, wei jiang, Hongwei Chen, Chengpeng Wang. and Gang Fan. Repofuse: Repository-Ievel code completion with fused dual context, 2024. URL /hattss///axiii wtwaaaawwww..rr///////////2/222 4323
10

---

Published as a conference paper at ICLR 2026
Xiangyan Liu, Bo Lan, Zhiyuan Hu, Yang Liu, Zhicheng Zhang, Fei Wang, Michael Qizhe Shieh, and Wenmeng Zhou. CodexGraph: Bridging large language models and code repositories via code graph databases. In Luis Chiruzzo, Alan Ritter, and Lu Wang (eds.). Proceedings of the 2025 Con- ference of the Nations of the Americas Chapter of the Association for Computtatinal Linguisties: Human Language Technologies (Volume I: Long Papers), pp. 142-160, Albuquerque, New Mexico, April 2025, Association for Computational Linguistics. ISBN 979 10----88897766188 doi: 10.186534 naacl -onngaaall--naaoaao.ae. 7/
v1/2025. naacl-long.7. URL http:e///sclaattoooogg.oorg/////
Yingwei Ma, Qingping Yang, Rongyu Cao, Binhua Li, Fei Huang, and Yongbin Li. How to understand whole software repository?, 2025. URL Tttpp::/arxxvvoorr//b///20000 01422
Shane McIntosh and Yasutaka Kamei. Are fix-inducing changes a moving target? longitudinal case study of just-in-time defect prediction. In Proceedings of the 40th international conference software engineering, pp. 560-560, 2018.
Niklas Muennighoff, Hongjin SU, Liang Wang, Nan Yang, Furu Wei, Tao Yu, Amanpreet Singh, and Douwe Kiela. Generative representational instruction tuning. In The Thirteenth International Conference on Learning Representations, 2025, URL /ttpps:://peerreieew net foormm?
CG-BC41IvfSZy
Nachiappan Nagappan and Thomas Ball. Use of relative code churn measures to predict system defect density. In Proceedings of the 27th international conference on Software engineering, pp-
284-292, 2005.
Siru Ouyang, Wenhao Yu, Kaixin Ma Zilin Xiao, Zhihan Zhang, Mengzhao Jia, Jiawei Han, Hongming Zhang, and Dong Yu. Repograph: Enhancing AI software engineering with repository- level code graph. In The Thirteenth International Conference on Learning Representations, 2025.
URL
fort//orum?" id=dw 9VUsSHRR
Chen Qian, Yufan Dang, Jiahao Li, Wei Liu, Zihao Xie, YiFei Wang, Weize Chen, Cheng Yang, Xin Cong, Xiaoyin Che, Zhiyuan Liu, and Maosong Sun. Experiential co-learning of software- developing agents. In Lun-Wei Ku, Andre Martins, and Vivek Srikumar (eds.), Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 5628 -6480, Bangkok, Thailand, August 2024. Association for Computational Linguistics. doi: 10.1 h2w.14..c.21........ 3057
URL wttps:ttpa.. aalaacclanooooooyyyo www.///00222 ac llog
Sophia Quach, Maxime Lamothe, Bram Adams, Yasutaka Kamei, and Weiyi Shang. Evaluating the impact of falsely detected performance bug-inducing changes in jit models. Empirical Software Engineering. 26(5):97, 2021.
Christopher Sciavolino, Zexuan Zhong, Jinhyuk Lee, and Danqi Chen. Simple entity ques- tions challenge dense retrievers. In MariceFrancine Moens, Xuanjing Huang, Lucia Specia, and Scott Wen-tau Yih (eds.), Proceedings of the 2021 Conference on Empirical Methods in Natural Language Processing, pp. 6138-6148, Online and Punta Cana, Dominican Republic, November 2021. Association for Computational Linguistics. doi: 10. 10.18653/v1/2221 .emelp-eeelppeee..e main.496. URL https::/aace antho ogy .ww.or/gg./o........oo.. 2021 emm 1 m- ma i n. 4967
Freda Shi, Xinyun Chen, Kanishka Misra, Nathan Scales, David Dohan, Ed H Chi, Nathanael Schärli, and Denny Zhou. Large language models can be casily distracted by irrelevant context. In International Conference on Machine Learning, pp. 31210-31227, PMLR, 2023.
Tarun Suresh, Revanth Gangi Reddy, Yifei Xu, Zach Nussbaum, Andriy Mulyar, Brandon Duderstadt, and Heng Ji. CoRNStack: High-quality contrastive data for better code retrieval and reranking. In The Thirteenth International Conference on Learning Representations, 2025. URL https //openreview.oo net/ http://ooommmmd1yooOLELLLL
Alexander Trautsch, Steffen Herbold, and Jens Grabowski. Static source code metrics and static analysis warnings for fine- -ree-gra just-in-ting defect prediction. In 2020 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 127-138. IEEE, 2020.
11

---

Published as a conference paper at ICLR 2026
Boshi Wang, Hao Fang, Jason Eisner, Benjamin Van Durme, and Yu Su. LLMs in the imagi- narium: Tool learning through simulated trial and error. In Lun-Wei Ku, Andre Martins, and Vivek Srikumar (eds.), Proceedings of the 62nd Annual Meeting of the Association for Compu- tational Linguistics ( (Volume 1: Long Papers), pp. 10583-10604, Bangkok, Thailand, August 2024. Association for Computational Linguisties. doi:
URL
wong..n....... 5707]
Xingyao Wang. Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng. Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brennan, Hao Peng, Heng Ji, and Graham Neubig. Openhands: An open platform for Al software developers as generalist agents. In The Thirteenth International Conference Learning Representations, 2025a. htthstss:: http:://///ppeeeeeeeee//mm net/ Btttt//ooounnddodaaaaaaa
Yue Wang, Hung Le, Akhilesh Gotmare, Nghi Bui, Junnan Li, and Steven Hoi. CodeT5+: Open code large language models for code understanding and generation. In Houda Bouamor, Juan Pino, and Kalika Bali (eds.). Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, pp. 1088, Singapore, December 2023, Association for Computational Linguistics. doi: 10. 18653vv (5553/v1/202/5 http://..222...mmmmaaa. 2023. www.e-nnnnlmia. main.. 68/]
URL httpp:://aat http:://acc.aanhhlooryy... org/
Zora Zhiruo Wang, Akari Asai, Xinyan Velocity Yu, Frank F, Xu, Yiqing Xie, Graham Neubig, and Daniel Fried. Co-eRAG-bench: Can retrieval augment code generation? In Luis Chiruzzo, Alan Ritter, and Lu Wang (eds.), Findings of the Association for Computational Linguistics: NAACL 2025, pp. 3 3199-3214, Albuquerque, New Mexico, April 2025b. Association for Computational Linguistics. ISBN 1111-9-88-977--95---11
doi: 10. 18633/66 1/2025. wtt.020....iinnnnnnn.. madiings-naacl.166 https: //aclantho lgg. 2025. mindinnggsnnn
1767
Zora Zhiruo Wang, Jiayuan Mao, Daniel Fried, and Graham Neubig. Agent workflow mem- ory. In Forty-second International Conference Machine Learning, 2025c. URL https 7/ //openrevies net. www.ommmiddnnn..... 2JEEE
Di Wu, Wasi Uddin Ahmad, Dejiao Zhang, Murali Krishna Ramanathan, and Xiaofei Ma. Repoformer: selective retrieval for repository-level code completion. In Proceedings of the 4 Is International Conference on Machine Learning, ICML'22. JMLR.org. 2024.
Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. Demystifying llm-based software engineering agents. Proc. ACM Softw. Eng., 2(FSE), June 2025. doi: 10.1145/3715754, URL
John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik R Narasimhan, and Ofir Press. SWE-agent: Agent-computer interfaces enable automated software engineering In The Tiihty-eighth Annual Conference on Neural Information Processing Systems, 2024. URL
https::/cpeenreiiie net/ forum? iimmmiiddiin id=mXpg6ut883
Xinli Yang, David Lo. Xin Xia, Yun Zhang, and Jianling Sun. Deep learning for just-in-time defect prediction. In 2015 IEEE International conference on software quality, reliability and security, pp. 17-26. IEEE, 2015.
Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models. In International Conference Learning Representations (ICLR), 2023.
Zhongming Yu, Hejia Zhang, Yujie Zhao, Hanxian Huang, Matrix Yao, Ke Ding, and Jishen Zhao. Orealoca: An LLM agent framework for software issue localization. In Forty-second International Conference on Machine Learning, 2025. URL LyOÊPOvM6I
www. /tt/forunnnntoeeee ?id=
Dejiao Zhang, Wasi Uddin Ahmad, Ming Tan, Hantian Ding, Ramesh Nallapati, Dan Roth, Xiaofei Ma, and Bing Xiang. CODE REPRESENTATION LEARNING AT SCALE. In The Twelfth International Conference on Learning Representations, 2024a. htRpstps::/ /tttpss:/openreviees
jumpx
12

---

Published as a conference paper at ICLR 2026
Fengji Zhang, Bei Chen, Yue Zhang, Jacky Keung, Jin Liu, Daoguang Zan, Yi Mao, Jian- HunnGuang Lou, and Weizhu Chen. RepoCoder: Repository-level code completion through iterative retrieval and generation. In Houda Bouamor, Juan Pino, and Kalika Bali (eds.), Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, pp. 2471 2471-2484, Singapore, December 2023. Association for Computational Linguistics. doi: 10. htt5/////223.mmllppppp 151. URL htttp:://aclantholoogy 220.//333...//22333..3 emnlp main. 151/
Linghao Zhang, Shilin He, Chaoyun Zhang, Yu Kang, Bowen Li, Chengxing Xie, Junhao Wang, Maoquan Wang, Yufan Huang, Shengyu Fu, Elsie Nallipogu, Qingwei Lin, Yingnong Dang, Saravan Rajmohan, and Dongmei Zhang. Swe-bench goes live!, 2025. URL hwt.:httpp://attt
bxg/aba/2505.233 23419
Yuntong Zhang. Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. Autocoderover. Autonomous program improvement. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2024, pp. 1592-1604, New York, NY, USA, 2024b.
doi: 1011145/6500212.3680344 URL htt.tttpss//oo..og///0.1.1111111 11tp:////...1113333333 3680333322.68888
Association for Computing Machinery, ISBN 97984000761277
Yunhua Zhao, Kostadin Damevski, and Hui Chen. A systematic survey of just-in-time software defect prediction, ACM Computing Surveys, 55(10): 2023.
Boyuan Zheng, Michael Y. Fatemi, Xiaolong Jin, Zora Zhiruo Wang, Apurva Gandhi, Yueqi Song, Yu Gu, Jayanth Srinivasa, Gaowen Liu, Graham Neubig, and Yu Su. Skillweaver: Web agents can self-improve by discovering and honing skills, 2025. URL http:t::///axxiioo///////.
1504.07077
Albert Örwall. Moatless tools. httpps://gttabb..cm//ao//////// GitHub repository. MIT License.
2024.
13

---

Published as a conference paper at ICLR 2026
A
MEMORY CONSTRUCTION AND OPERATIONAL COSTS
A.1 FURTIER DETAILS
To construct the semantic memory, for each of the most frequently edited files, we employ the LocAgent framework tasked with summarizing the file's functionality, where the model could actively explore dependencies across different files whenever it determines that local context is insufficient. This helps make the generated summaries context-aware and accurate. average, each file costs $0.23 (calculated via GPT-4o input/output pricing).
Our episodic memory construction currently relies on explicit links between commits and issues (e.g., commit messages containing "Fixes #123") to retrieve the full context of past solutions. We acknowledge that such explicit links can be noisy or missing, a limitation well-documented existing literature (Bachmann et al. 2010). The absence of these links potentially lowers the recall of our memory retrieval. Future work could explore mitigating this limitation by adopting more robust linking strategies used in JiT-SDP research (McIntosh & Kamei 2018 Trautsch et al. 2020 Quach et al. 2021 Zhao et al. 2023)
A.2 OVERHEAD
Offline Construction. We measured the wall-clock time SymPy, the repository with the largest history in SWE-bench- Verified (containing over 60k historical commits). The complete memory construction took approximately 45 minutes: roughly 37 minutes for data crawling (commits, issues, etc.) and 8 minutes for parallelized preprocessing and semantic memory generation. Importantly, this one-time setup cost per repository.
Online Latency. To assess the runtime impact during agent execution, we analyzed random 50-example subset of -WFF-bench-Verified.. The average total runtime per instance was 28.6 seconds. Crucially, the overhead introduced by our memory search tools is negligible, averaging only 0.22 seconds per instance (relatedly, the standard LocAgent tools cost 0.37 seconds). The vast majority of the runtime is dominated by LLM inference, confirming that incorporating repository memory adds minimal latency to the agentic loop. We also collect the average response length (in tokens) for memory tools compared to standard LocAgent tools across SWE-bench- Verified instances. The memory tools are generally at similar levels of token lengths compared with LocAgent tools:
LocAgent Tools: RetrieveEntity (7.10K), TraverseGraph (2.98K), SearchEntity (1.66K).
Memory Tools: ScarchCommit (2.11K), ExamineCommit (1.8IK), ViewSummary (1.67K),
SearchSummary (6.18
B ADDITIONAL RESULTS
B.1 SENSITIVITY TO K IN SEMANTIC MEMORY CONSTRUCTION
We investigate the impact of the hyperparameter K (the number of top active files included in Semantic Memory) on the localization effectiveness. The experiments done the Django repository, which is our primary repository for preliminary analysis and prototyping.
Coverage. While serving mostly as a proxy, we analyzed the coverage of target (buggy) files within the top-K frequently edited files. As shown in Table active files demonstrate high overall coverage of target files.
Table 5: Coverage of target (buggy) files within the top- frequently edited files in the Django repository.
K (Top Active Files)
50
100
200
300
400
Coverage (%)
39.4
62.3
83.1
87.4
90.9
14

---

Published as a conference paper at ICLR 2026
Performance Sensitivity. We evaluated the localization performance (Acc@5) across different values of K. As presented Table performance improves monotonically with K, but exhibits diminishing returns K increases.
Table 6: Impact of K on localization performance (Acc @55) the Django repository.
K (Top Active Files)
50
100
200
300
400
Acc@5 (%)
74.4
76.2
79.7
80.5
81.0
Based on these results, we selected K = 200 as the optimal setting to balance retrieval performance and computational cost. We maintain this value across all repositories for simplicity, though K could also be treated as repo-specific hyperparameter tuned to the size or activity level of each repository.
B.2
IMPACT ON ISSUR RESOLUTION RATE
To assess the downstream impact of our localization improvements, we conducted an end-to-end evaluation SWE-bench-verifiee. We utilized the patch generation pipeline from Agentless (Xia et al. 2025) under standard settings with GPT-4o as the backbone. Specifically, the pipeline employs LLMs generate 10 candidate patches per issue based on localization results, re-ranks them using regression and reproduction tests, and selects the top patch for evaluation.
As shown in Table 7 improved localization accuracy translates directly higher resolution rates, with RepoMem (Full) outperforming baseline methods. This also confirms that localization performance strongly correlates with the final resolve rate, a trend consistent with prior findings (Xia al. 2025
Chen et al. 2025b)
Table 7: Localization accuracy and issue resolution rate on SWE-bench-verified.
Method
Loc Acc@5
Resolve Rate
EobeRankEmbed (Suresh et al. 2025)
54.3
26.8
Agentless (Xia et al. 2025)
71.4
36.2
LocAgent (Chen et al. 2025b)
71.6
37.0
RepoMem (Episodic-only)
74.3
38.8
RepoMem (Semantic-only)
72.8
37.6
RepoMem (Full)
76.5
40.4
B.3 RETRIEVAL ABLATION
Here, include the full comparison between the LLM-bbsed tokenizer and the standard BM25 tokenizer utilized in the memory retrieval interfaces across different repositories. The results (Table confirm that the LLM-based tokenizer consistently outperforms the standard tokenizer across the majority of repositories.
Table 8: Localization performance (Acc@5) under Standard BM25 and LLM-based tokenizer in memory retrieval.
Method
Matplotlib
Sympy
Astropy
Django
Sklearn
Sphinx
Pytest
Others
BM25 (Standard)
69.9
81.8
77.9
90.6
72.2
BM25 (asMd
82.4
72.6
86.4
79.7
96.9
59.1
77.8
54.3
C DOCUMENTATION AND EXAMPLE RESPONSES OF MEMORY ToOLS
Figure show the documentation and example responses of the memory tools.
15

---

Published as a conference paper at ICLR 2026
SearchCommit
Doc:
This tool searches the repository's commit history to find commits similar given typically hypothetical commit message.
input against historical messages, surfacing relewant past changes. Ussing this tool carly in the investigation is recommended, as it can help identify related issues changes from the past. codebase
ranking algorithm
allowing you quickly locate potential
Parameters:
'type': 'object,
'properties:: {
(
"type': 'array..
items': ('type:: "string").
description::
"A list of queries. Each query can be a hypothetical commit message, which would be matched with the history commit
messages retrieve similar commits."
top_ K
"type:: 'integer'.
description':
"top_k commits be retured,"
'defeult:: 20
}
'rquiired:; ['querylist).
Example API call: SearchConmii(queryyFFF Cannot drop unique_together constraint on single field with its own unique= True constraint" top k=20)
##Searching for query "Fix Cannot drop unique together constraint on single field with its own unique= True constraint"...
### Search Result:
SHA: 73a6ab638 Commit mestage: Fixed #25551 - Fixed migration operations ordering when adding fields and a
unique together constraint. Edited fites: (Ganpodtimirrattonsuuuddttttoot
mriuu__tgeether constraint SHA: (Sa324391 Commit message: Fixed #33125 Avoided redundant constraint when converting non-unique field to primary key on MySQL and PostgreSQL.. Edited files: ["ffanggdttshcccceeedddbssssssse
533620877| on the same fields. Edited files: (iaamp@tbbcceendsbbeeeceeee.
message: #29224 removing toteetet
"ajapoldtladeenddaeeeeeeeeee
ExamineCommit
Doc:
This tool examines the details of commit based the short (9-digit) commit sha, includlin the commit patch and optionally the description.
Note that the line numbers displayed the patch are from those history commits, not the current repo you are working on.
Parameters:
'type': 'object',
Figure 5: Documentation and example outputs from the memory tools.
16

---

Published as a conference paper at ICLR 2026
properties':
'sha.list::
'type': 'arrayy.
'items: I'type: sstringg),
"description:
"A short 9-digit commit sha that you wish to examinee"
display.issue''
"type': 'boolean',
'description::
"Set to True you wish to include the issue description in the output."
'defautt:: False
'required:: list].
Example API call: EanniieCoommiiihhh///551l1l///// display.issue= True)
Observation:
DdCommil '50931dfa5"..
issue summary Allow management commands to check database migrations are applied
issue description: When creating project, you sometimes forget 'manage.py migrate' before creating the initial superuser (especially you don't execute 'runserver' before, display warning about migrations applied). resulting error make sense, it can't access to auth_uses since does not exist yet:
$ django-admin, py startproject sample
$ sample! && python manage.py createsuperuser
but with üttte trylexcept. it could be nicer and give more meaningful information:
$ python manage.py createsuperuser
CommandError:
'manage-py migrate'
creating super
}
have patch ready (as said, trylexcept, attachment) but. accepted, would need unit tests
be complete.
Edited file: wwt.gnggwwbbsbaenennnnemmmmooooo
Patch:
@@ 12,7 +12,7 @@
class Command(Baeeonnnand)
help "Change user's password daango.ontrib.auth!
saquires.migrations -oshactsonsscccckks--s checks True
requires_system_chhee Fatse
def get passiself, prompt- 'Password: "]:
Edited file: sineecamssaaaaaeeeeettmmaaesssss
Patch:
@ 23,6 +23,7 @@ class NaautuuuiiinngTTTTessssssosssst
class Command(@aseCommand)
Figure 6: Documentation and example outputs from the memory tools.
17

---

Published as a conference paper at ICLR 2026
help Ussed to create superuser."
eequures_migraaioon_eeee True
innit_(sett "args. "kwargs):
super/Command, self). init init___"arrgsss **kwargs]
ViewSSmmary
This tool views summary of python files in the repo. You can imput list of file namres you wish to exammine.
Parameters:
type': 'object'.
properties:: {
file_list:: [
"type': 'array.
"ites': l'type:: 'string'),
(deccriptio': filenames that you summaries."
}.
"required': ('iil listt),
Example API call:
Observation:
##Summary for file dijnggtthmigaraiin/errriiirrrrr
The serializerpy' module Django's migration provides various serializer classes Python objocts into serialized form suitable for migration files. The module includes base class 'BaseSeriatizer and multiple subclasses, each handling specific types of objects such as lists, dictionaries, datetime objects, models, and custom functions. Each serializer implements 'serialize() method 'Serializer' class maintains registry of type-to-serializer mappings, allowing easy registration and usage serializers through the 'serializer factory' function. This ensures objects properly serialized when creating applying migrations in Django.
string representation object and necessary import statements.
SearchSummary
This tool searches the repositary's cached file summaries to find files similar to given query typically message describing some functionalities keywords. match input query against summaries top-k ones.
Parameters:
'type: 'object',
"properties: [
query':
"type': 'string'.
description':
query, message describing some functionalities keywords,
summaries to retrieve similar ones."
top_kh
Figure 7: Documentation and example outputs from the memory tools.
18

---

Published as a conference paper at ICLR 2026
"type:: 'integer.
"description:
"the top files to return."
deffautt::5
}
1.
'required': ['query].
Example API call: SearchSumnnaryyguurr-- generates migration file that missing an import statement; top_k=4):
Observation:
Searching for query 'generates a migration file that is missing an import statementt.
## Search Result:
summary: 'special.py diongsttmmignaalosspprraiiosssss defines
classes for managing database migrations in Djangolnin1. ""SaparaeeDatbaaseennSSeee
This class separates migration
operations into those affecting database and those affecting the state. allows for operations that do not support state change to still apply the changes or vice versa. includes methods to deconstruct operations, forward and backward migrations
specifically for state and databuse, and description of the combined statekdatabase chamge./rin2. "RunSQL" ***; This class SQL statements during migrations. supports providing can handle state changes represented by state operations. includes methods for deconstructing the operations, performing forward and backward migrations with SQL, and a description of the raw SQL operation.vrins ** ""uunPython" **; This class facilitaees running
used
SQL statement for reversible migrations and
Pythan during migrations, suitable migrations and an optional callable for reverse migrations. It includes methods to deconstruct the operation, perform forward and backward database migrations, description of Python operation. also ensures models reloaded accormoddate possible delays/ninEach class inherits from 'Operation', ensuring compatibility with Django's migration framework and providing essential interfaces for migration processes.
operations. accepts callable forward
summary: The 'serializer.py' module in Django's migration system provides various serializer classes to convert Python objects into serialized form suitable for migration files. The module includes base class "BaseSerializer' multiple subclasses, handling specific types objects such as lists, dictionaries, datetime objects. models, and custom functions. Each seriatizer implements 'serialize])" method that returns string representation of the object and necessary import statements. The 'Serializer' class maintains registry type-tye-ttt -eseitiiee mappings. allowing easy registration and usage of serializers through the 'serializer fectory' function. This ensures objects are properly serialized when creating applying migrations Django.
file: djingg/ttsmigretiinsseiiiiaale
file: httpr///wnnngneeemmmmmmnmnnnenne
summany: This Django management command.
"makemigrations.py py", used create database migration files for specified offers various options such performing dry run, merging migration across databases, checks for migration confticts, and handles user prompts interactively or non-interactively. The script generates migration files based detected model changes, writes them disk, and display the details review. also includes functionality for merging conflicting migrations interactively, ensuring consistency and resolving dependencies.
creating empty migrations, controlling verbosity. ensures consistent migration history
file: djangskoredmangggeenddddt.yyy summary:...
Figure 8: Documentation and example outputs from the memory tools.
19

---

Published as a conference paper at ICLR 2026
D AGENT PROMPT
We use the same task instruction prompt from the original LocAgent framework to guide the agent, which is displayed in Figure 9 for completeness.
Proupt
Given the folloxing GiUHib probles description, your objective is to localize the specific files, classes functions, and Lires of code Uhat need rodi rodifica Lication contain key informttin to resolve the issue.
these steps to localize the issue:
Step Categorize Extract Key Information
probles statement
following categortes:
bug, additionat context. Probler description, "Hoockape_rate]? package rentioned calegory. references additional
keywords
** Step 2: Locate Referenced Modules
Accurately ly deternine specific rodules
Expl the repe to faniii yourself with its structure,
Ana Analyze the deseribed excnution flow to identsfy spocific modutes or componnnts being referenced.
Pay artertion disttiggt between modules
nanes using described exocution
Fornat collected relevent rodules:
fomat: "file path:tuullltiiieeiiee function "aaluulate,
"Hathutils" class located "sre/helpers//attheeeerrrrr represent it
"src/helpers/mthh htwppeeeeeeess.tttrteeeeee wtw.liss.cccclltesmr....
se Step 3: Ana lyze and Reproducing the Problen
Clarify the Purpose of the Issue
If expanding cepabiliiies: Identify where and how to incorporate new behavior, fields, or modules.
addressing unexeected behavior: Focus on localicing sodules containing potential bugs.
Recons truct execut
Identify rain entry points triggering
sequences
Identify potential broakpinnt
Important: Keep reconstructed
problen, avoiding
details.
Step Locale Areas for Modification
Locate specific tiles, functions, or Lines of code requiring changes or containing critical infomotion for resolving the issuc. Consider upstrean and downstreas dependencies that may affect or be affected by the issue.
If appliaale,,, ideatify wbere to intradure new fields, funct ions, or variables.
nuttiple potential. solutions and consider edge cases
impact resolution.
Forrat
tinal should the locations requiring modification, urapped (if applicaalle le), function Line ordered isportance.
backticks
location should include the would better incluse about files.
see Exaeples:
folLeetht/Fitel.oy
Line:
class: MyClass1 my__ functionn
Line:
function: fycncin2.n.funnction2
foll_otthS//ite...g
Line: 24
function: fy_functionn
location(s)
Note: thinking should tharough it's very Long-
Figure 9: The task instruction prompt used to guide the agent's reasoning process.
E USE OF LARGE LANGUAGE MODELS
Large Language Models (LLMs) were used solely as a general-purpose writing aid in the preparation of this paper. Specifically, they were used to help polish grammar and improve the clarity of certain sentences. No LLMs were used for research ideation, experimental design, data analysis, or drawing conclusions. All substantive contributions to the research and writing were made by the authors.
20


Reviews:
[{"review_id": "VhiZ8Q6dEv", "reviewer": "Reviewer_F6Cy", "summary": "The authors propose integrating commit history and recent activity via a \"memory\" interface as context for LLM agents when tackling fault localisation. To demonstrate the value of their approach, they integrate with LocAgent and expose the memory through tools/API calls. They evaluate on SWE-bench-verified and SWE-bench-live, showing consistent improvement in performance over the vanilla LocAgent. The authors also analyse the tools employed by the agent during localisation and the cost trade-off depending on success (either of the memory-based tool or the vanilla tool), demonstrating that the cost landscape is non-trivial. This work serves as a first step in considering external project information sources that can serve as project/institutional memory (commit history, issue trackers, code reviews, etc.).", "questions": "- Comment1: While not directly related, a \"sister\" area of research is just-in-time defect prediction, and the literature reference for this is missing. Consider this survey as a starting point: Yunhua Zhao, Kostadin Damevski, and Hui Chen. 2023. A Systematic Survey of Just-in-Time Software Defect Prediction. ACM Comput. Surv. 55, 10, Article 201 (October 2023), 35 pages. https://doi.org/10.1145/3567550. The core of the comment is that, by the nature of the just-in-time version of the fault localisation problem, the data that is to be used is the commit history. Still, to my knowledge, this work is the first to consider this source of information in an agentic framework, enabling access through tools.\n\n- Q1: In JIT defect prediction, features such as recent commits, recent commits by the same author, historically co-chaged files, etc., are used as manually created features. In this work, such metadata enrichment is not considered. Was such, or different, preprocessing considered beyond the scope of the work? For example, I would expect even a time-stamp filter to aid when retrieving development history for an agent to use; 7000 commits before the current base commit is considerably more than what is standard in SE work.", "limitations": "", "rating": 8, "confidence": 5, "soundness": 3, "presentation": 4, "contribution": 3, "strengths": "- combining project history (commit history) with repository structure for better localisation in the context of LLMs.\n- demonstrated consistent improvement in performance over the extended baseline/SOTA\n- analysis of the cost trade-off between using/not using memory tools\n- careful removal of information that can cause data leakage (through issues/transitive relationships)", "weaknesses": "- The cost overhead is significantly higher, specifically for cases where vanilla LocAgent fails. (I am not convinced about tool allocation, especially since hotspots and recent development can be a very strong signal, at least in just-in-time defect prediction)\n- The memory construction hyperparameters seem odd (I expected runtime compression + last 14 days of commits or similar thresholds from SE, not 7000 commits as pre-processing)\n- Some of the metadata exposed/used by the proposed approach depends on links that are known to be noisy (Issue-Commit links are known to be missing: seminal paper for the problem definition -- Bachmann, Adrian, et al. \"The missing links: bugs and bug-fix commits.\" Proceedings of the eighteenth ACM SIGSOFT international symposium on Foundations of software engineering. 2010. But research has progressed since)\n- Memory construction may be inefficient, but the efficiency of memory construction may be out of scope. (reference paper -- S. Kim, T. Zimmermann, K. Pan and E. J. Jr. Whitehead, \"Automatic Identification of Bug-Introducing Changes,\" 21st IEEE/ACM International Conference on Automated Software Engineering (ASE'06), Tokyo, Japan, 2006, pp. 81-90, doi: 10.1109/ASE.2006.23. And the area of just-in-time defect prediction). Specifically, borrowing ideas of how to narrow which commits to summarise/choose.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "4OINXaoa2J", "reviewer": "Reviewer_Fbe2", "summary": "The paper augments repository-level localization agents with repository memory built from pre-issue commit histories—an episodic memory of past commits/issues and a semantic memory of summaries for frequently edited files—yielding consistent gains over LocAgent on SWE-bench-Verified.", "questions": "Retrieval extensions: given BM25’s strong showing on Django, report whether the LLM-aware tokenizer generalizes across repos and whether hybrid sparse+dense retrieval helps when commit phrasing diverges from issue wording", "limitations": "", "rating": 6, "confidence": 4, "soundness": 3, "presentation": 2, "contribution": 3, "strengths": "- The framing—that human-like “long-term repository memory” is missing in current agents—is clear and well motivated, and the two concrete tools are simple yet effective: SearchCommit / ExamineCommit (BM25 over commit messages + diffs) and SearchSummary / ViewSummary (LLM summaries of “hot” files). Integration into LocAgent’s ReAct loop is clean and modular, with sensible leakage controls (time-slicing to pre-issue commits and filtering text overlaps). \n\n- On SWE-bench-Verified, RepoMem improves Acc@5 from 71.6 → 76.5 (+4.9 abs) over LocAgent; on SWE-bench-Live, 63.1 → 66.2. The setup details (GPT-4o, 7k prior commits, top-200 files for summaries) are reported, and both episodic- and semantic-only ablations are positive, suggesting complementary value. \n\n- Insightful analyses. (i) Per-repo analysis shows larger gains where commit histories are rich; (ii) cost analysis reveals instance-level heterogeneity—memory sometimes reduces cost dramatically but can add overhead on hard cases; (iii) retrieval study finds BM25 (with an LLM-aware tokenizer) outperforms a strong dense retriever (GritLM-7B) on Django. These help practitioners reason about when/why the method helps.", "weaknesses": "- Sensitivity to history density. Benefits correlate with repository commit volume; performance degrades on the “others” bucket with sparse histories (−13.1 Acc@5 vs. LocAgent), underscoring brittleness when history is limited or off-target. Some mitigation is discussed qualitatively but not implemented. \n\n\n- Dataset selection and external validity. For SWE-bench-Live, the paper evaluates an intersectioned subset (Lite and Verified) and filters to ≤5 modified files (130 examples/62 repos). This practical choice is understandable but may bias toward easier issues; a sensitivity analysis to the filter would strengthen claims. \n\n\n- Reporting gaps on efficiency & scalability. While costs are compared, the paper lacks index/build-time, memory footprint, and latency for constructing/searching the 7k-commit memory and top-200 summaries—numbers crucial for monorepos and CI integration.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "rlCTljPnX8", "reviewer": "Reviewer_tvHt", "summary": "The paper aims to enhance the fault localization agent with two types of memory designs.\n\nThe intuition is clear and well justified: A human developer would not consider a code repo as a fresh problem instance. Instead, she will consider the commit histories and other background knowledge about the code repo.\n\nSpecificially, this work introduces two types of memories:\n1. A memory that summarizes key information in commit histories\n2. A memory that summarizes the code semantics of some key files.\n\nTo identify the key files, the proposed system identifies the files that are most frequently modified in previous commits.\nthen they use LLM to generate summaries for those key files.\n\nTo enhance the localization agent system, the proposed memories are provided as tools to the agent.\n\nThe paper evaluates the localization agent on two issue fixing benchmarks: swe-bench and swe-bench-live. With the augmented tools, the agent demonstrates better performance in fault localization on those two benchmarks.", "questions": "Please see above.", "limitations": "", "rating": 4, "confidence": 3, "soundness": 2, "presentation": 3, "contribution": 2, "strengths": "The paper targets an important problem and proposes a neat and intuitive solution.", "weaknesses": "Q1: Justify the active code identification. The proposed approach identifies frequently modified code files and only summarizes the semantics of those files. I think it is a strong prior to assume most issues only happens in those files. Are there any statistical support for this observation/heuristics? Are they specific to those two benchmarks?\n\nQ2: Clarify the details about code summary generation. How the code summaries are generated? Many code snippets/functions have complex dependences across files. Do the generated summary consider the contexts across different files?\n\nQ3: The proposed technique summarizes the top_k active edited file. Is the system performance sensitive to the selection of k?\n\nQ4: Adaptation to newer commits. When the code repo receives new commits, how the pre-generated memories would be updated? For example, some of the code summaries may be out-dated.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "vt6Y1762J7", "reviewer": "Reviewer_bN9m", "summary": "The paper proposes RepoMem, a lightweight repository memory for code localization agents, built from each repo’s commit history. It instantiates two complementary, non-parametric memories: (1) Episodic—a searchable store of prior commits and linked issues, queried via SearchCommit / inspected via ExamineCommit; and (2) Semantic—LLM-generated functionality summaries for frequently edited (“hotspot”) files, accessed via ViewSummary / SearchSummary. Integrated into LocAgent, RepoMem improves localization on SWE-bench-verified and a filtered SWE-bench-live subset, using GPT-4o (2024-05-13) as the backbone and reporting Accuracy@k.", "questions": "1. End-to-end impact: Can you report SWE-bench end-to-end results (resolution rate, test pass) with/without RepoMem, and per-component ablations, to quantify how localization gains translate to actual fixes?\n2. Cost/latency & token accounting: What are (a) average prompt tokens per component, (b) offline token cost to build semantic memory (top-200 file summaries), and (c) online latency/$ overhead relative to LocAgent?", "limitations": "", "rating": 4, "confidence": 3, "soundness": 2, "presentation": 3, "contribution": 2, "strengths": "The paper introduces a practical repository-memory mechanism for SWE-bench localization, combining (i) an episodic store built from pre-issue commit history and linked artifacts that can be searched/inspected at inference time, and (ii) a semantic memory of LLM-generated summaries for frequently edited (“hotspot”) files; the design is simple to integrate, and aligns with how human developers leverage history to narrow the search scope. In extensive evaluations, the memory delivers consistent performance gains over a strong LocAgent baseline, improving Accuracy@k on SWE-bench-verified and a live subset, with ablations indicating complementary benefits of episodic + semantic memories.", "weaknesses": "1. Limited Novelty in Core Mechanism: The agent's memory system, while presented as a compositional structure, relies heavily on established prompting techniques and existing memory concepts rather than introducing fundamentally new mechanisms for agent memory or reasoning. The contribution seems more focused on engineering specific prompts for memory management than on novel agent capabilities.\n2. Ablation gaps (end-to-end impact). Empirics focus on localization Acc@k, but the paper does not quantify downstream SWE-bench end-to-end effects (e.g., Resolved@1, test pass rate, patch compile/apply rate, tool-call path length, wall-clock). Without E2E deltas versus a strong baseline (and versus LocAgent without memory), it is hard to assess whether memory truly improves fix outcomes.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)