Dongfang Li

Affiliation:

Harbin Institute of Technology, Shenzhen

Zixuan Liu

Affiliation:

Harbin Institute of Technology, Shenzhen

Junmai Wang

Affiliation:

Harbin Institute of Technology, Shenzhen

Jiahe Huang

Affiliation:

Harbin Institute of Technology, Shenzhen

Fuhao Li

Affiliation:

Harbin Institute of Technology, Shenzhen

Bonian Jia

Affiliation:

Harbin Institute of Technology, Shenzhen

Baotian Hu

Affiliation:

Harbin Institute of Technology, Shenzhen

Min Zhang

Affiliation:

Harbin Institute of Technology, Shenzhen

Abstract

Long-horizon LLM agents must preserve information from past interactions to support future tasks. Existing memory systems typically rely on eager consolidation, invoking LLMs after each interaction to extract, summarize, or update memories. This design makes memory construction increasingly costly as conversations grow. Coarse summarization can reduce construction cost but risks discarding fine-grained contextual evidence, whereas larger retrieval contexts or multi-hop LLM reasoning shift the overhead to query time. We present LycheeMemory V2, an efficient long-term memory framework that replaces turn-level consolidation with semantic segment-level consolidation. Instead of consolidating every interaction, LycheeMemory batches multiple exchanges into segments and encodes each finalized segment into context-independent typed memory records. Segment-level batching lowers LLM encoding frequency, while semantic boundary detection helps preserve coherent event-level and temporal evidence compared with fixed-window batching. The resulting records are organized with lightweight structured indexes for query-planned evidence retrieval. Experiments using GPT-4.1-Mini show that LycheeMemory achieves state-of-the-art performance, reaching 89.22% on LoCoMo and 92.20% on LongMemEval-S. Compared with A-Mem, it reduces construction tokens by 86.0% on LoCoMo and 75.9% on LongMemEval-S without increasing query-time token usage. More broadly, our results suggest that the accuracy–cost trade-off of long-term agent memory depends not only on what information is retained, but also on the granularity at which it is consolidated.

媒体内容 · 前往原文查看

1 Introduction

Large language model (LLM) agents (31; 24; 21) are increasingly expected to operate as persistent assistants rather than single-turn responders. In long-horizon settings (20; 28) such as personal assistance, customer support, tutoring, and task-oriented dialogue, an agent (31; 5) must remember user preferences, historical events, evolving facts, constraints, and previous failures across many interactions.

Since an LLM cannot reliably keep an unbounded interaction history in its active context window, recent systems (24; 12; 5; 29; 6; 8) have introduced external memory modules to extract, update, organize, and retrieve information from past conversations. A common design in these systems (5; 29; 12; 9; 13) is eager consolidation: after each turn or short exchange, an LLM is invoked to summarize the interaction, extract facts, update existing memories, or build links with historical memories. Although effective, this turns memory construction into a high-frequency LLM operation (9; 6; 13; 26) whose token cost accumulates rapidly as conversations grow.

Simply making memory cheaper by storing coarser summaries is also insufficient, because long-term memory questions (20; 28) often depend on fine-grained evidence (6; 8; 17) such as entities, temporal expressions, coreference relations, and small contextual details. Meanwhile, improving recall (16) by expanding top-$k$ retrieval or using LLM-driven multi-hop search (17; 3; 14) introduces additional query-time overhead. Thus, the key challenge is not merely how to store more history, but how to preserve sufficient evidence at the right granularity while keeping both construction and retrieval costs under control.

Motivated by these limitations, we propose LycheeMemory V2, a cost-efficient long-term memory framework for LLM agents (Figure 2). The core idea is that past experience should re-enter future reasoning with the proper granularity, temporal relation, and evidence strength. Instead of consolidating every turn, LycheeMemory batches multiple exchanges and invokes the LLM once for each finalized segment, thereby reducing construction frequency. Within this segment-level batching scheme, semantic surprise and cohesion signals determine where segments end, helping preserve coherent event boundaries rather than relying on mechanical fixed windows. Each segment is then encoded into context-independent typed memory records that contain natural-language statements, memory types, entities, topics, temporal scopes, and links to the original dialogue evidence. To maintain continuity across segments without re-reading the full history, the system carries lightweight disambiguation feedback, including entity aliases and reference relations, into later consolidation steps. LycheeMemory further organizes records in an append-only structured memory store with entity, topic, temporal, event-frame, and entity-topic indexes. At query time, a planner decomposes the user question into multiple recall routes and retrieves evidence from semantic memory, structured indexes, temporal indexes, and raw turns, followed by route-level reranking, fusion, and diversity-aware selection. This design improves evidence coverage without relying on blind context expansion.

We evaluate LycheeMemory on LoCoMo and LongMemEval-S (20; 28). The results show that LycheeMemory consistently improves long-term memory QA accuracy while substantially reducing construction-token cost, achieving over 20-point accuracy gains over A-Mem (29) with up to 7.2$\times$ fewer construction tokens. These improvements are obtained with lower query-time token usage than A-Mem, with particularly large gains on multi-hop, temporal-reasoning, preference-tracking, and multi-session questions.

• We identify memory-construction granularity as an important efficiency lever for long-term agent memory: batching multiple exchanges reduces write-side LLM calls, while semantic boundaries preserve coherent evidence relative to fixed windows.

• We introduce LycheeMemory, a semantic segment-level memory construction framework that encodes each finalized segment into typed, self-contained records. Bounded cross-segment context maintains entity and reference continuity despite less frequent consolidation.

• We demonstrate a stronger accuracy–cost trade-off on LoCoMo and LongMemEval-S, improving long-term memory QA accuracy while reducing construction-token cost and query-time token usage relative to A-Mem. Ablations further distinguish the cost effect of segment-level batching from the accuracy effect of semantic boundary selection.

2 Related Work

2.1 Long-Term Memory for LLM Agents

Long-term memory has become a central component of LLM agents that must operate across sessions rather than within a single context window. Early systems (31; 24; 21) introduced external memory to preserve user facts, preferences, and historical context, thereby moving from stateless response generation toward persistent assistance. More recent frameworks broaden this agenda by separating different forms of memory or by coupling memory with agent control. For example, MemoryOS (12) and A-Mem (29) emphasize richer memory abstractions and organization, while G-Long (6) and HORMA (8) connect memory with more structured reasoning or navigation mechanisms. In parallel, benchmarks such as LoCoMo (20) and LongMemEval (28) clarify that long-term memory quality depends not only on whether information is retained, but also on whether it can be reconstructed and used under long-horizon budget constraints.

Taken together, this literature suggests that long-term memory systems are increasingly differentiated along three technical axes: how memories are constructed from interaction streams, how they are organized and retrieved for downstream reasoning, and how cost is controlled during long-horizon use. We organize the remainder of this section around these three axes.

2.2 Memory Construction for LLM Agents

A dominant line of work constructs memory eagerly from incoming dialogue. Mem0 (5) extracts and updates memories at turn granularity, while A-Mem (29) enriches this pattern with linked notes and more structured memory units. MemoryOS (12) and related frameworks (22; 27) introduce stronger memory hierarchies or management policies, but still rely on LLM-mediated ingestion or summarization as new dialogue arrives. The common strength of this family is semantic richness at write time; its main drawback is that memory construction remains a frequent LLM operation.

A second line of work reduces write-side cost after or around this basic pipeline. MemRefine (13) treats compression as a post-construction decision problem, using the LLM to delete, merge, or preserve entries under a budget. DMF (26) removes LLM calls from memory management through deterministic scoring and decay, trading semantic flexibility for lower and more reproducible cost. MemRouter (9) makes a different trade-off by learning an embedding-based admission policy that decides whether a new interaction should enter memory. These methods show that construction can be made cheaper in different ways, but most of them either optimize memory after frequent writes have already been produced or make storage decisions at relatively fine temporal granularity.

Recent systems have also explored segment-level memory construction. SeCom (25) partitions conversations into topically coherent segments and compresses them before retrieval, while HiMem (30) uses topic-aware event-surprise segmentation to construct episode memories within a hierarchical memory architecture.

LycheeMemory shares this segment-level construction granularity but focuses specifically on online write-side efficiency. It uses embedding-based boundary decisions as a construction trigger, allowing multiple exchanges to share one encoding call instead of producing separate turn-level updates. Semantic boundary detection determines the composition of each batch, while bounded cross-segment disambiguation supports the construction of self-contained records.

2.3 Memory Organization and Retrieval

Once memory has been written, the next challenge is how to retrieve the right evidence for complex reasoning. Many early systems (31; 21; 5) expose memory primarily through flat semantic retrieval over summaries, notes, or profile-like records. This design works well for direct factual lookup, but it is less well aligned with questions that depend on temporal constraints, multi-hop relations, or comparisons across episodes (20; 28), where entity identity, topical scope, and temporal validity must be handled explicitly.

A substantial body of work addresses this problem by adding structure to the memory store itself. G-Long (6) and REAL (19) organize memory through structured relations or graph-like representations, while hierarchical or workspace-style systems such as HORMA (8), MAGE (4), and Infini-Memory (10) support reasoning across multiple granularities. These methods show that richer structure can improve long-horizon retrieval, especially when evidence must be composed rather than directly matched. At the same time, the amount of extra indexing, maintenance, or traversal machinery varies substantially across systems, so the trade-off is better characterized as additional structural complexity rather than a uniform cost increase.

