ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations ZHISHUO YANG, State Key Laboratory of Complex & Critical Software Environment, School of Computer Science and Engineering, Beihang University, China

LI ZHANG, State Key Laboratory of Complex & Critical Software Environment, School of Computer Science and Engineering, Beihang University, China

YANG LIU, State Key Laboratory of Complex & Critical Software Environment, School of Computer Science and

arXiv:2611.07759v1 [cs.SE] 5 Nov 2026

Engineering, Beihang University, China

DONGHAO YANG, State Key Laboratory of Complex & Critical Software Environment, School of Computer Science and Engineering, Beihang University, China

FANG LIU✉ , State Key Laboratory of Complex & Critical Software Environment, School of Computer Science and Engineering, Beihang University, China Large language model (LLM)-based code assistants are increasingly used in iterative repository-level development, where effective assistance requires jointly leveraging evolving conversational history and repository context. Existing memory systems, however, are primarily designed for general-purpose conversations and do not sufficiently coordinate conversational information with the structured code entities to which it refers. We propose ReConMem, a graph-based dual memory system for repository-oriented conversations. ReConMem organizes distilled conversational memories and conversation-relevant code entities into interconnected semantic and structural memory graphs, while maintaining their cross-graph associations as interactions evolve. For memory recall, ReConMem combines natural-language and code-aligned retrieval through code-draft-based query grounding, expands retrieved information over intra- and inter-graph relations, and compresses retrieved code according to its structural granularity. We evaluate ReConMem on two repository-oriented conversational benchmarks covering controlled long-horizon context management and realistic project-grounded multi-turn assistance. On LoCoEval, ReConMem improves overall Pass@1 score over the strongest baseline by 7.917 and 7.292 percentage points on the single-hop and multi-hop subsets, respectively, while maintaining comparable context compression. On CodeAssistBench, it achieves 27.61% Correct and 44.03% Partially Correct, outperforming Full History by 4.10 and 7.09 percentage points, respectively, while also improving interaction quality. Further analyses demonstrate the complementary contributions of the two retrieval routes and the effectiveness of ReConMem across different conversation characteristics. These results show that explicitly coordinating conversational history with repository structure enables more effective context management for repository-oriented multi-turn interactions. We provide the replication package at https://github.com/CoconutTreeee/ReConMem. Authors’ Contact Information: Zhishuo Yang, yangzhishuo@buaa.edu.cn, State Key Laboratory of Complex & Critical Software Environment, School of Computer Science and Engineering, Beihang University, Beijing, China; Li Zhang, lily@buaa.edu.cn, State Key Laboratory of Complex & Critical Software Environment, School of Computer Science and Engineering, Beihang University, Beijing, China; Yang Liu, liuyang26@buaa.edu.cn, State Key Laboratory of Complex & Critical Software Environment, School of Computer Science and Engineering, Beihang University, Beijing, China; Donghao Yang, yangdonghao@buaa.edu.cn, State Key Laboratory of Complex & Critical Software Environment, School of Computer Science and Engineering, Beihang University, Beijing, China; Fang Liu, fangliu@buaa.edu.cn, State Key Laboratory of Complex & Critical Software Environment, School of Computer Science and Engineering, Beihang University, Beijing, China. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. Manuscript submitted to ACM Manuscript submitted to ACM

1

2

Yang et al.

CCS Concepts: • Software and its engineering → Software development techniques; • Computing methodologies → Knowledge representation and reasoning. Additional Key Words and Phrases: Context Management, Repository Development, Dual Memory System, Memory Graph, Large Language Models ACM Reference Format: Zhishuo Yang, Li Zhang, Yang Liu, Donghao Yang, and Fang Liu. 2026. ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations. 1, 1 (November 2026), 26 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn

1

Introduction

Modern software development increasingly involves interactive collaboration with AI code assistants [1, 2, 7, 9, 26] driven by large language models (LLMs). Beyond single-turn code tasks, developers now engage in iterative interactions with these assistants in repository-level development, such as code understanding, feature implementation, and refactoring, resulting in overwhelming context that exceeds the LLM’s capacity. This raises a central challenge: how to effectively maintain, associate, and utilize context. Recent advances in memory systems have been extensively explored to manage conversational context and maintain stable interactions across turns [6, 21, 24, 36]. Rather than loading the entire context into the LLM prompt, these systems maintain external storage and retrieve only task-relevant information on demand. For example, Mem0 dynamically extracts salient information from conversations and employs graph-based memory representations to capture complex relational structures, thereby improving retrieval. However, these methods are designed for general scenarios and fail to fully exploit the characteristics of repositorylevel development. Conversation and repository are inherently interdependent here: requirements, decisions, and clarifications discussed across turns are often tied to specific repository entities, while the repository context relevant to a new request may in turn depend on the preceding interaction history. As illustrated in Figure 1, the developer begins with a question about ftfy versus manual encode/decode, proposes a detection function based on is_bad in badness.py, and then revises the plan toward different fix strategies after the assistant identifies missing cases. The later request builds on both the earlier discussion and the shared repository entity is_bad in badness.py, showing how conversational history and repository context are intertwined. Since existing methods fail to sufficiently coordinate these two types of context when organizing, retrieving, and utilizing context, their performance remains unsatisfactory. Effectively handling such intertwined context introduces several concrete challenges. Conversational memories and repository entities need to be associated rather than maintained as isolated context; retrieval needs to jointly leverage conversational semantics and information encoded in repository code, despite their heterogeneous representations; and retrieved code needs to retain sufficient task-relevant information without introducing excessive irrelevant details, even when relevant code entities vary substantially in granularity. To address these challenges, we propose ReConMem, a graph-based dual memory system that represents and utilizes two sources of context through two aligned yet distinct memory spaces. Specifically, ReConMem maintains a Semantic Memory Graph that captures distilled natural language memories and their relations from conversations, and a Structural Memory Graph that maintains conversation-relevant code entities and organizes them according to the repository structure. These two memory spaces are explicitly linked through dual relations and kept consistent by a dual synchronization protocol. Together, they form a unified yet dual-view representation, which we refer to as the dual memory graph. Building on this representation, we introduce a joint memory recall mechanism. Considering Manuscript submitted to ACM

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations repository

3

I'm working on the `ftfy` repository ..., and I'm curious about its main advantages over manually using `encode`/`decode` in Python. The big difference is that `ftfy` doesn't just convert bytes to text - it intelligently detects and fixes common encoding problems ...

...

I'm planning to add a function that detects if a string contains what looks like UTF-8 ..., I see a helper `is_bad` function in `badness.py`... You're on the right track thinking about pattern detection, but you'd also need to consider cases ... Hmm, maybe my plan is too narrow. Instead of just detecting, I should... tries different fix strategies ...

...

Fig. 1. A typical interaction between a user and a code assistant, involving cross-file reasoning, iterative requirements, and long conversational history.

the heterogeneity of the two graphs, ReConMem employs a code-draft-based query grounding strategy to derive a code-aligned representation of the original query. The original natural-language query and the resulting dual query are then used to retrieve from the semantic and structural memory graphs, respectively. We further apply graph-adjacency expansion over intra- and inter-graph relations to retrieve additional relevant context. For the retrieved code, we propose a hierarchical code context compression method that applies granularity-specific compression strategies to reduce task-irrelevant information while preserving task-relevant content. We evaluate ReConMem on two repository-oriented conversational benchmarks, LoCoEval [17] and CodeAssistBench (CAB) [12], covering both controlled long-horizon context management and realistic project-grounded multi-turn assistance. On LoCoEval, ReConMem improves the overall Pass@1 over the strongest baseline by 7.917 and 7.292 percentage points on the single-hop and multi-hop subsets, respectively, while maintaining a comparable context compression ratio. On CAB, ReConMem achieves 27.61% Correct and 44.03% Partially Correct, outperforming Full History by 4.10 and 7.09 percentage points, respectively; it also achieves the highest Appropriate rate and the fewest average interaction turns among the compared methods. Further analyses verify the effectiveness of individual components, reveal the complementary roles of the two retrieval branches, and demonstrate the efficiency and robustness of ReConMem under different repository-oriented conversational settings. In summary, our main contributions are as follows: • We propose ReConMem, a dual-graph memory system specifically designed for repository-oriented conversations. It introduces a dual-view memory organization that jointly represents conversational history and repository code, maintaining complementary context from two perspectives. • We design a joint memory recall mechanism tailored to the heterogeneous representations of conversational and code contexts. By combining code-draft-based query grounding and graph-adjacency-expanded retrieval, ReConMem retrieves comprehensive and diverse contextual information. Manuscript submitted to ACM

4

Yang et al.

Current interaction

next query extract

texts

repository

Memory Sketching

anchors

Code Entity Localization

paths

Memorized bipartite graph

retrieve

Dual Memory Graph

LLM

texts

Code Draft Database

Code draft

... LLM

insert

Semantic Memory Graph

Structural Memory Graph

update

update

... Semantic Memory Update

Dual Synchronization Protocol

Memory Construction and Maintenance

graph- Original query adjacencyexpanded retrieval

Dual query

hierarchical code context compression

Semantic context

Structural context

Joint Memory Recall

Fig. 2. Overview of ReConMem.

• We conduct systematic evaluations of ReConMem on LoCoEval and CodeAssistBench, covering both controlled long-horizon context management and realistic project-grounded multi-turn programming assistance. The results demonstrate the effectiveness of ReConMem by achieving consistent improvements over strong baselines. 2

Methodology

As shown in Figure 2, the core memory structure of ReConMem is the Dual Memory Graph, which consists of a semantic memory graph and a structural memory graph, connected to each other through dual relations. The workflow of the entire method is centered around the life cycle of the dual memory graph: after each interaction, it enters the Memory Construction and Maintenance stage, where it identifies and structures information worth retaining from the current turn, and consolidates these interaction-level memory sketches into the persistent dual memory graph; when a new user query arrives, it enters the Joint Memory Recall stage, where it retrieves and processes complementary conversational and code context from the maintained memory structures to support response generation. 2.1

Dual Memory Graph

As shown in Figure 3, the dual memory graph organizes conversational memories and repository code entities in two distinct but interconnected memory spaces: a semantic memory graph and a structural memory graph. Formally, we define it as ∗ 𝐺 dual = (𝐺 se, 𝐺 st, 𝑅dual, 𝑅dual ),

(1)

