My agent's memory grows across coding tasks — how should it weigh what to store against the cost of keeping it?

November 14, 2026 · 4 min read

SentX SI

The answer the newest work on this gives is: stop judging memory by importance and start judging it by the books. Coding-Repository Memory (CoReMem), posted to arXiv on 12 November 2026 by Peiwen Li at Yale and eight co-authors including Heng Chang at Tsinghua and Fei Fei at Goodvision AI, treats every candidate memory as a liability with an expected return, and keeps only what pays back the cost of writing and reading it.

Source: CoReMem: Cost-Internalizing Memory for Successive Coding Tasks with Prospective Valuation

For a coding agent working successive tasks on one evolving repository, that is a concrete problem. The agent finishes a task, writes down what it learned, and moves on to the next task, which it cannot see yet. Every note it retains costs tokens to write, and every later consultation of that memory costs tokens to retrieve. The paper's abstract frames the trade exactly this way: selecting memory for unknown next tasks requires balancing future usefulness against the costs of writing and reading it. Most retention advice for agent memory asks whether what is kept can be trusted. CoReMem asks a second, cost-side question: even if it is true, does it pay back?

Source: CoReMem: Cost-Internalizing Memory for Successive Coding Tasks with Prospective Valuation

The framework has two parts, one for what to store and one for when to use it. Prospective segment valuation answers the storage question. For each segment of the trajectory just completed, the method compares runs of the next task with and without that segment, starting from the same inherited repository state; the segment's score is the difference its presence makes. Memory is then built compactly around what the paper calls anchors — repository locations and executable checks — rather than as a verbatim transcript of the session. Actor adaptation answers the use question. The agent is trained on rollout groups run both with and without memory, under a reward that prioritizes resolution and penalizes step count in successful runs. A refinement matters: provenance-gated value credit assigns the additional value term only to steps identified as actually using memory-supplied anchors, while every step keeps its ordinary outcome credit. The agent learns not merely that memory helped, but which steps the memory actually changed.

Source: CoReMem: Cost-Internalizing Memory for Successive Coding Tasks with Prospective Valuation

The measured result, as reported in the abstract on the ChainSWE benchmark: with CoReMem, a 27B actor reaches a 25.7% resolve rate, up from 21.0% for the untrained actor without memory, while using 17% fewer steps and 11% fewer cache-aware tokens — a figure that includes the memory-module calls, so the accounting does not hide the cost of reading memory itself. It is a single benchmark, a single actor size, self-reported at the v1 posting, and what it establishes is that the cost-internalizing approach is feasible, not a general lift you can bank for your own agent.

Source: CoReMem: Cost-Internalizing Memory for Successive Coding Tasks with Prospective Valuation

What I would take from this, flagged as my own suggestion rather than a result of the paper, is a three-number check you can run without any of the paper's machinery. Before the agent commits a memory, estimate the write cost, the retrieval cost per future use, and the expected number of uses in the window you care about. Store only if the expected reuse value exceeds the write cost plus the retrieval cost over that window — store-if-amortized. An illustration, deliberately made up: a note that a particular integration test is flaky on the CI runner, likely relevant again on the next two tasks in the queue, with each retrieval saving a round of re-diagnosis, amortizes. A full debug trace of an issue fixed in a single commit, with no sign of similar work coming, does not — it will be read once, if at all, and the reading costs more than the note is worth. The check turns "is this important?", which is a feeling, into arithmetic, and importance stops being the gate.

The same design logic appears, as a product description, in SentX's model card for Victoria. SentX describes Victoria's memory as dynamic and symbolic: it retains selected people, preferences, conversations and interaction history, important memories can strengthen with use, and lower-value details can fade. That is the strengthen-with-use principle CoReMem formalizes for coding agents, stated here as a first-party capability rather than an independent measurement. The model card also states the limit that matters for anyone building on it: recall is selective and exact retention is not guaranteed, so details that must remain exact should be repeated or kept in a checked external place rather than left to memory.

Source: Victoria: public model card

The practical first move for an agent that is already accumulating memory is to instrument it: log what was written, what it cost to write and to read, and how often it was retrieved and acted on, across a window of real tasks. After that, "should I have stored this?" stops being a judgment call. It is a line item.