Another line of work improves retrieval through more explicit query-time control. EviMem (17) retrieves evidence iteratively based on missing information, MemFlow (3) routes a query to different memory operations, and MemReranker (14) shows that reasoning-aware reranking can substantially improve final evidence quality. These approaches make clear that long-term memory retrieval is often operation-aware rather than single-shot. LycheeMemory is closest in spirit to this structured and routed line, but it emphasizes a lighter query-time design: it uses one planning step to dispatch recall over pre-built indices instead of relying on iterative retrieval loops.

2.4 Efficient Memory Systems

Recent memory research increasingly treats efficiency as a primary objective rather than a secondary implementation concern. EMBER (16) studies budgeted evidence retention, asking which information should remain available under a fixed memory budget. ActiveMem (11) reduces the burden on the main model by offloading memory distillation to lighter components, while LightMem (7) develops a lightweight memory-augmented generation pipeline. ScrapMem (2) focuses on storage-constrained multimodal personalization, while Memanto (1) argues that some graph-plus-vector memory designs impose avoidable infrastructure and latency overheads. DMF (26) and MemRouter (9) similarly illustrate that large efficiency gains are possible when parts of memory management are replaced by deterministic or lightweight policies.

This literature establishes an important evaluation principle: memory systems should be compared not only by answer quality but also by their token, latency, and storage footprints. LycheeMemory belongs to this efficiency-oriented line, but its emphasis is narrower and more specific. Its main focus is construction-time token cost, and its key distinction is to reduce that cost by lowering the frequency of semantic consolidation rather than primarily by compressing stored memory or simplifying retrieval infrastructure.

3 Method

3.1 Overview

We formulate long-term agent memory as an online construction and retrieval problem. Given a multi-session conversation stream $𝒞=\{x_1,\dots ,x_T\}$, where each exchange $x_t$ contains a user message and the corresponding assistant response, the system incrementally builds a memory store $ℳ$ and later retrieves evidence for a query $q$. The objective is to maximize answer accuracy while controlling both construction cost, measured by total LLM tokens used during memory building, and query cost, measured by LLM tokens consumed per question.

LycheeMemory replaces turn-level consolidation with semantic segment-level consolidation. Instead of invoking an LLM after every exchange, it buffers multiple exchanges and performs one encoding pass per finalized segment. This segment-level batching reduces construction frequency. A semantic boundary detector separately determines which exchanges belong to each segment so that the batching policy follows conversational structure rather than fixed windows. Each segment is converted into typed, context-independent memory records, enriched with entities, topics, temporal scopes, and provenance links. The records are stored in an append-only evidence store with semantic retrieval and structured indexes for entity, topic, temporal, event-frame, and entity-topic access. At query time, a planner decomposes the question into typed recall routes, and deterministic retrieval modules collect, fuse, and select evidence from the indexed memory store.

Figure 3 provides an overview of LycheeMemory, which consists of a construction phase and a retrieval phase. During construction, online semantic segmentation groups the conversation stream into coherent segments and triggers segment-level encoding only when a segment is finalized. The encoded records are then inserted into an append-only store and exposed through structured evidence indexes. During retrieval, the query planner converts the current question into typed recall routes, and the retrieved candidates are fused into a compact evidence context for answer generation. Section 3.2 describes online segmentation, Section 3.3 defines segment-level record construction, Section 3.4 presents structured evidence organization, and Section 3.5 describes plan-guided retrieval. Algorithmic descriptions are provided in Appendix B.

3.2 Online Semantic Segmentation

The first component decides when a dialogue fragment is sufficiently complete to be consolidated. Turn-level eager consolidation is costly because it applies the same LLM encoding operation to every exchange, including exchanges that are still part of an unfinished semantic episode. Batching multiple exchanges into one segment reduces this call frequency. Fixed windows provide such batching mechanically, but they ignore event boundaries and may split temporally or referentially coherent evidence. We therefore use online semantic segmentation as the boundary policy within segment-level batching, triggering consolidation when the active segment becomes semantically saturated or a topic transition is detected.

Let $S_k=\{x_s,\dots ,x_{t-1}\}$ denote the current active segment before observing a new exchange $x_t$. We encode each exchange into an embedding vector ${𝐞}_t$, maintain the segment centroid ${𝐜}_k$, and keep the most recent exchange embedding ${𝐡}_k$. The semantic surprise score $s_t$ is defined as

$s_t=1-\max (\mathrm{sim}({𝐞}_t,{𝐜}_k),\mathrm{sim}({𝐞}_t,{𝐡}_k)),$

(1)

where $\mathrm{sim}(\cdot ,\cdot )$ is cosine similarity. This score captures whether the new exchange departs from both the global topic of the active segment and the local conversational trajectory.

We also measure how much the new exchange weakens internal segment coherence. For a set of exchange embeddings $V$, let

$\mathrm{Coh}\left(V\right)=\frac{1}{\left|V\right|}\sum _{𝐯\in V}\mathrm{sim}(𝐯,{𝐜}_V),$

(2)

where ${𝐜}_V$ is the centroid of $V$. The cohesion drop $d_t$ induced by $x_t$ is

$d_t=\max (0,\mathrm{Coh}\left(S_k\right)-\mathrm{Coh}\left(S_k\cup \left\{x_t\right\}\right)).$

(3)

A larger drop indicates that adding the exchange would make the segment less topically coherent.

The final boundary score combines semantic surprise, cohesion drop, token pressure, and turn-count pressure:

$p_t=\sigma \left(b+w_s\varphi \left(s_t\right)+w_c{d}_t+w_l{L}_t+w_n{N}_t\right),$

(4)

where $\varphi (\cdot )$ applies local normalization to semantic surprise, $L_t$ is the normalized token-length pressure, and $N_t$ is the normalized turn-count pressure. A segment is finalized when $p_t$ exceeds a fixed threshold $\delta$ or a hard token cap is reached; otherwise, $x_t$ is appended to the active segment. This design keeps the boundary decision fully embedding-based, so mid-segment exchanges are buffered without LLM inference. The reduction in encoding calls comes from consolidating at segment rather than exchange granularity: the number of calls is proportional to the number of segments $\left|𝒮\right|$ rather than the number of exchanges $T$. The semantic boundary score determines the composition of those segments.

3.3 Segment-Level Memory Encoding

The second component converts each finalized segment into memory records that can be retrieved and interpreted without the original dialogue context. Raw turns often contain pronouns, elliptical references, relative dates, and implicit entity mentions. If such turns are stored directly, later retrieval must recover missing context at query time. LycheeMemory instead resolves these dependencies at write time within a coherent segment, where the necessary local context is still available.

For a finalized segment $S_k$, the encoder receives the segment text together with a compact reference context ${\rho }_k$ from recent segments. It produces a set of memory records ${ℛ}_k$ and an updated disambiguation state $d_k$:

$({ℛ}_k,d_k)=\mathrm{Encode}(S_k,{\rho }_k).$

(5)

The encoding prompt asks the LLM to perform three operations in a single pass: extract atomic information units, resolve coreference and elliptical mentions, and normalize relative temporal expressions using the session timestamp.

Each record $r_i\in {ℛ}_k$ is represented as

$r_i=({\mathrm{id}}_i,{\tau }_i,{\mathrm{text}}_i,{ℰ}_i,{𝒦}_i,{𝒯}_i,{\mathrm{src}}_i),$

(6)

where ${\mathrm{id}}_i$ is an internal record identifier, ${\tau }_i$ is the memory type, ${\mathrm{text}}_i$ is a self-contained natural-language statement, ${ℰ}_i$ is the entity set, ${𝒦}_i$ is the topic-tag set, ${𝒯}_i$ records normalized event or validity times when available, and ${\mathrm{src}}_i$ stores provenance links to the source turns. The memory type ${\tau }_i$ is selected from a finite schema covering facts, preferences, events, constraints, procedures, failure patterns, and tool affordances.

To preserve continuity across segment boundaries, the encoder also returns a disambiguation state $d_k$ containing resolved aliases, canonical entity names, and reference relations that may be needed by later segments. The reference context for the next segment is constructed as

${\rho }_{k+1}=[d_k;\mathrm{Recent}\left({ℛ}_{k-m:k}\right)],$

(7)

where $\mathrm{Recent}(\cdot )$ selects a bounded set of recent record summaries from the same session. This context is truncated to a fixed budget, which prevents the prompt size from growing with the full conversation history. The result is a sequence of records that are locally self-contained while remaining consistent across segments.

3.4 Structured Evidence Organization

The third component organizes encoded records so that retrieval can satisfy both semantic and structured constraints. Flat vector search is effective for approximate semantic matching, but long-term memory questions often require explicit access by entity, topic, time, event context, or combinations of these fields. LycheeMemory therefore builds structured evidence indexes directly from the metadata already produced by the segment encoder, without additional LLM calls.

For each record $r_i$, the organizer inserts the record into a vector store and updates a structured store. The vector store embeds ${\mathrm{text}}_i$ for direct semantic retrieval. The structured store maintains five classes of evidence nodes:

• entity nodes, one for each entity in ${ℰ}_i$;

• topic nodes, one for each topic tag in ${𝒦}_i$;

• entity-topic nodes, one for each co-occurring pair $(e,k)\in {ℰ}_i\times {𝒦}_i$;

• temporal nodes, keyed by day-level or month-level temporal scopes in ${𝒯}_i$;

• event-frame nodes, each grouping the records produced from the same finalized semantic segment while retaining the source session and turn range as provenance.

Each evidence node stores a searchable text representation, an optional embedding, and pointers to linked memory records.