where 𝐺 se = (𝐸 se, 𝑅se ) and 𝐺 st = (𝐸 st, 𝑅st ) denote the semantic and structural memory graphs, respectively. 𝐸 se and 𝐸 st are their entity sets, while 𝑅se and 𝑅st represent the corresponding intra-graph relations. 𝑅dual ⊆ 𝐸 se × 𝐸 st and ∗ 𝑅dual ⊆ 𝐸 st × 𝐸 se represent the inter-graph relations connecting the two memory spaces.

In the semantic memory graph, each entity 𝑒 se ∈ 𝐸 se corresponds to a textual memory extracted from preceding interactions and maintained through the construction process described in §2.2. The directed intra-graph relations 𝑅se Manuscript submitted to ACM

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations intra-graph relation

Gr ap

Se ma

...

...

nt ic

function `is_bad` in `badness.py` may be used to implement user requirements

dual

...

M em or

y

inter-graph relation

h

user is curious about the advantages of this repository

user is planning to add a function to detect and fix encoding problems

5

CharData sort_key

badness

...

is_bad

...

Gr y M em or

...

cli.py

al

badness.py

...

README.md

ct ur

table.py

ftfy

St ru

scripts

ap

h

ftfy

Fig. 3. Illustration of the dual memory graph structure.

are dynamically established during the memory updating process (§2.2.2) to capture meaningful associations between different memory entities. These relations preserve local associations among otherwise separate textual memories and provide the semantic neighborhood used in subsequent graph-based retrieval. In the structural memory graph, each entity 𝑒 st ∈ 𝐸 st corresponds to a repository code entity currently associated with at least one textual memory. The structural memory graph is constructed selectively, containing only code entities referenced by the semantic memories, including files, type declarations, functions or methods, and variables, fields, or attributes. Each structural entity retains its complete repository path, from which its structural relation can be derived. Let 𝜋 (𝑒) denote the repository path of a structural entity 𝑒. The directed structural relation set is defined as  𝑅st = (𝑒𝑖 , 𝑒 𝑗 ) ∈ 𝐸 st × 𝐸 st | parent(𝜋 (𝑒𝑖 )) = 𝜋 (𝑒 𝑗 ) .

(2)

Accordingly, 𝑅st captures direct child-to-parent containment relations only between repository entities that have both been instantiated in the structural memory graph, forming a sparse structural view of the repository conditioned on the currently maintained memories. The two memory graphs are connected through dual relations that explicitly associate textual memories with the repository entities to which they refer. For a semantic entity 𝑒 se with one or more valid code associations, 𝑅dual contains ∗ directed relations from 𝑒 se to the corresponding structural entities, while 𝑅dual maintains their reverse mappings. A

semantic entity may therefore be associated with multiple structural entities, and the same structural entity may be referenced by multiple semantic entities. Textual memories without valid code associations remain solely in the semantic memory graph. The two relation sets satisfy  ∗ 𝑅dual = (𝑒 se, 𝑒 st ) | (𝑒 st, 𝑒 se ) ∈ 𝑅dual ,

(3)

where 𝑒 se ∈ 𝐸 se and 𝑒 st ∈ 𝐸 st . This bidirectional mapping preserves the associations between conversational memories and their referenced repository entities, allowing subsequent retrieval to traverse between the semantic and structural memory spaces. Manuscript submitted to ACM

6

Yang et al.

2.2

Memory Construction and Maintenance

In this phase, we extract key information from the current turn and represent it as textual descriptions together with their associated code-entity anchors. We then perform code entity localization to resolve these anchors into exact entity paths, thereby forming a series of Memorized Bipartite Graphs. Next, to integrate these dispersed memorized bipartite graphs into a unified memory structure, namely the dual memory graph, we introduce an LLM-driven decision mechanism to perform Semantic Memory Update. Subsequently, we employ a Dual Synchronization Protocol to consistently propagate the corresponding updates to the Structural Memory Graph, thereby maintaining the bidirectional consistency of the cross-graph mappings. 2.2.1 Memorized Bipartite Graph. For each interaction turn, we use an LLM to construct a bipartite graph to organize textual memory units and their associated code entities. Formally, for each interaction turn 𝑡, we construct B𝑡 = (𝐷𝑡 , 𝑃𝑡 , 𝑅𝑡 ),

(4)

𝑀 and 𝑃 = {𝑝 } 𝑁 are two disjoint vertex sets. 𝐷 contains textual memory units extracted from the where 𝐷𝑡 = {𝑑𝑖 }𝑖=1 𝑡 𝑗 𝑗=1 𝑡

