CoReMem lets coding agents learn what repository changes to remember for future tasks
arXiv: 2611.17316v1
A new memory framework, CoReMem, teaches large‑language coding agents to pick only the useful parts of a past editing session so that the next task can finish faster and more accurately. In each coding session the agent writes edits to a shared code repository and at the end it records a short memory text. Unlike previous methods that simply store all past work, CoReMem measures how much those recorded snippets help the next, still‑unknown task. The agent’s learning signals a compact set of memory anchors based on repository locations and executable checks.
Figure 2. What crosses coding-task boundaries and where memory is valued and optimized. Existing settings keep memory within one task, transfer general experience across independent tasks, or carry memory while resetting the repository. Our setting carries both repository state and memory to unseen future tasks.Li, Peiwen, Verma, Harshit, Zhou, Sophia, Wang, Haiwen, Bui, Ngoc, Chang, Heng et al. · arXiv:2611.17316v1 · Figure 2: · CC BY 4.0
CoReMem’s key idea is prospective segment valuation. The system runs the next task twice: once with the memory and once without it. If a segment of the previous session speeds up the run in the first case, that segment is kept in memory. The algorithm then gives the agent a cost‑internalizing reward that favours resolving tasks in fewer steps and penalises extra token use. When the agent actually retrieves a memory anchor during the new task, it receives additional credit for the memory’s value.
On ChainSWE, the 27‑billion‑parameter actor improves its resolve rate from 19.1 % to 25.1 % with CoReMem. The same model also uses 17 % fewer steps and 11 % fewer total tokens, including memory‑module calls. Across six open‑weight actor models, post‑training CoReMem raises resolve‑per‑token by 41 % on average, placing the agents in a favourable quadrant of lower steps and higher resolution.
A table showing performance metrics (resolve rate, steps, tokens) for six open‑weight actor models with and without CoReMem memory, indicating higher resolve per token and lower steps with post-training.
Memory layer
Linked
Unlinked
Overall
Tokens per session (K)
Res. per K tokens
Res. (%) ↑
Steps ↓
Res. (%) ↑
Steps ↓
Res. (%) ↑
Steps ↓
Actor ↓
Writer
Total ↓
Actor ↑
Total ↑
Qwen3.5-9B
No memory
9.7
98.4 (91.1)
19.4
98.1 (91.2)
14.0
98.2 (91.2)
98.3 (98.9)
–
98.3 (98.9)
0.152
0.152
Full history
11.4
70.0 (60.5)
17.9
76.4 (68.5)
14.2+2%
72.8 (65.1)−26%
85.9 (79.9)
–
85.9 (79.9)−13%
0.156
0.156+3%
Mem0
12.2
94.3 (86.0)
21.8
93.1 (85.2)
16.4+17%
93.8 (86.0)−5%
96.5 (94.8)
14.9 (14.4)
111.4 (109.1)+13%
0.175
0.1510%
MemOp
11.9
93.5 (85.8)
19.0
96.8 (86.3)
15.0+7%
94.9 (86.1)−3%
99.3 (96.4)
32.4 (33.1)
131.7 (131.4)+34%
0.147
0.111−27%
ReasoningBank
12.0
92.3 (83.6)
17.9
96.7 (90.3)
14.6+4%
94.3 (85.2)−4%
102.3 (94.0)
63.7 (65.8)
166.1 (163.1)+69%
0.143
0.088−42%
CoReMem w/o training
12.5
95.6 (87.2)
19.2
94.6 (88.6)
15.5+11%
95.1 (87.2)−3%
101.7 (104.6)
10.0 (7.5)
111.7 (116.5)+14%
0.140
0.128−16%
CoReMem
14.2
70.2 (64.2)
22.2
75.4 (69.3)
17.7+27%
72.4 (65.1)−26%
75.0 (65.4)
5.0 (2.0)
79.9 (70.8)−19%
0.236
0.222+46%
Qwen3.8-27B-FP8
No memory
19.1
30.9 (22.8)
23.4
40.5 (30.4)
21.0
35.1 (26.0)
32.2 (24.7)
–
32.2 (24.7)
0.653
0.653
Full history
20.7
27.0 (21.3)
24.6
39.8 (33.5)
22.4+7%
32.6 (23.8)−7%
39.0 (29.5)
–
39.0 (29.5)+21%
0.574
0.574−12%
Mem0
20.1
32.5 (26.6)
23.4
40.3 (30.0)
21.5+2%
35.9 (28.2)+2%
34.2 (25.4)
34.5 (28.4)
68.7 (53.4)+113%
0.632
0.314−52%
MemOp
22.5
29.4 (22.2)
24.6
38.9 (36.8)
23.4+12%
33.5 (24.8)−4%
32.3 (23.8)
18.2 (14.7)
50.4 (38.0)+57%
0.727
0.465−29%
ReasoningBank
23.8
30.1 (24.6)
27.0
39.8 (31.8)
25.2+20%
34.3 (27.7)−2%
32.5 (26.2)
35.0 (28.7)
67.5 (54.7)+110%
0.778
0.375−43%
CoReMem w/o training
22.5
26.9 (21.2)
24.5
38.0 (32.9)
23.4+11%
31.8 (22.4)−10%
30.4 (23.0)
2.0 (1.7)
32.4 (24.7)0%
0.772
0.724+11%
CoReMem
25.1
26.2 (18.0)
26.5
33.4 (25.0)
25.7+22%
29.2 (20.0)−17%
26.6 (18.5)
1.9 (1.7)
28.5 (20.3)−11%
0.966
0.902+38%
Gemma-4-31B
No memory
4.3
30.4 (23.8)
20.6
29.3 (21.7)
11.5
29.9 (23.2)
32.4 (23.9)
–
32.4 (23.9)
0.353
0.353
Full history
7.4
25.7 (18.5)
17.5
29.1 (19.8)
11.8+3%
27.2 (19.2)−9%
31.8 (25.8)
–
31.8 (25.8)−2%
0.371
0.371+5%
Mem0
4.9
28.7 (24.3)
18.3
27.4 (21.7)
10.8−6%
28.1 (23.0)−6%
34.0 (26.4)
13.2 (13.3)
47.2 (39.2)+46%
0.322
0.230−35%
MemOp
4.9
26.8 (20.0)
23.0
31.3 (22.5)
12.8+12%
28.8 (20.5)−4%
34.6 (26.2)
14.9 (13.5)
49.6 (39.6)+53%
0.371
0.259−27%
ReasoningBank
7.4
30.6 (23.3)
20.6
30.3 (22.2)
13.2+15%
30.4 (23.0)+2%
33.0 (26.0)
32.3 (28.9)
65.3 (54.9)+102%
0.399
0.202−43%
CoReMem w/o training
6.8
28.2 (21.3)
19.8
28.5 (23.3)
12.5+9%
28.3 (22.0)−5%
31.0 (23.8)
2.9 (1.3)
33.9 (26.3)+5%
0.405
0.371+5%
CoReMem
8.6
28.0 (21.8)
21.4
29.1 (22.0)
14.2+24%
28.5 (21.8)−5%
27.2 (21.7)
2.2 (1.3)
29.3 (23.9)−9%
0.527
0.486+38%
Table 1. Cost and outcome of each memory layer for the open-weight actor models on the test set. Resolve rate and steps on linked and unlinked boundaries (App. B) and overall, cache-aware tokens per session of the actor model and of the memory module (Writer), and resolve per thousand actor or total tokens. Tags give the change against the no-memory row of the same actor model. Grey values in parentheses are medians over sessions. CoReMem w/o training is our memory on the frozen actor model and CoReMem the post-trained actor model with it; replay counts and tests are in App. B, with the definition of every column.Li, Peiwen, Verma, Harshit, Zhou, Sophia, Wang, Haiwen, Bui, Ngoc, Chang, Heng et al. · arXiv:2611.17316v1 · Table 1: · CC BY 4.0
The improvements come with some caveats. The experiments ran on Python repositories only; other languages and larger models have not yet been tested. The study also reports only step counts and token numbers—wall‑clock time, energy use, or memory‑booster behaviour were not measured.
CoReMem lets coding agents learn what repository changes to remember for future tasks | arXiv News