The structured store retains textually distinct statements as separate records. Direct record search retrieves records by semantic similarity, while evidence-node search retrieves or filters structured nodes and expands them to linked records. Temporal nodes support exact-date and range-based filtering, and event-frame nodes preserve local co-occurrence among records extracted from the same finalized segment. Evidence distributed across segments or sessions is assembled later by retrieving and fusing records from multiple evidence nodes and recall routes. Because all nodes are derived from record metadata, this phase requires only embedding and bookkeeping operations, and the write-side LLM cost remains dominated by segment-level encoding.

3.5 Plan-Guided Multi-Route Retrieval

The final component retrieves evidence for a query using one planning step followed by deterministic recall. Long-term memory questions are often heterogeneous: a temporal question may require date filtering, a multi-hop question may require evidence from multiple entities, and a preference question may require stable user facts rather than recent events. A single embedding query cannot express these distinct evidence requirements. Iterative LLM retrieval can address the issue, but it increases query-time token cost. LycheeMemory separates query understanding from evidence collection: the LLM is used once to specify recall routes, while the subsequent retrieval operations are non-generative.

Given a query $q$ and recent dialogue context $H_q$, the planner outputs a structured plan

$\Pi (q,H_q)=(y,\{R_1,\dots ,R_m\}),$

(8)

where $y$ is the question type and each route $R_j=(g_j,Q_j,C_j,T_j)$ contains a route goal, one or more search queries, structured constraints, and optional temporal constraints. The question type selects retrieval parameters such as channel weights, per-channel candidate limits, and expansion depth.

Each route executes four recall channels in parallel. Direct record recall searches the record vector store using route-specific search queries. Evidence-node recall searches entity, topic, entity-topic, and event-frame nodes, then expands matched nodes to their linked records. Temporal recall applies exact date or range constraints over temporal nodes. Raw-turn recall searches verbatim dialogue embeddings to recover evidence that may not have been consolidated into typed records. Each candidate receives channel-specific scores and retains its provenance.

Candidates from all routes are merged with reciprocal-rank fusion:

$\mathrm{RRF}\left(d\right)=\sum _{j=1}^m\frac{1}{\kappa +{\mathrm{rank}}_j\left(d\right)},$

(9)

where ${\mathrm{rank}}_j\left(d\right)$ is the rank of candidate $d$ under route $R_j$ and $\kappa$ is a smoothing constant. Candidates are optionally reranked by a lightweight cross-encoder within each route before route-level lists are fused. The fused candidates are then passed through diversity-aware selection so that evidence from different routes is preserved. The selected records and raw-turn snippets are serialized with their memory types, temporal scopes, and provenance metadata to form the final context for answer generation. When retrieved evidence conflicts, the answer model is instructed to prefer the most recent supported information.

This retrieval design provides structured evidence coverage while bounding generative token usage. The only generative query-time operation is the planning call. All subsequent recall, expansion, reranking, fusion, and selection steps are embedding lookups, structured filtering, or arithmetic scoring.

4 Experiments

4.1 Experimental Setup

Datasets.

We evaluate LycheeMemory on two long-term conversational memory benchmarks that cover different interaction patterns. LoCoMo (20) focuses on companion-style casual sharing scenarios, comprising 10 multi-session conversations (averaging $\phantom{}\sim 600$ turns, $\phantom{}\sim 16$K tokens) with 1,986 question-answer pairs in total. Following the standard long-term memory QA setting, we retain 1,540 questions from the single-hop, multi-hop, temporal-reasoning, and open-domain categories to test whether memory systems can recover fine-grained evidence from cross-session history. LongMemEval-S (28) focuses on agent-style task-oriented interactions with significantly longer dialogue contexts (500 conversations, averaging $\phantom{}\sim 115$K tokens), covering six categories: user facts, assistant facts, preference tracking, multi-session reasoning, knowledge update, and temporal reasoning, posing stricter challenges for memory construction and retrieval under long-term high-load scenarios. Together, these benchmarks cover the core scenario we address: dialogue history grows continuously, and systems must preserve usable evidence under limited construction and query budgets. Detailed benchmark composition is provided in Appendix A.1.

Baselines.

We compare against baselines covering different design directions. Full Context places the entire dialogue history directly into the LLM context window, serving as a direct long-context reference without external memory. Naive RAG chunks the conversation and retrieves via embedding similarity, representing standard retrieval-augmented approaches. Among dedicated long-term memory systems, Mem0 (5) invokes the LLM after each turn for fact extraction and update, representing the standard eager consolidation paradigm; A-Mem (29) extends this with Zettelkasten-style linked notes and dynamic memory evolution, representing an agentic memory design with linked and evolving records; MemoryOS (12) employs an OS-inspired layered memory architecture (short-term / mid-term / long-term persona modules), representing more complex memory organization directions. Additionally, we compare with MemOS (18), Nemori (22), LightMem (7), and TiMem (15) on both benchmarks, and with MemU (23) on LoCoMo.

Implementation.

We evaluate LycheeMemory using GPT-4.1-Mini and GPT-4o-Mini as backbones. Each backbone is used throughout the pipeline for memory encoding, query planning, and final answer generation, with temperature set to 0. Embeddings are computed with text-embedding-3-small, and retrieval-side reranking uses bge-reranker-v2-m3. Additional implementation and prompt details are provided in Appendices C and F.

Answer and judge protocol.

Within each backbone setting, all methods use the same benchmark split and judge protocol. For LycheeMemory, the selected backbone is also used for memory encoding and query planning. Outputs in both settings are evaluated by GPT-4o-Mini using benchmark-specific judge prompts. On LoCoMo, the judge receives the question, gold answer, and generated answer and accepts semantically equivalent phrasings; category accuracy is computed within each retained question type, and overall accuracy over all 1,540 retained questions. On LongMemEval-S, we use the official task-specific yes/no judge with a 10-token output cap. Preference questions use rubric-style desired responses. For knowledge-update questions, the judge accepts the updated answer even if previous information is also mentioned; for temporal-reasoning questions, it applies the official duration tolerance. Judge calls are excluded from all token counts.

Metrics.

We report overall accuracy and fine-grained category accuracy following each benchmark’s official categorization. Overall accuracy is a micro-average over the valid evaluation set: 1,540 retained questions for LoCoMo and 500 questions for LongMemEval-S, with no additional filtering. Compared with lexical overlap metrics such as F1 and BLEU-1, the LLM judge more directly assesses semantic correctness in open-ended generation. Lexical overlap can underestimate semantically correct answers that differ in phrasing and overestimate answers that share surrounding words but contain an incorrect critical fact.

Token accounting.

For the efficiency analysis, we use GPT-4.1-Mini and count construction and query tokens as the sum of generative LLM input and output tokens. For every method, construction tokens cover all generative memory-building calls, whereas query tokens cover final answer generation and any method-specific query-time generative operations. For LycheeMemory, construction tokens comprise the segment-encoding prompt, finalized segment text, reference/disambiguation context, memory-record output, and disambiguation-state output; query tokens comprise the query-planner and final answer-generation input/output, including serialized evidence and recent dialogue context. Embedding computation, deterministic indexing, retrieval and filtering, reciprocal-rank fusion, non-generative reranking, diversity-aware selection, and judge calls are excluded; final answer generation is excluded from construction but included in query cost. Construction cost is averaged per conversation or conversation-question instance, query cost per question, and both are reported in thousands (K). Reporting both quantities separates write-side from query-side cost and reveals whether gains merely shift computation between stages.

4.2 Main Results

媒体内容 · 前往原文查看

Backbone	Method	Single Hop	Multi Hop	Temporal	Open Domain	Overall
GPT-4.1-Mini	Full Context	90.84	82.62	79.13	57.29	84.80
	Naive RAG	61.24	58.87	33.96	50.00	54.42
	MemOS	85.37	79.43	75.08	64.58	80.84
	MemU	74.91	72.34	43.61	54.17	66.62
	MemoryOS	77.05	66.31	47.66	55.21	67.60
	Mem0	66.23	58.16	63.86	44.79	62.92
	A-Mem	73.25	59.93	72.90	42.71	68.83
	Nemori	84.90	75.10	77.60	51.00	79.40
	LightMem	81.57	62.77	64.17	54.17	72.79
	TiMem	87.99	78.37	84.74	59.38	83.77
	LycheeMemory	93.34	87.23	86.60	67.71	89.22
GPT-4o-Mini	Full Context	90.01	69.86	52.96	55.21	76.43
	Naive RAG	57.55	54.61	24.30	51.04	49.68
	MemOS	81.45	69.15	72.27	60.42	75.97
	MemU	72.77	62.41	33.96	46.88	61.17
	MemoryOS	74.55	58.87	44.24	46.88	63.64
	Mem0	65.52	52.84	52.02	37.50	58.64
	A-Mem	66.83	52.13	61.99	30.21	60.84
	Nemori	82.10	65.30	71.00	44.80	74.40
	LightMem	76.61	67.02	76.32	45.83	72.87
	TiMem	81.43	62.20	77.63	52.08	75.30
	LycheeMemory	84.90	68.09	80.06	54.17	78.90

媒体内容 · 前往原文查看

Backbone	Method	SSU	SSA	SSP	MS	KU	TR	Overall
GPT-4.1-Mini	Full Context	91.43	100.00	56.67	53.38	75.64	48.12	66.20
	Naive RAG	85.71	82.36	83.33	63.91	75.64	45.86	67.20
	MemOS	90.00	64.29	50.00	54.14	70.51	63.91	65.20
	MemoryOS	94.29	89.29	100.00	67.67	80.77	54.89	74.40
	Mem0	95.71	50.00	90.00	69.92	74.36	62.41	71.20
	A-Mem	95.71	100.00	63.33	61.65	82.05	52.63	71.60
	Nemori	90.00	92.90	86.70	55.60	79.50	72.20	74.60
	LightMem	90.00	23.21	76.67	51.13	88.46	84.21	69.60
	TiMem	92.86	78.57	73.33	66.92	79.49	72.93	75.80
	LycheeMemory	100.00	98.21	90.00	87.97	97.44	87.22	92.20