interaction, which serve as candidates for subsequent updates into the Semantic Memory Graph, while 𝑃𝑡 contains repository-grounded code entities involved in these memories, which correspond to units in the Structural Memory Graph. The directed edge set 𝑅𝑡 ⊆ 𝐷𝑡 × 𝑃𝑡 records which code entities are involved in each textual memory. In this way, the bipartite graph serves as a turn-level bridge between the current interaction and the two memory spaces, providing the basis for subsequent memory integration and cross-graph association. The construction of the bipartite graph is guided by two considerations tailored to repository-oriented development: retaining information that may remain useful in subsequent development activities, and keeping each memory unit sufficiently fine-grained for independent retrieval and update. For the textual vertex set 𝐷𝑡 , we prompt an LLM to extract development-relevant information from the current user–assistant turn. The extracted information broadly covers requirement-oriented information, such as target functionality, structural constraints, dependencies, coding conventions, and input/output expectations, as well as contextual information relevant to implementation, such as project context, design decisions, task intentions, and code-specific observations. Each textual vertex 𝑑𝑖 ∈ 𝐷𝑡 is kept atomic and concise, typically representing a single development intent, requirement, constraint, decision, or code-related observation. ˜ 𝑖 ), Along with each textual memory 𝑑𝑖 , the LLM also produces a set of candidate code-entity anchors, denoted by 𝐴(𝑑 representing repository-style references associated with that memory. Explicitly mentioned repository entities, such as files, modules, classes, and functions, are prioritized when constructing these anchors. When precise code locations are unavailable, a small number of high-confidence approximate references may also be inferred from the entity mentions and the local interaction context. Consequently, the resulting anchors may be incomplete or approximate hierarchical references, such as CharData/sort_key, rather than exact repository locations. Because these candidate anchors are derived from conversational information, they may not exactly correspond to valid entities in the actual repository structure. We therefore perform code entity localization to resolve each candidate ˜ 𝑖 ) into at most one concrete code-entity path in the repository. We denote this process by 𝐿(𝑎), ˜ where anchor 𝑎˜ ∈ 𝐴(𝑑 ˜ = ⊥ if no valid entity can be resolved. 𝐿(𝑎) Specifically, we adopt a two-stage resolution strategy. We first perform an exact lookup over the repository structure. If the anchor cannot be resolved exactly, we collect non-directory code entities whose terminal path component exactly matches that of the anchor and rank them according to their structural agreement with the anchor path. The Manuscript submitted to ACM

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations

7

ranking prioritizes candidates with longer consecutively matched trailing path components, followed by those with longer consecutively matched leading path components; the string length of the candidate path is used only as a final tie-breaker. The highest-ranked candidate is selected as the localized path, while anchors with no valid candidate remain unresolved and are discarded. For each textual memory 𝑑𝑖 , the successfully resolved entities constitute  ˜ 𝑖 ), 𝐿(𝑎) ˜ | 𝑎˜ ∈ 𝐴(𝑑 ˜ ≠⊥ . 𝐴(𝑑𝑖 ) = 𝐿(𝑎)

(5)

Accordingly, the code-entity vertex set and the cross-set edge set of the memorized bipartite graph are defined as Ø 𝑃𝑡 = 𝐴(𝑑𝑖 ), (6) 𝑑𝑖 ∈𝐷𝑡

and  𝑅𝑡 = (𝑑𝑖 , 𝑝 𝑗 ) ∈ 𝐷𝑡 × 𝑃𝑡 | 𝑝 𝑗 ∈ 𝐴(𝑑𝑖 ) .

(7)

A textual vertex is not required to be associated with a code entity, i.e., 𝐴(𝑑𝑖 ) may be empty, whereas every code-side vertex in 𝑃𝑡 is associated with at least one textual vertex. 2.2.2 Semantic Memory Update. To consolidate overlapping information and avoid redundant or fragmented memory accumulation, we employ an LLM-driven mechanism to update the semantic memory graph based on the memorized bipartite graph. Specifically, for each textual description 𝑑𝑖 in the memorized bipartite graph, we first retrieve the top-𝑘 1 most relevant textual entities from the current semantic memory graph according to embedding similarity, together with the paths of their connected code entities. These retrieved entities and code paths serve as reference context for the update decision. We then feed this context together with the memorized bipartite graph into an LLM and formulate semantic memory update as a structured decision task. The model jointly determines an appropriate update action from a predefined set {Insert, Modify, Remove} and the semantic adjacency relations associated with the update. Semantic adjacency relations are established between memories concerning different but related development entities or topics. In contrast, information concerning the same referent is consolidated through memory updates rather than represented as an adjacency relation. Based on these principles, the three update actions are defined as follows: • INSERT: If 𝑑𝑖 is semantically unrelated to existing textual memory entities or corresponds to a different referent, this action is performed, instantiating 𝑑𝑖 as a new entity in the semantic memory graph. Its textual content and code associations are initialized from the corresponding information in the memorized bipartite graph, while directed semantic adjacency relations may be established with related existing memories. • MODIFY: If 𝑑𝑖 is semantically similar to an existing textual memory entity and corresponds to the same referent, but provides supplementary or updated information, this action is applied. The textual content is consolidated with the new information, while the existing and newly introduced code associations are merged. Its semantic adjacency relations are updated accordingly. • REMOVE: If 𝑑𝑖 exhibits a clear semantic conflict with an existing textual memory entity, or if the user explicitly invalidates prior information, this action is performed to remove the corresponding entity. Through these updates, outdated information is promptly revised or removed, while related information is consolidated or connected through semantic relations, keeping the semantic memory graph non-conflicting and well organized. Manuscript submitted to ACM

8

Yang et al.

2.2.3 Dual Synchronization Protocol. Since the updates described above are directly applied only to the semantic memory graph, we introduce a dual synchronization protocol to consistently propagate these updates to the structural memory graph. Specifically, when an update introduces a new association between a semantic entity 𝑒 se and a repository code entity 𝑒 st , the corresponding structural entity is instantiated if it does not already exist, and the reciprocal crossgraph mappings are established. Conversely, when an association is removed, the corresponding mappings are removed; if a structural entity is no longer referenced by any semantic entity, it is removed from the structural memory graph. Through this process, the structural memory graph contains only repository entities referenced by the currently maintained semantic memories, while the cross-graph mappings preserve the bidirectional consistency defined in Eq. 3. This allows subsequent retrieval to traverse consistently between the semantic and structural memory spaces. 2.3

Joint Memory Recall

In this phase, for each user query, we first perform Code-Draft-Based Query Grounding to obtain a code-modality representation aligned with the structural memory graph. This representation serves as the dual query and, together with the original query, is applied to the dual memory graph for similarity-based retrieval over the structural and semantic memory graphs, respectively, yielding a set of initially retrieved entities. Based on these initial results, we adopt a Graph-Adjacency-Expanded Retrieval strategy to expand the retrieval set through intra-graph and inter-graph adjacency relations. The retrieved entities are then merged and deduplicated, after which the retrieved code entities are processed through Hierarchical Code Context Compression to streamline the retrieved context and reduce noisy information. Finally, we obtain memory texts from the textual entities and compressed code from the code entities, forming the semantic and structural contexts, respectively. Together, they provide comprehensive and accurate background information for the code assistant to generate responses to the user. 2.3.1 Code-Draft-Based Query Grounding. In iterative repository-oriented interactions, later user requests often build upon code discussed or generated in preceding turns. Consequently, the current user query may not fully express the intended development state in isolation, as part of its meaning needs to be interpreted in conjunction with the preceding interaction context. Meanwhile, code artifacts generated in preceding turns provide a concrete representation of the evolving implementation state. We therefore leverage these code artifacts to ground the current query in the development context established through preceding interactions. To support this process, we extract code blocks from the responses generated by the code assistant and incrementally store them in an auxiliary code draft database. This database accumulates intermediate code artifacts produced throughout the conversation, serving as a complementary representation of the evolving conversational context in the code modality. Given a new user query, we retrieve the most similar code snippet from the code draft database based on embedding similarity with the query. The retrieved code snippet provides a code-side representation that is relevant to the current request and grounded in the preceding interaction history. If the highest similarity exceeds a predefined threshold, the retrieved code snippet is used as the dual query for retrieval over the structural memory graph. Otherwise, we fall back to the original user query to avoid introducing an unreliable code-side representation. 2.3.2 Graph-Adjacency-Expanded Retrieval. Building on the original user query and the dual query, we first identify a set of initial entities that are directly relevant to the current request from the semantic memory space and the code space through embedding-similarity-based retrieval. However, similarity-based retrieval primarily relies on the representational similarity between the query and individual entities, and may therefore overlook contextual information Manuscript submitted to ACM

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations

9

that is explicitly related to the retrieved entities but does not exhibit sufficiently high similarity to the query itself. To further exploit the dual memory graph structure, we introduce a graph-adjacency-expanded retrieval mechanism that supplements the initial retrieval results through intra-graph and inter-graph relations. Specifically, on the semantic side, we retrieve the top-𝑘 2 most relevant textual entities from the semantic memory graph based on embedding similarity with the original query. On the code side, we divide the retrieval budget 𝑘 3 into 𝑘 31 and 𝑘 32 , i.e., 𝑘 3 = 𝑘 31 + 𝑘 32 . Among them, 𝑘 31 code entities are retrieved from all code entities in the repository, while the other 𝑘 32 entities are retrieved from the structural memory graph. Both are retrieved based on embedding similarity with the dual query, or with the original query when no code draft satisfies the grounding threshold in code-draft-based query grounding. Repository-wide retrieval enables the system to discover code entities that have not yet been instantiated in the structural memory graph but are directly relevant to the current request, whereas retrieval over the structural memory graph prioritizes repository entities that have already been associated with conversational memories in preceding interactions. These retrieved entities collectively form the initial retrieval set 𝐸 0 . Starting from 𝐸 0 , we further perform a two-stage adjacency expansion over the dual memory graph. The first stage performs intra-graph expansion to recover local context within each memory space that is directly related to the initially retrieved entities. In the semantic memory graph, expansion along the directed semantic relations 𝑅se supplements other memory information that is different from but related to the retrieved textual memories. Such information may not be surfaced by the initial retrieval due to insufficient direct semantic similarity with the current query, but can be further recalled through the established memory associations. In the structural memory graph, we expand along the structural relations 𝑅st . Since 𝑅st represents direct child-to-parent containment relations between instantiated code entities, this expansion supplements fine-grained code entities with their direct higher-level structural context. Through this intra-graph expansion, we obtain 𝐸 1 . Formally, 𝐸 1 = 𝐸 0 ∪ {𝑒 | ∃𝑒 ′ ∈ 𝐸 0, (𝑒 ′, 𝑒) ∈ 𝑅se ∪ 𝑅st } .

(8)

The second stage performs inter-graph expansion to complement the retrieved context across the semantic and ∗ . For a semantic entity, this structural memory spaces. Starting from 𝐸 1 , we expand along the dual relations 𝑅dual and 𝑅dual

expansion further recalls its associated repository code entities; for a structural entity, it further recalls the conversational memories that reference that code entity. Because this stage is applied after intra-graph expansion, not only the initially retrieved entities but also the local neighbors discovered in the first stage can introduce corresponding cross-view context through the dual relations. In this way, conversational memories and repository code information complement each other during retrieval rather than being used as two independent sets of retrieval results. Formally,  ∗ 𝐸 2 = 𝐸 1 ∪ 𝑒 | ∃𝑒 ′ ∈ 𝐸 1, (𝑒 ′, 𝑒) ∈ 𝑅dual ∪ 𝑅dual .

(9)

The expansion process is deliberately bounded to one intra-graph expansion followed by one inter-graph expansion, rather than recursively traversing the dual memory graph. Therefore, only entities that have explicit relations with the initially retrieved entities or their direct local neighbors are further incorporated into the context, allowing ReConMem to exploit graph structure for complementary retrieval while avoiding unconstrained context expansion. For code entities retrieved through 𝑘 31 from the entire repository but not instantiated in the structural memory graph, they are retained as directly retrieved code context but do not participate in subsequent adjacency expansion because no corresponding graph relations are available. Through this two-stage process, the first stage enriches local context within

Manuscript submitted to ACM

10

Yang et al.

w/o Compression class IncrementalDecoder(UTF8IncrementalDecoder): @staticmethod def _buffer_decode( input: bytes, errors: Optional[str], final: bool ) -> tuple[str, int]: decoded_segments = [] position = 0 while True: decoded, consumed = ( IncrementalDecoder._buffer_decode_step( input[position:], errors, final )) if consumed == 0: break decoded_segments.append(decoded) position += consumed if final: assert position == len(input) return "".join(decoded_segments), position @staticmethod def _buffer_decode_step( input: bytes, errors: Optional[str], final: bool ) -> tuple[str, int]: sup = UTF8IncrementalDecoder._buffer_decode match = SPECIAL_BYTES_RE.search(input)

w/ Compression class IncrementalDecoder(UTF8IncrementalDecoder): @staticmethod def _buffer_decode( input: bytes, errors: Optional[str], final: bool ) -> tuple[str, int]: @staticmethod def _buffer_decode_step( input: bytes, errors: Optional[str], final: bool ) -> tuple[str, int]: @staticmethod def _buffer_decode_surrogates( sup: Callable[[ bytes, Optional[str], bool ], tuple[str, int]], input: bytes, errors: Optional[str], final: bool, ) -> tuple[str, int]:

... Fig. 4. Comparison of a class before and after compression.

each memory space, while the second stage further complements conversational information with repository code information, resulting in more complete task-relevant context. 2.3.3 Hierarchical Code Context Compression. The results of graph-adjacency-expanded retrieval provide comprehensive task-relevant context for the code assistant to respond to the user. This context often contains a large number of code entities at varying granularities. The full content of some code entities is relatively lengthy, and directly incorporating them into the context can introduce substantial noise and overhead, making it necessary to compress the code context. Considering that in practical development, higher-level code artifacts are primarily concerned with their overall structure rather than detailed logic, we introduce a hierarchical code context compression mechanism. This mechanism leverages the hierarchical structure of the repository and applies differentiated compression strategies to code entities of varying granularities, balancing information retention with context length. Specifically, a function entity, when directly retrieved as a fine-grained execution unit, is typically directly relevant to user requirements and is therefore fully preserved. In contrast, class and file entities primarily provide structural context, and are thus represented in a compressed form rather than retaining full implementations. During compression, we perform recursive traversal over the contained entity structure and abstract classes and files into signature-level structured summaries. As shown in Figure 4, these summaries preserve key structural information (e.g., interfaces and hierarchical relationships) while omitting implementation details, thereby effectively reducing context length and precisely minimizing redundant noise. Manuscript submitted to ACM

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations 3 3.1

11

Evaluation Research Questions • RQ1: Effectiveness. How effective is ReConMem in managing repository-oriented multi-turn conversations? • RQ2: Efficiency. What is the context-management cost of ReConMem? • RQ3: Ablation Study. To what extent does each key component contribute to ReConMem? • RQ4: Context Retrieval Quality. How effectively does ReConMem retrieve relevant and complementary context?

3.2

Benchmarks

To comprehensively evaluate repository-oriented conversational context management, we select two complementary benchmarks. LoCoEval [17] evaluates whether ReConMem can retain and utilize long-horizon conversational context for repository-level code generation. CodeAssistBench (CAB) [12] evaluates whether ReConMem can support realistic interactive software development assistance over complete repositories. 3.2.1 LoCoEval. LoCoEval is constructed from DevEval [14], a benchmark of manually annotated repository-level code generation tasks. LoCoEval extracts ground-truth information items from the reference implementations of selected DevEval tasks, introduces distracting information through mutation, and distributes these items into query outlines. During evaluation, a mock-user LLM dynamically generates queries based on the outline and the preceding response, and the evaluated LLM responds using the provided context. After the conversation-generation phase, function-generation queries are issued to evaluate whether the LLM can integrate conversational and repository information to produce implementations that pass the corresponding tests. LoCoEval contains 320 Python function-generation tasks across 128 long conversations, and is divided into two subsets: single-hop and multi-hop. In the single-hop subset, information relevant to a target task is relatively concentrated within the conversation, whereas in the multi-hop subset, relevant information is distributed across multiple topics and turns, requiring the system to identify and integrate dispersed contextual evidence. Each conversation contains at least 30 but fewer than 70 interaction turns, with an average of approximately 50 rounds. These characteristics make LoCoEval well suited for evaluating long-horizon conversational context management. The mock-user LLM is Gemini-2.5-Flash [8]. 3.2.2 CodeAssistBench. CodeAssistBench (CAB) is a benchmark for multi-turn, project-grounded programming assistance constructed from real-world GitHub issues. Unlike LoCoEval, which focuses on Python, the CAB Verified v3 release used in our experiments contains 274 human-verified issues across seven programming languages—Python, JavaScript, TypeScript, Java, Go, C, and C++—with human-reviewed satisfaction conditions.1 CAB’s evaluation framework consists of three agents: a User Agent, a Maintainer Agent, and a Judge Agent. The User Agent initiates the conversation with a programming question from a GitHub issue and provides follow-up responses; the Maintainer Agent represents the evaluated LLM, explores the repository, and answers the user across multiple turns; the Judge Agent evaluates the resulting conversation according to issue-specific satisfaction conditions and technical correctness. We set the maximum conversation length to 10 turns. In our CAB experiments, both the User Agent and the Judge Agent use Gemini-2.5-Flash, following the backbone setting adopted in LoCoEval. Before each interaction, the evaluation framework clones the target repository and checks out the commit specified by the dataset, after which the Maintainer Agent accesses the fixed repository snapshot through read-only code inspection and search tools. Among the 274 issues in CAB Verified 1 https://github.com/amazon-science/CodeAssistBench

Manuscript submitted to ACM

12

Yang et al.

v3, six could not be initialized due to unavailable repositories or cloning failures; therefore, all methods are evaluated on the same remaining 268 issues. 3.3

Metrics

We adopt different metrics following the two benchmarks. 3.3.1 LoCoEval. LoCoEval uses Pass@1 [4] as the primary effectiveness metric for repository-level function generation. A task is considered successfully completed if the generated code passes its execution-based test suite. Pass@1 denotes the percentage of successfully completed tasks. We also report the context compression ratio (CR) following LoCoEval, which measures the reduction in total prompt-context consumption over the LLM calls involved, relative to the Full baseline. For a context-management method 𝑀, CR is calculated as: InputTokens(Full) , (10) InputTokens(𝑀) where InputTokens(·) denotes the cumulative number of input tokens consumed by all LLM calls under the same CR(𝑀) =

experimental setting. A larger CR indicates lower prompt-context consumption, with CR(Full) = 1. CR characterizes context compression rather than the complete inference cost of a context-management method. We therefore additionally report end-to-end LLM token consumption, defined as the total input and output tokens consumed by response-generation and context-management LLM calls, excluding calls for mock-user simulation and judging. For ReConMem, we further decompose this end-to-end token consumption into Turn Generation, Task Generation, Memory Sketching, and Memory Update to characterize the cost distribution across different stages. We measure how well the retrieved context covers the ground-truth (GT) information items required by each function 𝑣 ∈ {0, 1} indicate whether context view generation task. Let 𝐺𝑖 denote the original GT item set for task-run 𝑖, and let 𝑠𝑖𝑔

𝑣 fully supports item 𝑔. We consider three context views: the original-query context, the dual-query context, and their combination. GT-item coverage is calculated as: 𝑁

1 ∑︁ Coverage(𝑣) = 𝑁 𝑖=1

Í

𝑣 𝑔∈𝐺𝑖 𝑠𝑖𝑔

|𝐺𝑖 |

,

(11)

where 𝑁 is the number of evaluated task-runs, each corresponding to a function generation task under a particular backbone and task setting. Coverage is therefore macro-averaged over task-runs, giving each task-run equal weight regardless of its number of GT items. We further characterize coverage complementarity by dividing the GT items into four mutually exclusive categories: supported by the original-query context only, by both contexts independently, by the dual-query context only, or by neither. Each category’s proportion is calculated within each task-run and then averaged across the same evaluation cohort. Combined-context coverage is evaluated independently on the merged context, rather than derived as the logical union of the two branch-level judgments. Since each context view is assessed in a separate LLM call, the combined score reflects an independent empirical judgment of the merged evidence and may therefore differ from the union implied by the two branch-level results. 3.3.2 CodeAssistBench. For CodeAssistBench, we follow its judge-based correctness evaluation. After each issue-level conversation concludes, the Judge Agent assigns one of three mutually exclusive labels—Correct, Partially Correct, or Incorrect—based on the technical correctness of the Maintainer Agent’s responses, their satisfaction of issue-specific user conditions, and, when applicable, execution results. Correct indicates that the responses are technically accurate and fully satisfy the user conditions, whereas Partially Correct indicates minor technical flaws or partial satisfaction Manuscript submitted to ACM

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations

13

of the conditions. We report the proportions of evaluated issues labeled Correct and Partially Correct; all remaining evaluated issues are classified as Incorrect. The Judge Agent additionally classifies response verbosity as Appropriate, Verbose, or Terse, indicating whether the amount of information provided is suitable, excessive, or insufficient, respectively. We report the proportion of evaluated issues assigned to each category. We also report the average number of interaction turns per issue (Avg. Turns), where each turn corresponds to one response from the Maintainer Agent. We distinguish between Maintainer tokens and Memory tokens. Maintainer tokens include all input and output tokens consumed by the Maintainer Agent, whereas Memory tokens capture the additional LLM token consumption introduced by an external memory mechanism. Their sum is reported as Combined tokens. Let 𝑁 denote the number of evaluated issues, 𝑟𝑖 the number of interaction turns for issue 𝑖, and 𝑇𝑖𝑥 the token consumption of category 𝑥 for that issue, where Memory

𝑥 ∈ {Maintainer, Memory, Combined} and 𝑇𝑖Combined = 𝑇𝑖Maintainer + 𝑇𝑖

. The per-issue and per-turn token costs

are calculated as: 𝑁

Tok./Issue𝑥 =

1 ∑︁ 𝑥 𝑇 , 𝑁 𝑖=1 𝑖

Tok./Turn𝑥 =

1 ∑︁ 𝑇𝑖𝑥 . 𝑁 𝑖=1 𝑟𝑖

(12)

𝑁

(13)

Thus, Tok./Turn is macro-averaged over issues: the token cost per turn is first calculated separately for each issue and then averaged across all issues. This gives every issue equal weight regardless of its interaction length. 3.4

Baselines

We compare ReConMem with different memory settings. • Full retains the complete conversational history and truncates it at the turn level only when the context exceeds the model’s context-window limit, without performing additional context selection or memory management. • Vanilla RAG retrieves the top-𝑘 user queries from the ongoing conversation history that are most similar to the current query and prepends the corresponding interaction turns as context. We set 𝑘 = 5 following LoCoEval. • MemGPT [21] adopts an OS-inspired virtual context management mechanism that manages information across hierarchical memory tiers. • LD-Agent [13] organizes long-term conversational information through event-based memory and persona modeling, together with topic-oriented retrieval. • Mem0 [6] maintains persistent conversational memories through dynamic extraction, integration, and retrieval. • Mem0 R [17], proposed together with LoCoEval, extends Mem0 specifically for repository-oriented long-horizon conversations. Instead of storing purely textual memories, Mem0R associates textual descriptions with the locations of relevant repository artifacts and uses these associations to retrieve the corresponding repository content when recalling memories. It therefore provides the most direct prior comparison for ReConMem, allowing us to examine ReConMem against an existing memory system that explicitly associates conversational information with repository artifacts. Together, these methods cover different designs for explicit long-term memory management and allow us to examine how general-purpose memory paradigms transfer to repository-oriented conversations. Because LoCoEval and CodeAssistBench adopt different interaction and evaluation frameworks, we adopt different comparisons. Manuscript submitted to ACM

14

Yang et al. For LoCoEval, we compare ReConMem with all six baselines. For Full, Vanilla RAG, MemGPT, LD-Agent, and Mem0,

we follow the LoCoEval protocol and provide repository access through a unified retrieval adaptation: for each user query, the 10 most similar repository functions are retrieved and supplied as additional context. This avoids comparing repository-aware methods against general-purpose baselines that lack access to repository information and allows the evaluation to focus more directly on their context-management mechanisms. For CodeAssistBench, we compare ReConMem with three baselines that represent different context-management strategies within the same Maintainer Agent framework: Full, Mem0 [6], and Strands Agents 1.45.02 , a host-agent baseline included in our CAB experiments that uses the native context-handling mechanism of the Strands-based Maintainer Agent without introducing an external memory system. It serves as the host-agent baseline and measures the performance achievable with the original agent context mechanism. 3.5

Implementation Details

Within each benchmark, all compared methods use the same response-generation prompt and repository-access configuration. The temperature of all LLMs is set to 0 to reduce variability caused by probabilistic sampling. Across both benchmarks, we implement ReConMem with Tree-sitter 3 to parse code repositories and construct repository-side code indices, and all-MiniLM-L6-v2 [28] with 384-dimensional embeddings to compute similarities for textual memories, code drafts, code entities, and repository retrieval. The LLM calls involved in memory sketching and memory updating use the same backbone model as response generation. The similarity threshold for code-draft-based query grounding is set to 0.35. For LoCoEval, our experiments use three advanced backbone LLMs: GPT-5 mini [20], DeepSeek-V3.2 [16], and Qwen3235B4 [32], which have maximum context-window lengths of 400K, 128K, and 256K tokens, respectively. These LLMs have broad user adoption and strong cost-effectiveness, and they cover both open-source and closed-source models. For retrieval hyperparameters, 𝑘 1 , 𝑘 2 , 𝑘 31 , and 𝑘 32 are set to 3, 6, 3, and 3 for DeepSeek-V3.2, respectively; for the other two models, the values are 2, 4, 2, and 2. To integrate ReConMem into LoCoEval, we use it to manage the context provided to the LLM. The preparation dialogue is processed sequentially, with each completed preparation turn triggering memory sketching and integration. Before generating each response, ReConMem retrieves relevant conversational memories and repository context. For the final function-generation tasks, the accumulated memory state is queried in a read-only manner, preventing independently evaluated tasks from affecting one another. We use all 128 LoCoEval conversation samples and evaluate their 320 function-generation tasks following the original conversation-generation and execution-based evaluation protocols. In CAB, we use Qwen3-235B as the backbone of the Maintainer Agent for all compared methods, using the same snapshot as in LoCoEval. ReConMem serves as the cross-turn context-management layer of the Maintainer Agent. Because no interaction memory is available initially, the first Maintainer response is generated without memory recall, after which the completed interaction is incorporated into memory. For each subsequent user follow-up, ReConMem retrieves relevant conversational memories and repository context to augment the Maintainer Agent’s input, and the memory state is updated after the response is completed. ReConMem is applied only to the Maintainer Agent; the User and Judge Agent configurations are held fixed across all compared methods. We directly reuse the core memory 2 https://strandsagents.com/ 3 https://tree-sitter.github.io 4We use its qwen3-235b-a22b-instruct-2507 snapshot.

Manuscript submitted to ACM

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations

15

Table 1. Experimental results of different methods and backbone models. The values with arrows indicate the absolute differences in Pass@1 (in percentage points, pp) between ReConMem and Mem0R , the strongest baseline in overall performance under the corresponding task setting. CR denotes the prompt-token-based context compression ratio following LoCoEval. Model

Full Pass@1

Vanilla RAG CR

Pass@1

CR

MemGPT Pass@1

CR

LD-Agent Pass@1

Mem0 R

Mem0

ReConMem

CR

Pass@1

CR

Pass@1

CR

Pass@1

CR

8.750 6.875 4.375

9.8× 15.0× 13.1×

30.625 5.625 5.000

5.3× 15.6× 15.4×

37.500 31.875 24.375

2.8× 5.1× 6.1×

38.125 ↑ 0.625 41.875 ↑ 10.000 38.125 ↑ 13.750

2.9× 5.0× 5.6×

6.667

12.6×

13.750

10.1×

31.250

4.4×

39.167 ↑ 7.917

4.3×

Single-hop GPT-5 mini DeepSeek-V3.2 Qwen3-235B

35.000 8.750 13.750

1.0× 1.0× 1.0×

40.625 25.625 16.875

5.7× 5.1× 5.6×

6.250 8.750 18.125

1.0× 1.2× 1.3×

Overall

19.167

1.0×

27.708

5.4×

11.042

1.2×

Multi-hop GPT-5 mini DeepSeek-V3.2 Qwen3-235B

35.625 11.875 18.750

1.0× 1.0× 1.0×

36.875 26.875 18.125

6.4× 6.1× 5.8×

12.500 14.375 21.250

1.0× 1.1× 1.1×

8.125 7.500 6.250

10.4× 15.5× 12.9×

30.625 7.500 9.375

5.6× 15.8× 15.8×

42.500 37.500 25.625

3.2× 5.4× 6.4×

40.625 ↓ 1.875 45.625 ↑ 8.125 41.250 ↑ 15.625

3.1× 5.0× 5.8×

Overall

22.083

1.0×

27.291

6.1×

16.042

1.1×

7.292

12.8×

15.833

10.4×

35.208

4.7×

42.500 ↑ 7.292

4.4×

implementation and the Qwen3-235B hyperparameter configuration from LoCoEval without additional tuning on CodeAssistBench. Following the CodeAssistBench protocol, each conversation terminates when the user indicates that the issue has been resolved or when the maximum of 10 turns is reached. 4

Results and Analysis

4.1

RQ1: Effectiveness

In controlled long-horizon context management scenarios, ReConMem improves code generation effectiveness and context utilization compared with existing baselines. As shown in Table 1, ReConMem achieves the highest overall Pass@1 on both the single-hop and multi-hop subsets of LoCoEval across all evaluated backbone models. Compared with the overall strongest baseline Mem0 R , ReConMem improves the overall Pass@1 by 7.917 and 7.292 percentage points on the single-hop and multi-hop subsets, respectively, while maintaining a comparable context compression ratio. The improvements are particularly pronounced on DeepSeek-V3.2 and Qwen3-235B. Compared with Mem0 R , ReConMem improves Pass@1 by 10.000 and 13.750 percentage points on the single-hop subset, and by 8.125 and 15.625 percentage points on the multi-hop subset, respectively. In contrast, on GPT-5 mini, ReConMem achieves competitive Pass@1 performance but does not consistently outperform the strongest baseline across both task settings. This suggests that the benefits of explicit context management are not identical across different LLMs and are related to the backbone models’ inherent capability in utilizing contextual information. Notably, GPT-5 mini has the largest context window among the three evaluated backbone LLMs. Compared with DeepSeek-V3.2 and Qwen3-235B, its Full History and Vanilla RAG baselines already achieve relatively strong Pass@1 performance, leaving less room for additional improvements from explicit memory management. This indicates that when backbone models are less effective at handling accumulated historical information or selecting task-relevant contexts, structured memory organization and targeted context retrieval can better compensate for these limitations and bring more substantial performance gains. In realistic repository-oriented interaction scenarios, ReConMem improves both task correctness and interaction quality compared with existing baselines. As shown in Table 2, Full History already achieves relatively strong performance by directly utilizing complete conversation histories, with Correct and Partially Correct rates of 23.51% and Manuscript submitted to ACM

16

Yang et al.

Table 2. Performance comparison on CodeAssistBench. Correctness and interaction-quality metrics are reported as percentages, and Avg. Turns denotes the average number of conversation turns per issue. Metric

Native Strands

Full History

Mem0

ReConMem

Correct (%) Partially Correct (%)

19.78 31.72

23.51 36.94

19.40 32.84

27.61 44.03

Appropriate (%) ↑ Verbose (%) ↓ Terse (%) ↓

60.45 27.24 12.31

60.45 25.37 14.18

62.31 30.60 7.09

67.54 27.24 5.22

Avg. Turns

4.30

4.03

4.18

3.84

36.94%, respectively. Nevertheless, ReConMem further improves these two metrics to 27.61% and 44.03%, achieving gains of 4.10 and 7.09 percentage points, respectively. These results indicate that, in repository-oriented multi-turn interactions, effectively managing and utilizing contextual information is more beneficial than simply retaining the complete conversation history. By organizing conversational memories and repository code information through structured representations and selecting relevant contexts according to the current request, ReConMem enables the agent to better identify and utilize task-related information, thereby improving problem-solving performance. In contrast, the general-purpose memory method Mem0 provides limited benefits in this repository-oriented setting. Its Correct and Partially Correct rates are 19.40% and 32.84%, respectively, which are even lower than those achieved by Full History without explicit memory management. This further suggests that context management for software engineering tasks requires modeling the structural associations between conversational information and repository code, while simply extracting and storing textual memories from historical interactions is insufficient to effectively improve task performance. Beyond correctness metrics, Table 2 shows that ReConMem achieves the highest Appropriate rate of 67.54% among all compared methods. Meanwhile, it requires the fewest average interaction turns, with only 3.84 turns compared with 4.30, 4.03, and 4.18 turns for Native Strands, Full History, and Mem0, respectively. These results indicate that the improvement achieved by ReConMem does not rely on generating longer responses or requiring additional interaction rounds. Instead, by retrieving and utilizing more relevant context, ReConMem enables the agent to provide responses that better satisfy user requirements while reducing unnecessary clarification and correction interactions. Answer to RQ1: ReConMem demonstrates strong overall effectiveness across both controlled long-horizon and realistic repository-oriented conversational settings. It achieves the highest overall Pass@1 on both LoCoEval subsets while maintaining a comparable context compression ratio, and achieves the highest Correct, Partially Correct, and Appropriate rates on CodeAssistBench with the fewest average interaction turns.

4.2

RQ2: Efficiency

Beyond the context compression ratio reported in Table 1, we further examine the end-to-end LLM token consumption of ReConMem on LoCoEval. We first examine the context-management cost of ReConMem on LoCoEval. As shown in Table 3, ReConMem substantially reduces token consumption compared with Full across all backbone models and task settings, with an approximately 55%–79% reduction in the average token consumption per conversation. Meanwhile, its token consumption remains comparable to Mem0 R , indicating that the performance gains observed in RQ1 are not obtained by substantially increasing context cost. Manuscript submitted to ACM

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations

17

Table 3. Average end-to-end LLM token consumption per conversation across different methods and backbone models on LoCoEval. The Average row reports the mean across the three backbone models. Full

Model

Vanilla RAG

MemGPT

LD-Agent

Mem0

Mem0R

ReConMem

Single-hop GPT-5 mini DeepSeek-V3.2 Qwen3-235B

3,388K 4,592K 4,162K

694K 1,028K 831K

3,611K 3,888K 3,154K

388K 309K 328K

1,075K 385K 369K

1,584K 1,072K 859K

1,534K 1,090K 907K

Average

4,047K

851K

3,551K

342K

610K

1,171K

1,177K

Multi-hop GPT-5 mini DeepSeek-V3.2 Qwen3-235B

3,275K 4,303K 3,902K

607K 807K 753K

3,455K 3,887K 3,348K

358K 282K 315K

983K 351K 331K

1,368K 930K 762K

1,420K 1,018K 826K

Average

3,827K

722K

3,564K

318K

555K

1,020K

1,088K

Table 4. Token consumption breakdown of ReConMem across different backbone models on LoCoEval. Tok./Conv. denotes the average number of input and output tokens consumed per conversation, while Share denotes the proportion of tokens consumed by each stage relative to the total token consumption of ReConMem. Turn Generation

Task Generation

Memory Sketching

Memory Update

Total

Model Tok./Conv.

Share (%)

Tok./Conv.

Share (%)

Tok./Conv.

Share (%)

Tok./Conv.

Share (%)

Tok./Conv.

Single-hop GPT-5 mini DeepSeek-V3.2 Qwen3-235B

911K 639K 526K

59.42 58.62 57.99

52K 30K 18K

3.43 2.78 2.04

174K 117K 114K

11.36 10.81 12.64

395K 302K 248K

25.79 27.79 27.34

1,534K 1,090K 907K

Average

692K

58.80

33K

2.87

135K

11.52

315K

26.81

1,177K

GPT-5 mini DeepSeek-V3.2 Qwen3-235B

837K 590K 464K

58.97 58.00 56.19

44K 27K 15K

3.16 2.66 1.92

167K 114K 109K

11.81 11.21 13.22

370K 286K 237K

26.07 28.13 28.67

1,420K 1,018K 826K

Average

630K

57.96

29K

2.69

130K

11.98

297K

27.37

1,088K

Multi-hop

Table 4 further decomposes the cost introduced by ReConMem. Memory Sketching and Memory Update together account for 38.33% and 39.35% of the total token consumption on the single-hop and multi-hop subsets, respectively, with Memory Update constituting the larger portion. Thus, explicit memory management itself introduces non-negligible overhead. The efficiency of ReConMem therefore depends on whether the cost of extracting and maintaining useful context can be offset by reducing the irrelevant information subsequently supplied to the backbone model. Notably, this stage-wise cost distribution remains similar across different backbone models and task settings. Figure 5 further shows how this trade-off changes with conversation length. At the early stages of a conversation, the history is still short, and the additional memory-management operations can make ReConMem more expensive than directly using the accumulated context. As the conversation progresses, however, the per-turn token consumption of Full continues to increase with the growing history, whereas ReConMem grows substantially more slowly by selectively retaining and recalling relevant information. From turn 10 to turn 60, the number of turns increases by a factor of six, whereas the per-turn token consumption of ReConMem increases by less than twofold. Therefore, the token-saving Manuscript submitted to ACM

18

Yang et al. Qwen3-235B ReConMem Qwen3-235B Full DeepSeek-V3.2 ReConMem DeepSeek-V3.2 Full GPT-5 mini ReConMem GPT-5 mini Full

160K 140K

Tokens per turn

120K 100K 80K 60K 40K 20K 0

0

10

20

30

Turns

40

50

60

Fig. 5. Per-turn token consumption of ReConMem and Full as conversation turns increase on LoCoEval.

benefit of ReConMem becomes increasingly pronounced as more historical information accumulates, because a larger amount of irrelevant or currently unnecessary context can be excluded from each turn. The CodeAssistBench results provide a complementary short-horizon perspective on this behavior. Unlike LoCoEval, CAB conversations terminate dynamically when the User Agent considers the issue resolved or when the maximum of 10 turns is reached, and the evaluated methods consequently exhibit different interaction lengths. Therefore, Tok./Issue and Tok./Turn should be interpreted jointly rather than as isolated measures of context-management efficiency: the former reflects both per-turn cost and the number of turns required to complete an interaction, whereas the latter normalizes conversation length but is still measured over method-dependent interaction trajectories. In practice, CAB conversations are short, averaging only around four turns. Under this setting, the historical context has not yet accumulated sufficiently for the savings from selective context management to offset its memory-management overhead. Accordingly, as shown in Table 5, ReConMem consumes 363,822.40 Combined Tok./Issue and 100,921.00 Combined Tok./Turn, compared with 325,622.92 and 84,972.27 for Full History, respectively. This result is consistent with the early-stage behavior observed in Figure 5. Nevertheless, the CAB results also show that the additional cost introduced by ReConMem is effectively controlled. Its Memory Tok./Issue is 17,241.94, approximately 56% lower than the 39,203.21 of Mem0, while its Combined Tok./Issue is approximately 10% lower. Moreover, the higher token consumption of ReConMem relative to Full History should be considered together with its interaction outcomes. As reported in RQ1, ReConMem achieves the highest Correct (27.61%), Partially Correct (44.03%), and Appropriate (67.54%) rates while requiring the fewest average turns (3.84). In particular, the higher Appropriate rate provides complementary evidence that its additional token consumption does not simply result from unnecessarily verbose responses. Taken together, these results suggest that, even before explicit token savings emerge in short conversations, selective context management can still improve the effectiveness of repository-oriented interactions by focusing the model on useful conversational and repository context. Answer to RQ2: ReConMem introduces additional memory-management overhead, but selectively extracting, consolidating, and recalling relevant context limits the growth of contextual cost as conversation history accumulates. Manuscript submitted to ACM

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations

19

Table 5. Token consumption of different context-management methods on CodeAssistBench. Maintainer tokens include all input and output tokens consumed by the Maintainer Agent, while memory tokens include the additional LLM token consumption introduced by the external memory mechanism. Combined tokens are the sum of the two. Tok./Turn is macro-averaged over issues.

Metric

Native Strands

Full History

Mem0

ReConMem

Maintainer Tok./Issue Memory Tok./Issue Combined Tok./Issue

360,521.97 0 360,521.97

325,622.92 0 325,622.92

365,017.51 39,203.21 404,220.72

346,580.46 17,241.94 363,822.40

Maintainer Tok./Turn Memory Tok./Turn Combined Tok./Turn

96,825.50 0 96,825.50

84,972.27 0 84,972.27

94,146.95 9,437.53 103,584.48

96,357.12 4,563.88 100,921.00

Consequently, its token-efficiency advantage becomes increasingly evident in long-horizon conversations. In shorter interactions, this overhead may not yet be fully offset by token savings, but ReConMem still maintains controlled memory cost and improves interaction effectiveness without relying on longer or excessively verbose conversations. Overall, ReConMem supports both efficient long-horizon context management and effective context utilization in shorter repository-oriented interactions.

4.3

RQ3: Ablation Study

To evaluate the effectiveness of each core component in ReConMem, we conduct ablation studies on LoCoEval. We focus the ablation analysis on LoCoEval because its controlled long-horizon evaluation setting allows the effects of individual context-management components on generation accuracy and context efficiency to be examined more directly. Specifically, we remove or modify key components as follows: ❶ w/o GAE: removing graph-based adjacency expansion and using similarity-based retrieval only; ❷ w/o SMG: removing direct retrieval on the structural memory graph, and instead allowing code entities to be obtained solely through expansion via inter-graph adjacency; ❸ w/o QG: disabling code-draft-based query grounding and directly using the original query for code-side retrieval; and ❹ w/o HCC: disabling hierarchical code context compression and retaining full code snippets after retrieval. To control variables, we adjust the hyperparameters to keep the compression ratio under different ablation settings as consistent as possible with the reference value. All experiments use Qwen3-235B as the backbone model. The ablation results in Table 6 show that removing any key component leads to a decrease in Pass@1, indicating that each module contributes to the overall framework. Specifically, removing graph-based adjacency expansion (w/o GAE) decreases Pass@1 by 7.500 and 10.625 percentage points on the single-hop and multi-hop subsets, respectively. Removing direct retrieval on the structural memory graph (w/o SMG) results in decreases of 10.000 and 6.875 percentage points. These two settings cause the largest performance degradation among all ablations, while their changes in compression ratio remain comparatively limited, highlighting the importance of the memory graph structure and joint retrieval mechanism for generation accuracy. In contrast, removing hierarchical code context compression (w/o HCC) mainly affects context efficiency. Its Pass@1 decreases by only 1.875 and 0.625 percentage points on the single-hop and multi-hop subsets, respectively, while the compression ratio decreases substantially by 29.60% and 27.92%. This demonstrates that HCC primarily contributes to controlling code-context consumption while preserving generation accuracy. In addition, disabling code-draft-based query grounding (w/o QG) reduces Pass@1 by 1.875 and 3.750 percentage points on the two subsets, respectively, while Manuscript submitted to ACM

20

Yang et al.

Table 6. Ablation study results on LoCoEval using Qwen3-235B. The values with arrows indicate the absolute differences in Pass@1 (in percentage points, pp) compared with the complete ReConMem configuration. Method

Single-hop Pass@1

Multi-hop CR

Pass@1

CR

ReConMem

38.125

5.6×

41.250

5.8×

w/o GAE w/o SMG w/o QG w/o HCC

30.625 ↓ 7.500 28.125 ↓ 10.000 36.250 ↓ 1.875 36.250 ↓ 1.875

6.2× 5.2× 5.8× 4.0×

30.625 ↓ 10.625 34.375 ↓ 6.875 37.500 ↓ 3.750 40.625 ↓ 0.625

5.4× 5.3× 5.8× 4.2×

having little effect on the compression ratio. This result shows that the code-draft-based query grounding provides consistent additional gains in generation accuracy. Answer to RQ3: All four components contribute to ReConMem, but in different ways. GAE and direct retrieval on the structural memory graph contribute most to generation accuracy, QG provides additional accuracy gains, and HCC primarily improves context efficiency.

4.4

RQ4: Context Retrieval Quality

To examine the coverage and complementarity of the contexts retrieved by ReConMem, we analyze 960 LoCoEval task-runs across the three backbone models and the single-hop and multi-hop settings, covering 37 repositories. For each task-run, we evaluate the original-query context, the dual-query context, and their merged context after removing exact duplicate snippets within each modality. Each context view is evaluated independently by Gemini-2.5-Flash with temperature set to 0 and a fixed prompt containing eight synthetic examples. We use the ground-truth (GT) items that LoCoEval provides as evaluation targets. A GT item is considered supported only when the supplied context provides sufficient evidence for all its substantive requirements; partial support receives no credit, and neither the task query nor the reference code is treated as retrieved evidence. Positive judgments must reference valid evidence identifiers in the supplied context, and structured outputs are checked automatically for item completeness and evidence-identifier validity. We estimate percentile-based 95% confidence intervals using 2,000 repository-cluster bootstrap resamples. Figure 6(a) reports the GT-item coverage of the original-query, dual-query, and combined contexts, while Figure 6(b) characterizes the complementary contributions of the two retrieval branches. As shown in Figure 6(a), the original-query context achieves an average coverage of 71.95%, compared with 47.18% for the dual-query context. The independently evaluated combined context achieves 76.69%, exceeding the original-query context by 4.75 percentage points, with a 95% confidence interval of [2.09, 6.83] percentage points for the increase. These results indicate that the original-query branch provides broader coverage under the evaluated configuration, while incorporating the dual-query results increases the coverage of task requirements. Figure 6(b) further characterizes the coverage contributed by the two branches. On average, 39.25% of GT items are supported by both contexts independently, 32.69% are supported only by the original-query context, and 7.94% are supported only by the dual-query context. Thus, despite its lower standalone coverage, the dual-query branch provides task-relevant evidence absent from the original-query results. The substantial original-only coverage likewise shows that the two branches make distinct contributions and cannot fully substitute for one another. The remaining 20.12% of items are unsupported by either context when evaluated separately. Manuscript submitted to ACM

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations (a) Context coverage

(b) Coverage complementarity 50

76.69%

71.95%

60

47.18%

40 20 0

Original-query

Dual-query

Share of GT items (%)

GT-item coverage (%)

100 80

21

Combined

39.25%

40

32.69% 30

20.12%

20

7.94%

10 0 Original only

Both

Dual only

Neither

Fig. 6. Context coverage and complementarity of ReConMem on LoCoEval. (a) Mean GT-item coverage of the original-query, dualquery and combined contexts. (b) Proportions of GT items supported by the original-query context only, both contexts independently, the dual-query context only, or neither. All values are macro-averaged over task-runs. Error bars indicate 95% repository-cluster bootstrap confidence intervals.

One interpretation of this pattern concerns the different retrieval entry points. The original query starts from textual memories and more directly accesses descriptions of requirements, design decisions, and behavioral constraints. The dual query provides a code-oriented entry point that can lead to concrete interfaces, dependencies, and implementation behavior. Such information may cover fewer GT items while still providing specific references for implementing the corresponding requirements. The two retrieval routes may therefore emphasize different aspects of requirement coverage and implementation guidance, with the observed dual-only coverage providing direct evidence of their complementarity. Moreover, both branches undergo graph-based expansion, and their output sizes depend on the initial retrieval budgets, accessible neighborhoods, and overlap among entities. They are not constrained to equal snippet counts or token budgets, and both can return textual and code content through cross-graph relations. The coverage difference therefore describes their contributions under the current retrieval configuration, rather than ranking the two modalities under an equal budget. The central observations are the exclusive information provided by each branch and the coverage improvement obtained from their combination. To illustrate the relationship between the retrieval results, Figure 7 presents t-SNE visualizations of the semantic and structural contexts. Points associated with the two query sources overlap but also exhibit differences in their local distributions, with some local groups more prominently represented by one source. This pattern is consistent with the shared and exclusive coverage in Figure 6: the two branches retrieve some common information while also returning distinct context. The visualization provides a qualitative view of their distributions, while the GT-item evaluation establishes their complementary support for task requirements. Answer to RQ4: ReConMem’s two retrieval branches provide asymmetric but complementary coverage of taskrelevant information. The original-query branch achieves broader coverage, while the dual-query branch exclusively supports 7.94% of GT items. Their combined context achieves 76.69% average coverage, exceeding the original-query context by 4.75 percentage points and supporting the effectiveness of using both retrieval routes. Manuscript submitted to ACM

22

Yang et al.

Semantic Context

Structural Context

original query dual query

80

75

60 50 40 25

20 0

0

20

25

40

50

60

75

80 80

60

40

20

0

20

40

60

80

75

50

25

0

25

50

75

Fig. 7. t-SNE visualization of retrieved semantic (left) and structural (right) contexts from the dual memory graph, obtained via the original query (blue) and dual query (orange). The visualization qualitatively reflects local distributional overlap and differences between the two retrieval routes.

5

Discussion

5.1

Performance under Varying Conversation Characteristics

To understand how different conversation characteristics affect context-management performance, we further analyze the experimental results of ReConMem on LoCoEval. Specifically, we partition the LoCoEval conversations according to the number of code-generation tasks (𝑘) and conversation length (𝑙), and report the Pass@1 performance of different methods in Figure 8. As shown in Figure 8 (left), ReConMem achieves the highest Pass@1 among all evaluated methods in the multi-task settings (𝑘 = 2, 3, 4), whereas Mem0 R slightly outperforms ReConMem in the single-task setting. This suggests that ReConMem tends to exhibit a clearer advantage when a conversation involves multiple code-generation tasks and the relevant context may be distributed across different parts of the interaction. However, the performance of ReConMem does not increase monotonically with the number of tasks. It achieves its best performance at 𝑘 = 3, while its Pass@1 decreases by 13.45 percentage points when 𝑘 further increases to 4. This indicates that increasing task complexity provides more opportunities to leverage historical context, while also introducing additional challenges caused by information competition and retrieval difficulty. Conversation length exhibits a similar pattern. As shown in Figure 8 (right), the performance of all methods decreases as conversations become longer, including that of ReConMem. In comparison, the advantage of ReConMem lies in maintaining stronger relative performance as conversational context accumulates. In the longest conversation interval [60, 70), both ReConMem and the baselines exhibit a clear drop in Pass@1, but the decrease of ReConMem is less pronounced than those of the baselines. Overall, our results support a more restrained conclusion: by explicitly maintaining memories of conversational history and repository code, together with their associations, ReConMem can effectively mitigate the retrieval difficulty Manuscript submitted to ACM

Pass@1 (%)

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations

50

50

40

40

30

30

20

20

10

10

0

1

2

3

k

4

0

23

Full Vanilla RAG MemGPT LD-Agent

[30, 40)

[40, 50)

[50, 60)

Mem0 Mem0R ReConMem

[60, 70)

Interval of l

Fig. 8. Trend of Pass@1 for each method, with respect to the number of tasks per conversation 𝑘 (left) and the number of turns per conversation 𝑙 (right).

and context interference caused by information accumulation, but it cannot make the model completely insensitive to increasing interaction complexity. 5.2

Threats to Validity

Threats to internal validity primarily arise from differences in context consumption across methods and the inherent variability of LLM-based processing. On LoCoEval, we carefully tune the retrieval-related hyperparameters to keep the token usage of ReConMem as comparable as possible to that of the strongest baseline, Mem0 R . However, because conversations evolve dynamically and different methods employ different context-management mechanisms, it is difficult to strictly control the final token consumption, making some discrepancies unavoidable. Nevertheless, as discussed in §4.1, the differences in context compression ratio are relatively limited compared with the observed performance gains. In addition, although we set the temperature of all backbone LLMs to 0 to reduce variability caused by probabilistic sampling, model generation may still exhibit minor nondeterminism due to model-serving and hardware-level factors. Another potential threat arises from the use of LLM-based judgments in the evaluation. CodeAssistBench relies on a Judge Agent to assess correctness and interaction quality, while our context retrieval quality analysis also uses an LLM to determine whether the retrieved contexts sufficiently support the ground-truth information items. Such judgments may introduce evaluation variance or model-specific bias. To mitigate this threat, we follow the original CodeAssistBench evaluation protocol and keep the Judge Agent unchanged across all compared methods. For the context retrieval quality evaluation, we first calibrate the LLM on a subset of examples, analogous to a training set. We then freeze the calibrated prompt and evaluate its agreement on a separate set of examples, analogous to a validation set. Full-scale annotation is conducted only after all of these consistency checks are passed. Throughout this process, we use exactly the same evaluator, temperature, prompt, and decision criteria for all context views. These controls improve evaluation consistency across different experimental conditions, although they cannot completely eliminate the uncertainty inherent in LLM-based evaluation. Threats to external validity mainly concern the generalizability of our results. Repository-oriented conversational context management remains a relatively emerging research setting, and currently available benchmarks cover only a limited range of development tasks and interaction patterns. We evaluate ReConMem on two complementary Manuscript submitted to ACM

24

Yang et al.

benchmarks, LoCoEval and CodeAssistBench. Although this combination broadens the evaluation beyond a single benchmark, it still cannot cover all repository-oriented development scenarios, such as longer-term cross-session development processes and other forms of repository evolution. Finally, due to computational and budget constraints, our evaluation covers only a limited set of backbone models. LoCoEval is evaluated with three different LLMs, whereas CodeAssistBench uses Qwen3-235B as the Maintainer backbone under a fixed agent configuration. Although the results across different LoCoEval backbones and the complementary CodeAssistBench setting exhibit consistent overall trends, the exact performance gains and efficiency trade-offs may vary across different models, repository distributions, and interaction settings. 6

Related Work

With the increasing application of large language models (LLMs) in multi-turn conversations and complex software development tasks [5, 10], effectively leveraging historical context over long-horizon interactions has become a critical research challenge [19]. Due to the limitation of context windows, models are unable to directly process excessively long conversational sequences, which has motivated a growing body of work on external mechanisms to enhance context management. Early approaches primarily construct such mechanisms based on simple retrieval-augmented generation (RAG), where historical conversations are stored and relevant segments are retrieved at query time to augment generation, such as RECOMP [30] and COCOM [23]. While these methods are simple to implement and scalable, they typically manage context at a coarse granularity, such as turn-level, which can easily introduce a large amount of noisy information. To address this limitation, subsequent work explores more fine-grained context management strategies. The dominant paradigm, referred to as memory systems, periodically extracts conversational context into a set of atomic memory units, which are retrieved as background knowledge in each turn. Early memory systems typically store and retrieve memory units independently [13, 15, 21, 24, 36], overlooking the semantic relationships among them, which leads to issues such as fragmented retrieval results and insufficient accuracy [31, 35]. To address this, some studies [6, 11, 22, 25, 29, 31] further propose leveraging graphs to model relationships among memories, enabling more coherent retrieval and improved coverage. Building upon these developments, as code LLMs extend toward repository-level software engineering tasks [3, 18, 33, 34], recent research has begun to address scenarios involving both code repositories and multi-turn conversations. Compared to single-turn or short-context code generation, such tasks require continuously leveraging historical interactions while reasoning over structured code context within repositories, posing higher demands on memory modeling. In terms of evaluation data, LoCoEval [17] is the first benchmark to systematically define long-horizon conversational context management for repository-level settings. It constructs multi-turn interaction processes and evaluates model performance on repository-level tasks based on conversational information, thereby assessing the model’s ability to accumulate and utilize long-horizon context. Experimental results show that existing general-purpose memory systems provide limited benefits in this scenario, struggling to effectively integrate both conversational and repository context. On the methodological side, a limited number of existing studies have explored this problem from different perspectives. For example, Liu et al. [17] extend memory mechanisms centered solely on conversation, building upon the general memory system Mem0 [6] and proposing Mem0 R to integrate conversational history with relevant code context in repository settings; CodeMEM [27] emphasizes structure-based modeling on the code side. It incorporates abstract syntax trees to guide memory construction and updating, thereby enhancing the representation of code semantics. Manuscript submitted to ACM

ReConMem: A Graph-Based Dual Memory System for Repository-Oriented Conversations

25

Overall, research on memory systems for repository-oriented conversation is still at an early stage. Existing approaches typically focus on a single perspective, such as conversational information, code structure, or repository history, and lack a unified representation and coordinated utilization of multiple information sources. This highlights the need to integrate contextual information from different sources and at different granularities, which is exactly what ReConMem aims to address. 7

Conclusion

In this work, we investigated how conversational history and repository context can be effectively managed together in repository-oriented multi-turn interactions. ReConMem addresses this problem by maintaining their associations through a dual memory graph and selectively recalling complementary conversational and code context for each request. Evaluations on LoCoEval and CodeAssistBench show that this design improves code generation and problem-solving effectiveness across both controlled long-horizon conversations and realistic project-grounded interactions. The retrieval analysis further shows that natural-language and code-side retrieval provide asymmetric but complementary evidence, while the ablation results confirm that graph-based retrieval and direct use of repository structure make substantial contributions to generation accuracy. More broadly, our findings suggest that repository-oriented context management should not be viewed merely as a mechanism for compressing histories that exceed an LLM’s context window. Even when the complete conversation remains manageable, selectively organizing and retrieving relevant context can improve interaction effectiveness. As conversations grow longer, the same mechanism additionally limits the increasing cost of repeatedly supplying accumulated history. Repository-oriented context management is therefore fundamentally a problem of maintaining the relationship between evolving conversational intent and repository state, and exposing the information relevant to the current task. ReConMem provides one realization of this perspective by explicitly preserving and jointly utilizing these two sources of context. References [1] Anthropic. 2024. Claude Code. https://claude.com/product/claude-code [2] Anysphere. 2024. Cursor. https://cursor.com/ [3] Ramakrishna Bairi, Atharv Sonwane, Aditya Kanade, Vageesh D C, Arun Iyer, Suresh Parthasarathy, Sriram Rajamani, Balasubramanyan Ashok, and Shashank Shet. 2024. Codeplan: Repository-level coding using llms and planning. Proceedings of the ACM on Software Engineering 1, FSE (2024), 675–698. [4] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374 (2021). [5] Xiang Chen, Chaoyang Gao, Chunyang Chen, Guangbei Zhang, and Yong Liu. 2025. An empirical study on challenges for llm application developers. ACM Transactions on Software Engineering and Methodology 34, 7 (2025), 1–37. [6] Prateek Chhikara, Dev Khant, Saket Aryan, Taranjeet Singh, and Deshraj Yadav. 2025. Mem0: Building production-ready ai agents with scalable long-term memory. arXiv preprint arXiv:2504.19413 (2025). [7] Cline. 2025. Cline. https://cline.bot/ [8] Gheorghe Comanici, Eric Bieber, Mike Schaekermann, Ice Pasupat, Noveen Sachdeva, Inderjit Dhillon, Marcel Blistein, Ori Ram, Dan Zhang, Evan Rosen, et al. 2025. Gemini 2.5: Pushing the frontier with advanced reasoning, multimodality, long context, and next generation agentic capabilities. arXiv preprint arXiv:2507.06261 (2025). [9] Github. 2021. Github Copilot. https://github.com/features/copilot [10] Junda He, Christoph Treude, and David Lo. 2025. Llm-based multi-agent systems for software engineering: Literature review, vision, and the road ahead. ACM Transactions on Software Engineering and Methodology 34, 5 (2025), 1–30. [11] Zhengjun Huang, Zhoujin Tian, Qintian Guo, Fangyuan Zhang, Yingli Zhou, Di Jiang, Zeying Xie, and Xiaofang Zhou. 2026. Licomemory: Lightweight and cognitive agentic memory for efficient long-term reasoning. In Findings of the Association for Computational Linguistics: ACL 2026. 36842–36858. Manuscript submitted to ACM

26

Yang et al.

[12] Myeongsoo Kim, Shweta Garg, Baishakhi Ray, Varun Kumar, and Anoop Deoras. 2025. CodeAssistBench (CAB): Dataset & Benchmarking for Multi-turn Chat-Based Code Assistance. arXiv preprint arXiv:2507.10646 (2025). [13] Hao Li, Chenghao Yang, An Zhang, Yang Deng, Xiang Wang, and Tat-Seng Chua. 2025. Hello again! llm-powered personalized agent for long-term dialogue. In Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers). 5259–5276. [14] Jia Li, Ge Li, Yunfei Zhao, Yongmin Li, Huanyu Liu, Hao Zhu, Lecheng Wang, Kaibo Liu, Zheng Fang, Lanshen Wang, et al. 2024. Deveval: A manually-annotated code generation benchmark aligned with real-world code repositories. In Findings of the Association for Computational Linguistics: ACL 2024. 3603–3614. [15] Zhiyu Li, Shichao Song, Hanyu Wang, Simin Niu, Ding Chen, Jiawei Yang, Chenyang Xi, Huayi Lai, Jihao Zhao, Yezhaohui Wang, et al. 2025. MemOS: An Operating System for Memory-Augmented Generation (MAG) in Large Language Models. arXiv preprint arXiv:2505.22101 (2025). [16] Aixin Liu, Aoxue Mei, Bangcai Lin, Bing Xue, Bingxuan Wang, Bingzheng Xu, Bochao Wu, Bowei Zhang, Chaofan Lin, Chen Dong, et al. 2025. DeepSeek-v3.2: Pushing the frontier of open large language models. arXiv preprint arXiv:2512.02556 (2025). [17] Yang Liu, Li Zhang, Fang Liu, Ping Lin, and Xinyi Li. 2026. A Scalable Benchmark for Repository-Oriented Long-Horizon Conversational Context Management. arXiv preprint arXiv:2603.06358 (2026). [18] Yingwei Ma, Qingping Yang, Rongyu Cao, Binhua Li, Fei Huang, and Yongbin Li. 2025. Alibaba lingmaagent: Improving automated issue resolution via comprehensive repository exploration. In Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering. 238–249. [19] Lingrui Mei, Jiayu Yao, Yuyao Ge, Yiwei Wang, Baolong Bi, Yujun Cai, Jiazhi Liu, Mingyu Li, Zhong-Zhi Li, Duzhen Zhang, et al. 2025. A survey of context engineering for large language models. arXiv preprint arXiv:2507.13334 (2025). [20] OpenAI. 2025. GPT-5 Mini Model Overview. https://platform.openai.com/docs/models/gpt-5-mini. [21] Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G Patil, Ion Stoica, and Joseph E Gonzalez. 2023. Memgpt: Towards llms as operating systems. arXiv preprint arXiv:2310.08560 (2023). [22] Preston Rasmussen, Pavlo Paliychuk, Travis Beauvais, Jack Ryan, and Daniel Chalef. 2025. Zep: a temporal knowledge graph architecture for agent memory. arXiv preprint arXiv:2501.13956 (2025). [23] David Rau, Shuai Wang, Hervé Déjean, Stéphane Clinchant, and Jaap Kamps. 2025. Context Embeddings for Efficient Answer Generation in Retrieval-Augmented Generation. In Proceedings of the Eighteenth ACM International Conference on Web Search and Data Mining (Hannover, Germany) (WSDM ’25). Association for Computing Machinery, New York, NY, USA, 493–502. doi:10.1145/3701551.3703527 [24] Zhen Tan, Jun Yan, I-Hung Hsu, Rujun Han, Zifeng Wang, Long Le, Yiwen Song, Yanfei Chen, Hamid Palangi, George Lee, et al. 2025. In prospect and retrospect: Reflective memory management for long-term personalized dialogue agents. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 8416–8439. [25] Zihao Tang, Xin Yu, Ziyu Xiao, Zengxuan Wen, Zelin Li, Jiaxi Zhou, Hualei Wang, Haohua Wang, Haizhen Huang, Weiwei Deng, et al. 2026. Mnemis: Dual-route retrieval on hierarchical graphs for long-term LLM memory. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 23914–23928. [26] Trae. 2025. Trae. https://trae.ai/ [27] Peiding Wang, Li Zhang, Fang Liu, Chongyang Tao, and Yinghao Zhu. 2026. Codemem: Ast-guided adaptive memory for repository-level iterative code generation. In Findings of the Association for Computational Linguistics: ACL 2026. 16903–16917. [28] Wenhui Wang, Furu Wei, Li Dong, Hangbo Bao, Nan Yang, and Ming Zhou. 2020. Minilm: Deep self-attention distillation for task-agnostic compression of pre-trained transformers. Advances in neural information processing systems 33 (2020), 5776–5788. [29] Yaxiong Wu, Yongyue Zhang, Sheng Liang, and Yong Liu. 2025. Sgmem: Sentence graph memory for long-term conversational agents. arXiv preprint arXiv:2509.21212 (2025). [30] Fangyuan Xu, Weijia Shi, and Eunsol Choi. 2024. RECOMP: Improving retrieval-augmented LMs with context compression and selective augmentation. In The Twelfth International Conference on Learning Representations. [31] Wujiang Xu, Zujie Liang, Kai Mei, Hang Gao, Juntao Tan, and Yongfeng Zhang. 2025. A-Mem: Agentic Memory for LLM Agents. In Advances in Neural Information Processing Systems, D. Belgrave, C. Zhang, H. Lin, R. Pascanu, P. Koniusz, M. Ghassemi, and N. Chen (Eds.), Vol. 38, Main Conference. Curran Associates, Inc., 17577–17604. doi:10.52202/085713-0593 [32] An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, et al. 2025. Qwen3 technical report. arXiv preprint arXiv:2505.09388 (2025). [33] John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. Swe-agent: Agent-computer interfaces enable automated software engineering. Advances in Neural Information Processing Systems 37 (2024), 50528–50652. [34] Kechi Zhang, Jia Li, Ge Li, Xianjie Shi, and Zhi Jin. 2024. Codeagent: Enhancing code generation with tool-integrated agent systems for real-world repo-level coding challenges. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 13643–13658. [35] Yujie Zhang, Weikang Yuan, and Zhuoren Jiang. 2025. Bridging intuitive associations and deliberate recall: Empowering llm personal assistant with graph-structured long-term memory. In Findings of the Association for Computational Linguistics: ACL 2025. 17533–17547. [36] Wanjun Zhong, Lianghong Guo, Qiqi Gao, He Ye, and Yanlin Wang. 2024. Memorybank: Enhancing large language models with long-term memory. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 38. 19724–19731. Manuscript submitted to ACM

Related documents

• Remember Your Trace: Memory-Guided Long-Horizon Agentic Framework for Consistent and Hierarchical Repository-Level Code Documentation#1141539
• A Tool-Augmented, GPT-4 Chatbot for Real-Time Repository Data Analysis#984498
• A Graph-Native Bitemporal Memory Store for Conversational AI Agents#411142
• AdaPath: Query-Adaptive Path-Finding via Path-Bank for Multi-Hop Implicit Biomedical KGQA#799746
• From Pocket-Inferer to SemanticWebBrowser: Incremental development of a user-friendly, deterministic, language-interface-based, web-paradigm-agnostic, IDE-like, energy-efficient Web-Browser#85455