CoReMem Teaches Coding Agents to Remember Economically — Deciding What's Worth Keeping Before the Next Task Exists

A framework for coding agents that prices memory like inventory: what to write, what to carry, what to discard — evaluated on the next unknown task, not the last one.

Imagine you're a contractor renovating a house one room at a time. After finishing the kitchen, you have leftover tile, notes about where the pipes run, and a half-used bucket of grout. You don't know which room is next — bathroom? basement? — so you can't just save everything. Storage costs money, hauling costs time, and irrelevant junk clutters your truck. The smart move is to keep things that are useful across many possible next rooms (pipe maps, electrical diagrams) and ditch the rest (kitchen-specific trim). CoReMem is that contractor's inventory system, built for coding agents. The committed claim: a memory-selection framework for coding agents that explicitly prices the cost of writing and reading memory, then uses prospective valuation — comparing task performance with and without specific memory segments — to build compact, useful carry-forward memory. This isn't the first paper on agent memory, but it's one of the first to treat memory as an economic resource with measured costs and benefits rather than a simple append-only log. The architecture sits in the RL-for-code-agents family. A 27B-parameter actor model operates on an evolving repository, solving successive SWE-Bench-style tasks. Memory is structured around 'anchors' — repository locations and executable checks — not raw text dumps. Prospective segment valuation runs counterfactual comparisons: the next task is attempted both with and without each trajectory segment from the previous task, and the delta determines what gets kept. Actor adaptation then fine-tunes the agent's policy using rollout groups with and without memory, applying a reward that values task resolution but penalizes step count. A provenance-gating mechanism assigns bonus credit only to steps that actually used memory-supplied anchors, preventing the agent from getting rewarded for memory it ignored. The headline numbers on ChainSWE: resolve rate climbs from 21.0% to 25.7% (a 22% relative improvement), step count drops 17%, and total cache-aware tokens — including the memory system's own overhead — drop 11%. That last number matters: the memory framework doesn't just help, it helps net of its own cost. This is the 'cost-internalizing' part that distinguishes CoReMem from approaches that bolt on memory and hope for the best. The validation regime has notable strengths and gaps. ChainSWE is a purpose-built benchmark for successive coding tasks on evolving repositories, which is the right shape for evaluating this kind of carry-forward memory. The counterfactual valuation design is methodologically sound — you're measuring actual value deltas, not proxying. But ChainSWE is the authors' own benchmark (or at least not a widely established community standard), the 27B model is a single scale point, and there's no independent replication. The comparison baseline is the same actor model without memory, which is the right first comparison but doesn't include other memory-augmented approaches. The milestone question for this line of work is clear: can cost-internalizing memory scale to larger models, longer task chains, and real-world repositories with hundreds of files? The current demonstration is on 27B parameters with structured task chains. The threshold that would make this matter for production coding agents is probably around 5-10 successive real-world tasks on a repository with 500+ files, where the agent maintains useful memory across a full sprint's worth of work without drowning in irrelevant context. The obvious experiment not run: scaling to a larger model (70B+) and longer task chains (10+ successive tasks). The honest read is probably (a) — compute budget. Running counterfactual comparisons for every trajectory segment on every task, across rollout groups with and without memory, is expensive. Doing that at 70B scale with 10-task chains would be a serious compute bill. The framework's design should scale, but proving it costs real money.