GPT-4o-Mini	Full Context	44.29	80.36	53.33	35.34	55.13	34.59	45.60
	Naive RAG	85.71	83.93	46.67	52.63	65.38	41.35	59.40
	MemOS	95.71	67.86	96.67	70.67	74.26	77.44	77.80
	MemoryOS	97.14	89.29	70.00	58.65	73.08	48.87	67.80
	Mem0	95.71	55.36	70.00	57.89	69.23	54.14	64.40
	A-Mem	92.54	98.21	36.67	53.38	70.51	44.36	63.20
	Nemori	88.60	83.90	46.70	51.10	61.50	61.70	64.20
	LightMem	87.14	32.14	68.18	71.74	83.12	67.18	69.81
	TiMem	95.71	82.14	63.33	70.83	86.16	68.42	76.88
	LycheeMemory	97.14	96.43	70.00	72.93	74.36	72.18	78.80

Tables 1 and 2 show that LycheeMemory achieves the highest overall accuracy on both benchmarks with either backbone. LycheeMemory reaches 89.22% on LoCoMo and 92.20% on LongMemEval-S with GPT-4.1-Mini, compared with 84.80% for Full Context and 75.80% for TiMem, the strongest baselines on the respective benchmarks. The corresponding results with GPT-4o-Mini are 78.90% and 78.80%, improving over the strongest baselines by 2.47 and 1.00 percentage points. Section 4.3 further compares the accuracy and token costs of MemoryOS, Mem0, A-Mem, TiMem, and LycheeMemory using GPT-4.1-Mini. The consistent gains across both benchmarks indicate that LycheeMemory remains effective with either backbone and across different interaction lengths.

LoCoMo.

On LoCoMo, LycheeMemory’s largest gains over A-Mem with GPT-4.1-Mini appear in multi-hop reasoning (87.23% vs. 59.93%, +27.3 pp) and open-domain questions (67.71% vs. 42.71%, +25.0 pp). It also reaches 93.34% on single-hop questions, +20.1 pp above A-Mem (73.25%). On temporal reasoning, LycheeMemory reaches 86.60%, +13.7 pp above A-Mem (72.90%) and +38.9 pp above MemoryOS (47.66%). LycheeMemory achieves 78.90% overall with GPT-4o-Mini, 18.06 pp above A-Mem and 2.47 pp above Full Context, together with 80.06% on temporal reasoning. These gains show that LycheeMemory remains effective across direct recall, evidence composition, temporal reasoning, and open-ended questions; Section 4.4 further examines the corresponding design choices. Full Context remains competitive on LoCoMo, but with either backbone, its accuracy decreases on the substantially longer conversations in Table 2.

LongMemEval-S.

On LongMemEval-S, LycheeMemory’s three largest gains over A-Mem with GPT-4.1-Mini occur in temporal reasoning (87.22% vs. 52.63%, +34.59 pp), preference tracking (90.00% vs. 63.33%, +26.67 pp), and multi-session reasoning (87.97% vs. 61.65%, +26.32 pp). It also reaches 97.44% on knowledge-update questions, compared with 82.05% for A-Mem, showing that the pipeline can recover updated evidence from the retained history under the benchmark’s answer-level criterion (28). On single-session user and assistant facts, LycheeMemory reaches 100.00% and 98.21%, respectively. LycheeMemory achieves the highest overall accuracy of 78.80% with GPT-4o-Mini, 1.00 pp above MemOS, together with the highest multi-session score (72.93%) and a tied best result on single-session user facts (97.14%). These results show consistent gains across temporal, preference-intensive, and cross-session evidence needs with both models. MemoryOS reaches 100.00% on preference tracking with GPT-4.1-Mini, higher than LycheeMemory’s 90.00%, suggesting that dedicated user-profile modules may provide advantages for preference-intensive queries.

4.3 Accuracy-Cost Trade-off

Using GPT-4.1-Mini, we next examine whether the accuracy gains require higher write- or query-side token consumption. Figure 4 visualizes the trade-off, while the discussion below reports the key exact values.

媒体内容 · 前往原文查看

Construction cost.

On LoCoMo, LycheeMemory uses only 204.1K construction tokens, 86.0% and 86.6% lower than A-Mem’s 1459.9K and Mem0’s 1520.8K respectively, and 58.3% lower than TiMem’s 489.5K. On LongMemEval-S, LycheeMemory uses 304.7K, 75.9% lower than A-Mem’s 1264.3K and 50.9% lower than TiMem’s 620.9K. Construction savings come from segment-level batching: it reduces LLM encoding calls from $T$ (one per turn) to $\left|𝒮\right|$ (one per segment, averaging 5.8 turns per segment on LoCoMo), while each call processes multiple exchanges rather than an individual turn. Semantic boundary detection determines which exchanges are batched together; its contribution relative to fixed-window batching is evaluated separately in Section 4.4.

Query cost.

Despite substantial accuracy gains, LycheeMemory’s query tokens do not increase. On LoCoMo, LycheeMemory uses 4.01K query tokens, lower than A-Mem’s 5.56K (-27.9%) and TiMem’s 10.71K (-62.6%). On LongMemEval-S, it uses 8.88K, lower than A-Mem’s 15.46K (-42.6%) and TiMem’s 11.36K (-21.8%). This indicates that LycheeMemory’s accuracy gains do not come from expanding query-time context or adding multi-step LLM reasoning. Its retrieval pipeline requires only one LLM planning call; the remaining recall, scoring, fusion, and selection operations are embedding lookups and arithmetic computations that consume no generative tokens.

Overall trade-off.

Taken together, LycheeMemory simultaneously improves accuracy and reduces both construction and query token consumption relative to A-Mem and TiMem. Mem0 has the lowest query tokens but also the lowest accuracy, while MemoryOS has relatively low construction cost but accuracy still falls far below LycheeMemory. Overall, LycheeMemory provides a stronger trade-off among accuracy, construction cost, and query-time overhead.

4.4 Ablation Study

Unless otherwise stated, all ablation experiments are conducted on LoCoMo using GPT-4.1-Mini. We assess the contributions of major design choices and component groups to the accuracy-cost trade-off following the system pipeline: construction triggering (Table 3), memory representation and cross-segment continuity (Table 4), and query-time retrieval (Table 5). We further vary the boundary threshold used by online semantic segmentation to assess parameter sensitivity (Figure 5). Detailed variant definitions are provided in Appendix E.

媒体内容 · 前往原文查看

Variant	Overall	Single	Multi	Temp.	Open	Const. $\downarrow$
Full LycheeMemory	89.22	93.34	87.23	86.60	67.71	204.1
eager cons.	81.88	87.16	74.47	81.31	59.38	849.9
fixed-window cons.	82.40	90.49	74.82	75.70	56.25	174.7

Construction triggering.

Replacing segment-level batching with eager construction causes accuracy to drop from 89.22% to 81.88% (-7.3 pp) while construction tokens increase from 204.1K to 849.9K (+316%). Fixed-window consolidation retains batching and uses slightly fewer construction tokens than the full system (174.7K vs. 204.1K), but its accuracy drops to 82.40% (-6.8 pp), with the largest losses on multi-hop (87.23% $\to$ 74.82%) and open-domain questions (67.71% $\to$ 56.25%). Together, these comparisons show that batching reduces construction cost, while semantic boundary detection improves accuracy relative to mechanical windows.

媒体内容 · 前往原文查看

Variant	Overall	Single	Multi	Temp.	Open	Const. $\downarrow$
Full LycheeMemory	89.22	93.34	87.23	86.60	67.71	204.1
summary records	80.78	88.35	74.47	73.83	56.25	99.7
w/o cross-seg. context	81.56	87.87	75.18	76.95	60.42	189.6

媒体内容 · 前往原文查看

Variant	Overall	Single	Multi	Temp.	Open	Query $\downarrow$
Full LycheeMemory	89.22	93.34	87.23	86.60	67.71	4.01
record-vector only	81.75	88.23	76.60	78.19	52.08	4.09
w/o query planner	83.38	90.01	79.08	78.50	54.17	2.26
w/o fusion/rerank/div	66.62	71.34	60.64	66.04	44.79	3.35

Memory representation.

Replacing typed, self-contained records with summary-level records reduces construction tokens to 99.7K, while accuracy drops to 80.78% (-8.4 pp) and temporal reasoning falls from 86.60% to 73.83% (-12.8 pp). This comparison shows higher accuracy for structured records than for summary-level memory. Removing cross-segment reference context leaves construction tokens nearly unchanged (189.6K vs. 204.1K) but reduces accuracy to 81.56% (-7.7 pp), showing the contribution of cross-segment continuity to the representation configuration.

Retrieval pipeline.

Using record-vector retrieval only, query tokens remain comparable to the full system (4.09K vs. 4.01K) but accuracy drops to 81.75% (-7.5 pp), showing the combined effect of entity, topic, temporal, event-frame, and raw-turn recall. Removing the query planner reduces query tokens to 2.26K but accuracy drops to 83.38% (-5.8 pp), exposing a trade-off between the planning call and QA accuracy. Jointly disabling fusion, reranking, and diversity-aware selection reduces accuracy from 89.22% to 66.62% (-22.6 pp), showing the contribution of the combined evidence-selection stack.

Boundary-threshold sensitivity.

