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

Coding agents that work across successive tasks on an evolving repository face a memory problem: they must decide what to remember before they know what the next task will ask. Every memory segment costs tokens to write, tokens to retrieve, and context window space to store. The agent needs to predict which fragments will pay back those costs when the next task arrives. CoReMem (Coding-Repository Memory) treats memory selection as a cost-benefit problem. It measures the prospective value of each trajectory segment by running the next task twice: once with the segment included, once without. The difference in resolution rate and step count becomes the segment's measured value. The agent then builds a compact memory around anchors (repository locations and executable checks) that showed positive value, and learns when to act on that memory versus waiting for more context. The Memory Selection Problem Most coding agents either dump everything into memory or use heuristic filters (error messages, file edits, test results). Neither approach internalizes cost. Dumping everything bloats context and slows retrieval. Heuristic filters discard segments that might be useful and keep segments that won't be. CoReMem frames the problem explicitly: Write cost: tokens spent serializing the segment Read cost: tokens spent retrieving and re-parsing it Storage cost: context window space occupied until the segment is used or pruned Future utility: expected improvement in resolution rate and step reduction on unknown next tasks The agent selects memory when expected utility exceeds combined costs. This requires estimating utility before the next task is revealed. Prospective Segment Valuation CoReMem runs a two-pass evaluation on each candidate segment from the previous task's trajectory: Baseline run: execute the next task starting from the inherited repository state, without the candidate segment in memory Memory run: execute the same next task from the same state, with the candidate segment included The segment's value is the difference in outcome (resolved vs. unresolved) and efficiency (step count, token usage). Segments that improve resolution or reduce steps get positive value. Segments that add no benefit or slow the agent down get zero or negative value. This approach requires access to the next task for measurement, so it works as a training signal rather than a runtime filter. The agent learns which segment types (error traces, file diffs, test outputs, dependency graphs) tend to have high prospective value across task distributions. Anchor-Based Memory Structure CoReMem organizes memory around two anchor types: Location anchors: file paths, function names, class definitions, variable scopes Executable anchors: test commands, linter invocations, build steps, runtime checks Each anchor links to the trajectory segment that produced it. When the agent encounters a location or needs to run a check, it retrieves the linked segment. This structure keeps memory compact and makes retrieval deterministic. The agent prunes anchors when their linked segments show low prospective value across multiple tasks. Pruning happens between tasks, not mid-task, to avoid destabilizing the current rollout. Actor Adaptation with Provenance-Gated Credit The agent learns when to act on memory versus when to wait for more information. CoReMem uses a reward function that prioritizes resolution and penalizes step count in successful runs: reward = resolution_bonus - (step_count * step_penalty) The agent runs rollout groups with and without memory access. The difference in on-policy reward estimates the memory's value. Provenance-gated credit assignment splits this value: Outcome credit: every step in a successful run gets the resolution bonus Memory credit: only steps that used memory-supplied anchors get the additional value term from the memory-vs-no-memory comparison This prevents the agent from over-attributing success to memory when the task would have resolved without it. It also prevents under-attribution when memory enables a shortcut that saves steps. Architecture and Flow ┌─────────────────┐ │ Task N (done) │ │ - trajectory │ │ - repo state │ └────────┬────────┘ │ ▼ ┌─────────────────────────────────┐ │ Prospective Valuation │ │ - run Task N+1 without segment │ │ - run Task N+1 with segment │ │ - measure Δ(resolution, steps) │ └────────┬────────────────────────┘ │ ▼ ┌─────────────────────────────────┐ │ Anchor Selection │ │ - keep high-value segments │ │ - prune low-value segments │ │ - serialize anchors + links │ └────────┬────────────────────────┘ │ ▼ ┌─────────────────────────────────┐ │ Task N+1 (new) │ │ - actor retrieves anchors │ │ - provenance tracks usage │ │ - reward split: outcome + mem │ └─────────────────────────────────┘ The cycle repeats for each successive task. The agent's memory grows when new anchors prove valuable and shrinks when old anchors stop paying back their cost. Implementation Considerations Component Trade-off Mitigation Prospective valuation Requires running next task twice (expensive) Amortize over batch of segments; use cheaper proxy model for initial filtering Anchor pruning Aggressive pruning loses useful context; conservative pruning bloats memory Track anchor usage frequency and recency; prune when both are low Provenance tracking Adds instrumentation overhead to every step Use lightweight span IDs; batch provenance writes Reward shaping Step penalty may discourage thorough exploration Tune penalty coefficient per task distribution; use separate exploration budget The paper reports results on ChainSWE, a benchmark of successive coding tasks on evolving repositories. CoReMem raised the 27B actor's resolve rate from 21.0% to 25.7%, with 17% fewer steps and 11% fewer total cache-aware tokens (including memory module calls) relative to the untrained actor without memory. When Memory Value Goes Negative Memory can hurt performance in three scenarios: Stale anchors: the repository evolved and the anchor points to outdated code Misleading context: the segment describes a problem that no longer exists or a solution that no longer applies Retrieval overhead: the cost of fetching and parsing the segment exceeds the value it provides CoReMem handles staleness by re-validating location anchors against the current repository state. If a file path or function name no longer exists, the anchor is pruned immediately. Executable anchors are re-run to confirm they still produce useful signals. Misleading context is harder to detect. The agent relies on prospective valuation to identify segments that consistently reduce performance. If a segment type shows negative value across multiple tasks, the agent stops selecting it. Retrieval overhead is managed by tracking token counts for each anchor retrieval. If retrieval cost exceeds the segment's measured value, the anchor is marked for pruning. Deployment Shape CoReMem requires three components: Memory module: stores anchors, handles retrieval, tracks provenance Valuation pipeline: runs paired task executions, computes segment value Actor training loop: collects rollouts, assigns credit, updates policy The memory module can be a separate service with a vector store for anchor embeddings and a key-value store for segment content. The valuation pipeline runs offline between task batches. The actor training loop runs online during task execution. For production deployment, the valuation pipeline can be replaced with a learned value estimator that predicts segment value without running the next task. This trades measurement accuracy for speed. Failure Modes Value estimation drift: if the task distribution shifts, historical value measurements become unreliable Anchor collision: multiple segments link to the same anchor, causing retrieval ambiguity Credit leakage: provenance tracking misattributes memory usage when the agent uses memory indirectly (e.g., memory informs a search query that finds the answer) Pruning thrash: the agent prunes an anchor, then re-discovers it in the next task, wasting write cost The paper does not address multi-agent scenarios where memory must be shared or synchronized across actors working on the same repository. Technical Verdict Use CoReMem when: Your agent works on successive tasks where repository state carries forward Memory bloat is a bottleneck (context window exhaustion, slow retrieval) You can afford offline valuation runs between task batches You need explainable memory selection (anchors provide clear provenance) Avoid CoReMem when: Tasks are independent (no repository evolution) You need real-time memory selection without offline training Your task distribution shifts frequently (value estimates go stale) You cannot instrument the actor for provenance tracking The framework is most valuable for long-running coding agents that maintain a repository over weeks or months. For short-lived agents or one-shot tasks, the valuation overhead exceeds the memory savings. Source Links CoReMem paper on ArXiv PDF