To assess the stability of online semantic segmentation with respect to its cut criterion, we vary the threshold $\delta$ applied to the boundary probability $p_t$ from 0.30 to 0.70 on the same LoCoMo evaluation set while keeping all other settings fixed. As shown in Figure 5, overall accuracy ranges from 88.18% to 89.22%, a total variation of 1.04 percentage points. The default threshold of 0.50 achieves the highest accuracy; the neighboring settings of 0.40 and 0.60 remain within 0.39 and 0.58 percentage points of the default, respectively. These results show limited sensitivity to the boundary threshold within the evaluated range.

媒体内容 · 前往原文查看

Summary.

Overall, removing or replacing the proposed construction, representation, and retrieval components produces substantial accuracy losses or cost increases, whereas accuracy remains stable across the evaluated values of $\delta$. This contrast indicates that the observed gains arise from the system design rather than a narrowly tuned boundary threshold.

5 Conclusion

We introduced LycheeMemory, a cost-efficient long-term memory framework for LLM agents that replaces turn-level consolidation with semantic segment-level consolidation. Segment-level batching reduces construction frequency, while semantic boundary detection determines coherent segment composition before each segment is encoded into context-independent typed records. Together with lightweight cross-segment disambiguation, structured evidence indexes, and query-planned multi-route recall, this design preserves fine-grained conversational evidence while avoiding unnecessary construction and query-time overhead. Experiments on LoCoMo and LongMemEval-S demonstrate that this design improves long-term memory QA and yields a stronger accuracy–cost trade-off than representative memory baselines. Future work will extend this segment-level evidence construction paradigm beyond text-only conversational QA toward multimodal memories, richer preference modeling, and deployment-oriented memory governance.

References

• Abtahi et al. (2026) S. M. Abtahi, R. Rahnema, H. Patel, N. Patel, M. Fekri, and T. Khani Memanto: typed semantic memory with information-theoretic retrieval for long-horizon agents. External Links: 2604.22085, Link Cited by: §2.4.
• Chang and Ren (2026) J. Chang and Y. Ren ScrapMem: a bio-inspired framework for on-device personalized agent memory via optical forgetting. External Links: 2605.03804, Link Cited by: §2.4.
• Chen et al. (2026a) J. Chen, Y. Li, and G. Wang MemFlow: intent-driven memory orchestration for small language model agents. External Links: 2605.03312, Link Cited by: §1, §2.3.
• Chen et al. (2026b) Y. Chen, H. Lai, Y. Feng, C. Han, Q. Zhang, B. Lu, M. Li, X. Wang, Z. Wang, S. Xu, Z. Li, Z. Jin, H. Wu, C. Li, and Q. Chen Beyond semantic organization: memory as execution state management for long-horizon agents. External Links: 2606.06090, Link Cited by: §2.3.
• Chhikara et al. (2025) P. Chhikara, D. Khant, S. Aryan, T. Singh, and D. Yadav Mem0: building production-ready AI agents with scalable long-term memory. CoRR abs/2504.19413. Cited by: §1, §1, §2.2, §2.3, §4.1.
• Choi et al. (2026) M. Choi, Y. Jang, S. Youn, and Y. Ko G-long: graph-enhanced memory management for efficient long-term dialogue agents. External Links: 2606.13115, Link Cited by: §1, §1, §2.1, §2.3.
• Fang et al. (2025) J. Fang, X. Deng, H. Xu, Z. Jiang, Y. Tang, Z. Xu, S. Deng, Y. Yao, M. Wang, S. Qiao, H. Chen, and N. Zhang LightMem: lightweight and efficient memory-augmented generation. CoRR abs/2510.18866. Cited by: §2.4, §4.1.
• Hsu et al. (2026) H. Hsu, N. L. Kuang, B. Liu, Z. Yao, and Y. He Organize then retrieve: hierarchical memory navigation for efficient agents. External Links: 2606.11680, Link Cited by: §1, §1, §2.1, §2.3.
• Hu et al. (2026) T. Hu, W. Lin, W. Zhang, J. Ma, and S. Wang MemRouter: memory-as-embedding routing for long-term conversational agents. External Links: 2605.00356, Link Cited by: §1, §2.2, §2.4.
• Ji et al. (2026) S. Ji, B. Wu, Z. Wang, L. Xia, Q. Li, R. Wang, W. Ding, Z. Zhu, B. Li, G. Dai, and Y. Wang Infini memory: maintainable topic documents for long-term llm agent memory. External Links: 2606.10677, Link Cited by: §2.3.
• Jiang et al. (2026) Y. Jiang, W. Duan, S. Guo, L. Pang, X. Sun, and H. Shen ActiveMem: distributed active memory for long-horizon llm reasoning. External Links: 2606.10532, Link Cited by: §2.4.
• Kang et al. (2025) J. Kang, M. Ji, Z. Zhao, and T. Bai Memory OS of AI agent. CoRR abs/2506.06326. Cited by: §1, §2.1, §2.2, §4.1.
• Kim et al. (2026) M. Kim, J. Baek, S. Jeong, and S. J. Hwang MemRefine: llm-guided compression for long-term agent memory. External Links: 2606.13177, Link Cited by: §1, §2.2.
• Li et al. (2026a) C. Li, M. Zhang, J. Kang, D. Chen, J. Shen, B. Tang, X. Zhou, F. Xiong, and Z. Li MemReranker: reasoning-aware reranking for agent memory retrieval. External Links: 2605.06132, Link Cited by: §1, §2.3.
• Li et al. (2026b) K. Li, X. Yu, Z. Ni, Y. Zeng, Y. Xu, Z. Zhang, X. Li, J. Sang, X. Duan, X. Wang, C. Liu, and J. Tan TiMem: temporal-hierarchical memory consolidation for long-horizon conversational agents. External Links: 2601.02845, Link Cited by: §4.1.
• Li et al. (2026c) Y. Li, S. Banerjee, and T. Che EMBER: efficient memory via budgeted evidence retention for long-horizon agents. External Links: 2606.05894, Link Cited by: §1, §2.4.
• Li et al. (2026d) Y. Li, Y. He, Z. Zhang, and D. Gong EviMem: evidence-gap-driven iterative retrieval for long-term conversational memory. External Links: 2604.27695, Link Cited by: §1, §2.3.
• Li et al. (2025) Z. Li, S. Song, H. Wang, S. Niu, D. Chen, J. Yang, C. Xi, H. Lai, J. Zhao, Y. Wang, J. Ren, Z. Lin, J. Huo, T. Chen, K. Chen, K. Li, Z. Yin, Q. Yu, B. Tang, H. Yang, Z. J. Xu, and F. Xiong MemOS: an operating system for memory-augmented generation (MAG) in large language models. CoRR abs/2505.22101. External Links: Link Cited by: §4.1.
• Lu et al. (2026) K. Lu, L. Chen, G. Jiang, Z. Qin, Y. Liu, and W. Zhang REAL: a reasoning-enhanced graph framework for long-term memory management of llms. External Links: 2606.10694 Cited by: §2.3.
• Maharana et al. (2024) A. Maharana, D. Lee, S. Tulyakov, M. Bansal, F. Barbieri, and Y. Fang Evaluating very long-term conversational memory of llm agents. External Links: 2402.17753, Link Cited by: §A.1.1, §1, §1, §1, §2.1, §2.3, §4.1.
• Memobase, Inc. (2025) Memobase, Inc. Memobase: user profile-based long-term memory for ai chatbot applications.. GitHub. Note: https://github.com/memodb-io/memobaseAccessed: 2025-01-04 Cited by: §1, §2.1, §2.3.
• Nan et al. (2025) J. Nan, W. Ma, W. Wu, and Y. Chen Nemori: self-organizing agent memory inspired by cognitive science. CoRR abs/2508.03341. External Links: Link, Document, 2508.03341 Cited by: §2.2, §4.1.
• NevaMind-AI (2025) NevaMind-AI memU: Memory Infrastructure for LLMs and AI Agents. Note: GitHub repository, accessed 2026-07-04 External Links: Link Cited by: §4.1.
• Packer et al. (2023) C. Packer, V. Fang, S. G. Patil, K. Lin, S. Wooders, and J. E. Gonzalez MemGPT: towards llms as operating systems. CoRR abs/2310.08560. External Links: Link Cited by: §1, §1, §2.1.
• Pan et al. (2025) Z. Pan, Q. Wu, H. Jiang, X. Luo, H. Cheng, D. Li, Y. Yang, C. Lin, H. V. Zhao, L. Qiu, and J. Gao SeCom: on memory construction and retrieval for personalized conversational agents. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025, External Links: Link Cited by: §2.2.
• Stabile and Zimuel (2026) M. Stabile and E. Zimuel DMF: a deterministic memory framework for conversational ai agents. External Links: 2606.03463, Link Cited by: §1, §2.2, §2.4.
• Wang (2026) Z. Wang TOKI: a bitemporal operator algebra for contradiction resolution in llm-agent persistent memory. External Links: 2606.06240, Link Cited by: §2.2.
• Wu et al. (2025) D. Wu, H. Wang, W. Yu, Y. Zhang, K. Chang, and D. Yu LongMemEval: benchmarking chat assistants on long-term interactive memory. In ICLR, External Links: Link Cited by: §A.1.2, §1, §1, §1, §2.1, §2.3, §4.1, §4.2.
• Xu et al. (2025) W. Xu, Z. Liang, K. Mei, H. Gao, J. Tan, and Y. Zhang A-MEM: agentic memory for LLM agents. CoRR abs/2502.12110. External Links: Link, Document Cited by: §1, §1, §2.1, §2.2, §4.1.
• Zhang et al. (2026) N. Zhang, X. Yang, Z. Tan, W. Deng, and W. Wang HiMem: hierarchical long-term memory for LLM long-horizon agents. CoRR abs/2601.06377. External Links: Link, Document, 2601.06377 Cited by: §2.2.
• Zhong et al. (2024) W. Zhong, L. Guo, Q. Gao, H. Ye, and Y. Wang MemoryBank: enhancing large language models with long-term memory. In AAAI, pp. 19724–19731. External Links: Link Cited by: §1, §2.1, §2.3.

Appendix A Experimental Protocol Details

This appendix specifies the evaluation protocol used in Section 4. It details the benchmark composition, answer generation protocol, judge configuration, and token accounting rules, so that the reported accuracy-cost trade-off can be interpreted without relying on hidden implementation assumptions. Unless otherwise stated, all generation and judge calls use deterministic decoding with temperature set to 0.

A.1 Benchmark Data and Evaluation Tasks

We report the benchmark statistics separately because LoCoMo and LongMemEval-S use different evaluation units and question taxonomies. LoCoMo evaluates multiple question-answer pairs over each multi-session conversation, whereas LongMemEval-S evaluates one question for each long conversation-question instance. Aggregating these statistics into a single table would obscure the different sources of difficulty in the two benchmarks.

A.1.1 LoCoMo

LoCoMo (20) is a long-context conversational memory benchmark built around companion-style multi-session dialogues. Each dialogue contains two named speakers and requires a memory system to recover fine-grained personal facts, resolve speaker-specific references, and combine evidence distributed across turns or sessions.

Data statistics.

LoCoMo is small in the number of conversations but dense in annotated memory questions. It contains 10 multi-session conversations, with each conversation averaging approximately 600 turns and 16K tokens. The benchmark provides 1,986 question-answer pairs in total; the main evaluation retains 1,540 QA pairs from the standard long-term memory categories after excluding the adversarial/counterfactual subset.

Task categories.

The LoCoMo main evaluation uses 1,540 valid question-answer pairs from the first four categories. We exclude category 5 adversarial/counterfactual questions because these examples are not part of the standard semantic-answering setting used for the main long-term memory QA comparison. The same 1,540 questions are used for the main results, cost analysis, and LoCoMo ablations, so method variants are compared on an identical evaluation set. Table 6 gives the category-level composition.

媒体内容 · 前往原文查看

Question type	# Questions	Evidence pattern	Capability stressed
Single-hop	841	A localized fact, event, preference, or detail is sufficient to answer the question.	Fine-grained fact preservation and speaker/entity disambiguation.
Multi-hop	282	Evidence must be combined across multiple turns, events, or sessions.	Cross-session evidence coverage and entity continuity.
Temporal reasoning	321	The answer depends on dates, ordering, duration, recurrence, or relative time expressions.	Temporal normalization, date-aware retrieval, and reasoning over event order.
Open-domain	96	The question is phrased more openly and may have weak lexical overlap with the relevant dialogue evidence.	Robust evidence selection under non-template queries.
Total	1,540	All retained LoCoMo QA pairs.	Overall micro-average.

A.1.2 LongMemEval-S

LongMemEval-S (28) focuses on agent-style task-oriented interactions with substantially longer dialogue histories. In contrast to LoCoMo, each evaluation item corresponds to one long conversation-question instance. This setting stresses whether a system can recover user facts, assistant-side facts, preferences, cross-session evidence, changed information, and temporal relations under much higher context load.

Data statistics.

LongMemEval-S is organized at the instance level rather than as multiple QA pairs over the same conversation. The official cleaned split contains 500 conversation-question instances, with one question attached to each long dialogue history. Its average context length is approximately 115K tokens per instance, making it substantially longer than LoCoMo and better suited for testing memory construction under high context load.

Task categories.

The LongMemEval-S evaluation uses all 500 questions in the official cleaned split. We report category accuracy using the official question type field and compute the overall score as a micro-average over all 500 questions. For compact table layout, Table 7 abbreviates the official category names as SSU (single-session-user), SSA (single-session-assistant), SSP (single-session-preference), MS (multi-session), KU (knowledge-update), and TR (temporal-reasoning).

媒体内容 · 前往原文查看

Question type	# Questions	Memory ability	Evidence requirement
SSU	70	User-fact recall	Recover a fact provided by the user within a single session.
SSA	56	Assistant-side recall	Recover information, commitments, or responses previously given by the assistant.
SSP	30	Preference tracking	Use user-specific preference information to satisfy the reference rubric.
MS	133	Cross-session reasoning	Integrate evidence distributed across multiple sessions.
KU	78	Changed-state recall	Answer with the updated state from information that changes across the dialogue history.
TR	133	Temporal reasoning	Interpret order, duration, relative time, or time-bounded evidence.
Total	500	Official cleaned split	Overall micro-average.

A.2 Answer Generation and Judge Protocol

We evaluate all methods with GPT-4.1-Mini and GPT-4o-Mini as answer models. For each model, all methods use the same benchmark split and judge protocol. Each memory system constructs or retrieves an evidence context according to its own design before the model generates the final answer. For LycheeMemory, the same model is also used for memory encoding and query planning. Predictions from both models are evaluated with the same benchmark-specific GPT-4o-Mini judge. The token-cost analysis uses GPT-4.1-Mini. Table 8 summarizes the components used by LycheeMemory.

媒体内容 · 前往原文查看

Component	Model	Role
Memory encoder	GPT-4.1-Mini / GPT-4o-Mini	Convert finalized segments into typed memory records.
Query planner	GPT-4.1-Mini / GPT-4o-Mini	Produce typed recall routes for evidence retrieval.
Answer generator	GPT-4.1-Mini / GPT-4o-Mini	Generate the final answer from the retrieved evidence.
Embedding model	text-embedding-3-small	Embed exchanges, records, and queries.
Reranker	bge-reranker-v2-m3	Rerank retrieved evidence candidates without generative decoding.
LoCoMo judge	GPT-4o-Mini	Judge semantic correctness for LoCoMo answers.
LongMemEval-S judge	GPT-4o-Mini	Apply the official task-specific yes/no judge.

For LoCoMo, the judge receives the question, the gold answer, and the generated answer, and returns whether the generated answer is semantically correct. The judge is instructed to accept equivalent phrasings and concise answers that refer to the same fact or time period as the gold answer. Category accuracy is computed within each retained question type, and the overall score is computed over all 1,540 retained questions.

For LongMemEval-S, we use the official task-specific yes/no judge protocol with a 10-token output cap for the judge response. Standard single-session and multi-session questions are judged by whether the generated response contains the correct answer, while preference questions are judged against a rubric-style desired response. For knowledge-update questions, the judge accepts a response that contains the updated answer even if it also mentions previous information. Temporal-reasoning questions use the temporal-specific judge rule, including the official tolerance for minor off-by-one differences in duration-style answers.

A.3 Metrics and Token Accounting

We report category accuracy, overall accuracy, construction tokens, and query tokens. Accuracy is always computed over the valid evaluation set defined for each benchmark: 1,540 retained questions for LoCoMo and 500 questions for LongMemEval-S. No additional filtering is applied beyond these benchmark-specific valid sets. Table 9 summarizes the metric definitions and accounting rules.

媒体内容 · 前往原文查看

Metric	Definition	Notes
Category accuracy	Number of correct answers in a category divided by the number of valid questions in that category.	Reported using each benchmark’s question taxonomy.
Overall accuracy	Number of correct answers divided by the number of valid questions in the benchmark.	Micro-average over questions, not a macro-average over categories.
Construction tokens	Generative LLM input and output tokens consumed during memory construction.	Averaged per conversation or conversation-question instance; reported in K.
Query tokens	Generative LLM input and output tokens consumed during answer generation and any query-time generative planning.	Averaged per question; reported in K.

Construction-token accounting covers memory-building calls such as segment-level encoding. Query-token accounting covers answer generation and the single query-planning call used by LycheeMemory. Non-generative operations, including embedding lookup, structured filtering, reciprocal-rank fusion, reranking, and diversity-aware selection, do not consume generative LLM tokens and are therefore not counted as construction or query tokens. All token costs reported in Section 4.3 use GPT-4.1-Mini. This accounting separates write-side cost from query-side cost.

Appendix B Algorithmic Description

This appendix gives algorithm-level descriptions of the two core procedures in LycheeMemory. The main text explains the design motivation, mathematical scoring components, and system modules; the pseudocode below records the computation path needed to understand when generative LLM calls occur, which intermediate states are maintained, and how the final evidence context is assembled.

B.1 Semantic Segment-Level Memory Construction

Algorithm B.1 corresponds to Sections 3.2–3.4. It emphasizes three implementation properties: segment-level batching reduces construction frequency by assigning one encoding call to each finalized segment rather than each exchange; semantic boundary detection uses embeddings and deterministic scoring to determine segment composition; and cross-segment disambiguation is carried forward only as reference context, not as a new source of facts.

Algorithm B.1: Semantic Segment-Level Memory Construction
Input: conversation stream $𝒞=\{x_1,\dots ,x_T\}$; session identifier $s$; memory store $ℳ$; boundary threshold $\delta$.
Output: updated memory store $ℳ$.
1	Initialize active segment $S\leftarrow \varnothing$, same-session reference context ${\rho }_s\leftarrow \varnothing$, and local surprise history $H_s\leftarrow \varnothing$.
2	Procedure FinalizeSegment$(S,\mathrm{reason})$:
3	Encode $S$ with reference context ${\rho }_s$: $(ℛ,d)\leftarrow \text{Encode}(S,{\rho }_s)$.
4	Normalize each $r\in ℛ$ into $(\mathrm{id},\mathrm{type},\mathrm{text},\mathrm{entities},\mathrm{tags},\mathrm{temporal},\mathrm{provenance})$.
5	Insert each normalized record into $ℳ$.
6	Build entity, topic, entity-topic, temporal, and event-frame evidence nodes from record metadata.
7	Update ${\rho }_s$ with $d$ and recent same-session record summaries; reset $S\leftarrow \varnothing$.
8	For each incoming exchange $x_t\in 𝒞$ do:
9	Index $x_t$ as raw dialogue evidence and embed $x_t$ with the exchange encoder.
10	If $S=\varnothing$, start $S$ with $x_t$ and finalize it if the target length or exchange-count limit is reached.
11	Compute semantic surprise, cohesion drop, length pressure, and exchange-count pressure for $x_t$ relative to $S$.
12	Combine the boundary signals into $P_{\mathrm{cut}}$ and update $H_s$ with the current semantic surprise.
13	If appending $x_t$ would exceed the hard segment capacity, call FinalizeSegment$(S,\mathrm{capacity}\_\mathrm{limit})$ and start a new $S$ with $x_t$.
14	Else if $P_{\mathrm{cut}}\ge \delta$, call FinalizeSegment$(S,\mathrm{semantic}\_\mathrm{boundary})$ and start a new $S$ with $x_t$.
15	Else append $x_t$ to $S$ and finalize $S$ if the target length or exchange-count limit is reached.
16	End for. If the session is flushed and $S\ne \varnothing$, call FinalizeSegment$(S,\mathrm{session}\_\mathrm{flush})$.
17	Return $ℳ$.

B.2 Plan-Guided Multi-Route Retrieval

Algorithm B.2 corresponds to Section 3.5. It uses one LLM planning call to convert the question into typed evidence routes, while route recall, temporal filtering, record search, raw-turn search, reranking, reciprocal-rank fusion, and diversity-aware selection are non-generative operations.

Algorithm B.2: Plan-Guided Multi-Route Retrieval
Input: user query $q$; recent dialogue context $H_q$; memory store $ℳ$; requested evidence budget $k$; configured planning depth $k_{\mathrm{plan}}$.
Output: evidence context $E_q$ for answer generation.
1	Generate a structured retrieval plan with one LLM call: $\Pi \leftarrow \text{Plan}(q,H_q)$.
2	Normalize $\Pi$ and select a retrieval strategy from the planned question type.
3	Set the effective evidence budget $k\leftarrow \max (k,k_{\mathrm{plan}},1)$.
4	For each evidence route $R_i\in \Pi .\mathrm{routes}$ do:
5	Build route-specific query variants from $q$ and $R_i$; initialize candidate set $D_i\leftarrow \varnothing$.
6	If $R_i$ or $\Pi$ specifies a temporal filter, retrieve matching records through temporal evidence nodes and add them to $D_i$.
7	For each query variant $v$ in $R_i$ do:
8	Retrieve entity, topic, entity-topic, and event-frame evidence nodes by semantic search.
9	Expand matched evidence nodes to linked memory records and add them to $D_i$.
10	Retrieve memory records by semantic search over record embeddings and add direct hits to $D_i$.
11	Retrieve raw dialogue turns by semantic search and add raw-turn hits to $D_i$.
12	Merge duplicate candidates inside $D_i$.
13	Apply question-type-specific score adjustments and local evidence expansion.
14	Optionally rerank $D_i$ with a non-generative cross-encoder reranker.
15	Sort $D_i$ to obtain a route-level ranked list $L_i$.
16	End for. Fuse route-level lists $\{L_1,\dots ,L_m\}$ with reciprocal-rank fusion.
17	Preserve route coverage, apply diversity-aware selection, and enforce temporal/source-type budget controls.
18	Serialize selected memory records and raw dialogue snippets into $E_q$.
19	Return $E_q$.

Appendix C Implementation Details

This appendix provides the default implementation parameters following the pipeline order in Section 3. The four stages are online semantic segmentation, segment-level memory encoding, structured evidence organization, and plan-guided multi-route retrieval.

C.1 Online Semantic Segmentation

Online semantic segmentation decides when a buffered dialogue segment should be encoded by the memory encoder. Unlike turn-level eager consolidation, segment-level batching allows multiple exchanges to share one encoding call and therefore controls construction frequency. Within this batching scheme, the semantic boundary policy determines which exchanges form each segment: LycheeMemory finalizes the active segment when it becomes saturated, a topic transition is detected, or a hard capacity limit is reached. Boundary scoring uses embeddings and deterministic computation only.

Each exchange is embedded with text-embedding-3-small. The system maintains the active segment centroid, the most recent exchange embedding, the local semantic-surprise history, the current token length, and the exchange count. Table 10 lists the default segmentation parameters. The implementation converts the combined boundary score into a cut probability:

$P_{\mathrm{cut}}=\sigma \left(-1.10+\mathrm{score}\right),\mathrm{cut}\text{if}{P}_{\mathrm{cut}}\ge 0.50.$

媒体内容 · 前往原文查看

Parameter / signal	Value	Function
Exchange embedding model	text-embedding-3-small	Embed each incoming exchange.
Cut probability threshold	0.50	Finalize the active segment when the cut probability reaches this threshold.
Surprise history window	64 values	Support local normalization of semantic surprise.
Minimum history for robust signal	5 values	Disable robust surprise normalization when the history is too short.
Robust surprise normalization	median/MAD z-score clipped to [-2.0, 4.0]	Reduce outlier and early-stage noise.
Absolute surprise signal	clip((s - 0.20) / 0.14, -1.0, 2.5)	Provide an absolute novelty component.
Minimum chunk tokens	300	Avoid excessive fragmentation.
Target chunk tokens	600	Preferred consolidation scale.
Maximum chunk tokens	900	Hard token cap.
Maximum exchanges	10	Hard exchange-count cap.

The length signal is a piecewise pressure function over the current segment length. It is set to -1.30 below 0.7 * min_tokens, grows from -0.80 to 0 before the minimum length, grows from 0.45 to 1.90 between the minimum and target lengths, grows from 1.90 to 2.80 between the target and maximum lengths, and becomes 3.00 at or beyond the maximum length. The turn-count signal is -0.85 for one exchange, -0.15 for two exchanges, 0.15 for three exchanges, and min(1.0, 0.30 + 0.15 * (n - 4)) for four or more exchanges. If appending a new exchange would exceed the maximum token cap, the current segment is finalized before the new exchange is added.

C.2 Segment-Level Memory Encoding

Segment-level memory encoding converts each finalized segment into typed records that can be retrieved and interpreted without the original dialogue context. The encoder receives the current segment text and a compact same-session reference context, then returns memory records and an updated disambiguation state. Tables 11 and 12 summarize the encoding settings and record schema.

媒体内容 · 前往原文查看

Item	Setting
Encoder model	GPT-4.1-Mini or GPT-4o-Mini, matching the answer model
Temperature	0
Max output tokens	Provider default
Output format	Raw JSON object without markdown fences
disambiguation_context budget	1,200 characters
Same-session reference context budget	2,400 characters
Recent semantic records retained	12

媒体内容 · 前往原文查看

Field	Description
record_id	Internal identifier used to link storage and retrieval entries.
memory_type	One of fact, preference, event, constraint, procedure, failure_pattern, or tool_affordance.
semantic_text	Self-contained natural-language memory statement.
normalized_text	Concatenation of memory type and semantic text.
entities	Canonical entity names.
tags	Topic, action, or type tags.
temporal	Normalized event or validity times, represented by fields such as t_ref, t_valid_from, and t_valid_to.
evidence_turn_range	Source turn indexes.
source_session	Source session identifier.
source_role	user, assistant, both, or empty.
confidence	Current implementation uses 1.0.

C.3 Structured Evidence Organization

Structured evidence organization converts metadata from the segment encoder into searchable evidence nodes. In addition to record embeddings, LycheeMemory organizes records into entity, topic, entity-topic, temporal, and event-frame indexes. This phase does not call a generative LLM; it uses embedding, SQLite/FTS indexing, and deterministic bookkeeping. Table 13 summarizes the organization settings.

媒体内容 · 前往原文查看

Component	Implementation	Notes
Vector backend	LanceDB	Stores record embeddings for direct semantic retrieval.
Structured store	SQLite + FTS5	Stores evidence nodes and full-text searchable fields.
Entity/tag normalization	Case folding, separator normalization, punctuation cleanup, repeated-whitespace merge	Produces stable keys.
Temporal nodes	Day-level and month-level keys	Derived from t_ref, t_valid_from, and t_valid_to.
Event-frame index	Finalized semantic segment	Each node groups the records produced from one finalized semantic segment and retains its source session and turn range as provenance.
Evidence-node merge	node_type:key	Merges repeated entity, topic, and temporal nodes.

LycheeMemory retains textually distinct statements as separate records, including records that may describe successive or conflicting states. The organizer does not perform approximate semantic merging, infer supersession links, close the validity interval of an earlier record, or automatically expire it when a later statement is inserted. This preserves the available historical evidence while leaving conflict resolution to retrieval and answer generation.

C.4 Plan-Guided Multi-Route Retrieval

Plan-guided multi-route retrieval uses one LLM planning call for query understanding and then executes non-generative evidence collection. The planner’s internal question types are single, aggregate, temporal, comparison, personalized_advice, prior_assistant_response, and other. These types are not benchmark categories; they select retrieval strategies, candidate budgets, and route constraints. Table 14 lists the default retrieval parameters.

媒体内容 · 前往原文查看

Retrieval parameter	Value
Planner model	GPT-4.1-Mini or GPT-4o-Mini, matching the answer model; temperature 0
Final top-$k$	max(requested_top_k, plan_depth, 1)
plan_depth	15
Evidence-node recall budget	max(top_k * 3, 30) * evidence_limit_multiplier
Direct record recall budget	max(top_k * 3, 30) * record_limit_multiplier
Raw-turn recall budget	max(top_k, 20) * turn_limit_multiplier
Temporal filter recall budget	max(top_k * 10, 100)
RRF smoothing constant	60.0
Reranker	bge-reranker-v2-m3
Route-level rerank candidate limit	max(configured_reranker_candidate_limit, top_k * 4)
Configured reranker candidate limit	100

Each route can activate direct record recall, evidence-node recall, temporal recall, and raw-turn recall. Route-level candidates are merged with reciprocal-rank fusion using a smoothing constant of 60.0. After fusion, the system first preserves route coverage using the route quota max(1, min(4, top_k // route_count)). The final candidate score is:

$s_{\mathrm{final}}=0.82s_{\mathrm{best}}+0.18s_{\mathrm{route}}.$

Diversity-aware selection uses an MMR-style objective:

$s_{\mathrm{select}}=0.75s_{\mathrm{rel}}-0.25s_{\mathrm{sig}}.$

The candidate signature contains the source session, entities, matched queries, evidence nodes, turns, and text tokens. The final evidence budget is count-based top-$k$ rather than a fixed token budget, so query prompt length varies with the selected evidence text. This is why Section 4.3 reports empirical average query tokens.

Appendix D Token Accounting Details

This appendix expands the token-accounting definitions in Appendix A.3. The distinction between construction tokens and query tokens is central to the paper’s conclusion: LycheeMemory aims to reduce write-side construction cost without shifting the cost to query-time context expansion.

D.1 Construction Tokens

Construction tokens count all recorded generative LLM input and output tokens consumed during memory building, averaged by conversation or conversation-question instance and reported in thousands (K):

$\mathrm{ConstructionTokens}=\frac{{\sum }_{c\in {𝒞}_{\mathrm{build}}}\left(t_c^{\mathrm{in}}+t_c^{\mathrm{out}}\right)}{N_{\mathrm{conv}}}.$

For LycheeMemory, construction tokens include all recorded memory-encoding input and output tokens, covering the segment memory encoding prompt, finalized segment text, reference/disambiguation context, memory-record output, and disambiguation-state output. Construction tokens exclude embedding computation, deterministic structured indexing, SQLite/FTS/vector operations, BM25 or vector search, non-generative reranking, evaluation judge calls, and final answer generation calls.

D.2 Query Tokens

Query tokens count all recorded generative LLM input and output tokens consumed while answering evaluation questions, averaged by question and reported in thousands (K):

$\mathrm{QueryTokens}=\frac{{\sum }_{q\in 𝒬}\left(t_q^{\mathrm{in}}+t_q^{\mathrm{out}}\right)}{\left|𝒬\right|}.$

For LycheeMemory, query tokens include the query-planner input/output, final answer-generation input/output, serialized evidence context, and recent dialogue context included in the answer prompt. Query tokens exclude embedding retrieval, structured filtering, reciprocal-rank fusion, non-generative cross-encoder reranking, diversity-aware selection, and evaluation judge calls. Because the final evidence context is count-based rather than token-budget based, query tokens reflect the average prompt length after selected evidence has been serialized.

Appendix E Ablation Variant Definitions

This appendix defines the implementation of each ablation variant in Section 4.4. The main text discusses the results, while the appendix specifies which modules are removed, replaced, or preserved in each comparison.

E.1 Construction-Side Variants

per-turn construction (w/o segment-level batching).

This variant removes segment-level batching and falls back to turn-level eager construction. On LoCoMo, it triggers memory construction at the speaker-turn ingestion granularity; on LongMemEval-S, it uses the original message/exchange granularity. The record schema, structured indexing, and query-time retrieval pipeline remain unchanged. This variant evaluates the effect of replacing segment-level batching with eager construction.

fixed-window consolidation.

This variant replaces semantic boundary detection with fixed-window batching. It preserves batching, but segment boundaries no longer depend on semantic surprise or cohesion drop. The default configuration uses 600 target chunk tokens and at most 10 exchanges. This variant evaluates semantic boundary detection relative to mechanical windows at a comparable batching scale.

E.2 Representation-Side Variants

summary-level records.

This variant replaces typed, self-contained records with a summary-level representation. It no longer explicitly retains the typed atomic structure formed by memory type, entity, topic, temporal scope, and provenance fields, resulting in summary-level retrieval without these structured fields. The rest of the retrieval pipeline remains unchanged, enabling a comparison between typed records and summary-level memory.

w/o cross-segment reference context.

This variant encodes each segment independently and does not pass same-session disambiguation context or recent resolved records to subsequent segments. The record schema and retrieval pipeline remain unchanged. This variant evaluates the cross-segment context configuration.

E.3 Retrieval-Side Variants

record-vector retrieval only.

This variant disables entity, topic, temporal, event-frame, and raw-turn multi-route recall, and uses only memory-record vector search to return evidence candidates. The final evidence budget is kept consistent with the requested top-$k$ of the full system. This variant evaluates the combined structured and raw-turn recall channels relative to memory-record vector search.

w/o query planner.

This variant removes the LLM query planner and constructs a fixed single-route query directly from the original question. It performs no LLM query rewriting, question-type classification, or route decomposition. Query tokens therefore decrease, but retrieval routes cannot adapt to temporal, comparison, personalized-advice, or prior-assistant-response intents.

w/o fusion/reranking/diversity selection.

This variant preserves recall candidates but jointly removes reciprocal-rank fusion, cross-encoder reranking, and diversity-aware selection. Candidates are sorted by their original retrieval or field scores and truncated to top-$k$. This variant evaluates the combined evidence-selection stack.

Appendix F Prompt Templates and Evaluation Prompts

This appendix reports the prompt templates used by LycheeMemory and the evaluation prompts used for judging. The LycheeMemory memory encoding, query planning, and answer generation prompts are taken from the implementation files src/memory/semantic/prompts.py and src/core/semantic_pipeline.py. The LongMemEval-S judge prompts follow the official task-specific yes/no evaluator, and the LoCoMo judge prompt follows the JSON label protocol used in the LoCoMo evaluation implementation. Prompt blocks below are line-wrapped for typesetting.

F.1 LycheeMemory Segment Encoding Prompt

Segment encoding uses a system message and a user message. The user message contains <SESSION_DATE>, <REFERENCE_CONTEXT>, and <CURRENT_TURNS>. The reference context is used only for resolving references and aliases; it is not treated as a source from which new facts may be extracted.

F.2 LycheeMemory Query Planning Prompt

The query planning prompt converts the current question into an executable retrieval plan. The planner describes only the evidence need visible in the user question and recent context; it does not decide whether the answer exists and does not invent answer candidates. For ordinary named-speaker factual questions, the default behavior is a single route; multiple routes are used only when the question explicitly requires separate evidence.

F.3 LycheeMemory Answer Generation Prompt

The answer generation prompt receives two evidence blocks, episodic/semantic memories and raw memories. The prompt instructs the model to avoid double-counting overlapping evidence, answer only about the named person when a question names a person, and prioritize the most recent supported information when memories conflict.

F.4 LongMemEval-S Official Judge Prompts

The LongMemEval-S evaluator constructs task-specific judge prompts with get_anscheck_prompt(task, question, answer, response, abstention=False). We use GPT-4o-Mini as the metric model, temperature 0, and a 10-token output cap; a response containing “yes” is parsed as correct.

F.5 LoCoMo Accuracy Metric and Judge Prompt

LoCoMo uses accuracy as the primary metric. For each question, GPT-4o-Mini judges whether the generated answer is semantically consistent with the gold answer. Samples labeled CORRECT count as correct; category and overall accuracy are then computed over the retained valid questions.

Appendix G Limitations and Artifact Use

Our evaluation focuses on text-only long-term conversational memory. It does not cover multimodal memories, production latency, long-term online user feedback, privacy governance, cache behavior, or storage growth under continuous deployment. LycheeMemory primarily optimizes construction-token cost and query-time token overhead; database latency, embedding-index storage, and production monitoring require separate deployment-oriented evaluation.

The main results show a remaining weakness on preference-intensive questions. On LongMemEval-S, LycheeMemory reaches 90.00% with GPT-4.1-Mini, below MemoryOS at 100.00%, and 70.00% with GPT-4o-Mini, below MemOS at 96.67%. This suggests that dedicated persona or user-profile modeling may provide advantages for preference-heavy queries. A future system could combine segment-level evidence construction with stronger profile modeling.

The experiments use hosted LLM and embedding APIs together with a reranker model or service. Replacing these components with compatible open-source models is possible, but model capability and token accounting may change; any such replacement should therefore be evaluated with newly reported accuracy and cost numbers.

Artifact release should separate code, prompts, configurations, question-id lists, prediction files, and token-accounting summaries from benchmark redistribution. The local LoCoMo license file specifies Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0), so artifacts containing LoCoMo source conversations, QA pairs, evidence, or substantial derived content should retain attribution and license notices and should respect the non-commercial restriction. The local LongMemEval reference copy is MIT licensed, which requires retaining copyright and license notices when redistributing code, evaluation scripts, processed identifiers, or derived metadata. If multiple benchmark resources are packaged together, each dataset should keep its upstream license instead of being relicensed under the code license of this paper.