# SWE-MeM: Learning Adaptive Memory Management for Long-Horizon Coding Agents

> SWE-MeM trains agents to proactively compress their own context via a learned memory tool, achieving 60.2% on SWE-Bench Verified with a 30B model under a 32K budget, outperforming larger models and reducing token usage.

- **Source:** [arXiv](https://arxiv.org/abs/2606.28434)
- **Published:** 2026-09-19
- **Permalink:** https://picx.dev/p/5igu2q
- **Whiteboard:** https://picx.dev/p/5igu2q/image

## Summary

## Summary (Overview)

- **SWE-MeM** is a training framework that equips long-horizon software engineering agents with **proactive and on-demand memory management**, allowing the agent to decide *when*, *what*, and *how* to compress its context based on trajectory state, task progress, and remaining context budget.
- The framework introduces a **flexible memory tool** (`compress`) with arguments for analysis, step range, summary content, and remaining work, enabling selective compression of low-value context spans rather than rigid full-history summarization.
- Training combines **synthesized proactive memory-management trajectories**, **curriculum fine-tuning** (two stages: general tool use, then targeted proactive behavior), and **Memory-aware GRPO** with memory-aware trajectory splitting and step-level credit masking.
- On **SWE-Bench Verified**, SWE-MeM achieves **43.4%** resolve rate with a 4B model and **60.2%** with a 30B model under a **32K context budget**, outperforming existing memory management baselines in both performance and efficiency.
- Ablations confirm that proactive triggering, selective span compression, curriculum SFT, and Memory-aware GRPO each contribute meaningfully; removing the memory tool drops performance even with a 256K context window.

## Introduction and Theoretical Foundation

**Background and Motivation.** Long-horizon software engineering agents typically follow a ReAct-style append-only paradigm where interaction history accumulates indefinitely. In software engineering tasks, lengthy environment feedback, verbose logs, and numerous intermediate actions quickly exceed LLM context windows, and even when history fits, agents struggle to effectively utilize task-relevant information from long, noisy trajectories.

**Limitations of Existing Methods.** Prior memory management approaches suffer from two key limitations:

1. **Inflexibility**: Fixed compression rules (threshold-based summarization, subtask-level folding, or window-based compression) cannot adapt to the heterogeneous value of information. Lengthy execution logs can be safely compressed at any point, while early code inspections may remain essential for later reasoning.
2. **Suboptimal optimization objectives**: Existing methods optimize context reduction rather than task-solving efficiency. As shown in Figure 1(c), they reduce peak context length but dramatically increase total token usage or interaction steps.

**Key Insight.** The authors argue that effective memory management should be *learned* as a decision-making capability—the agent should decide when to compress, what to compress, and how to summarize—jointly optimized with issue resolution capability.

## Methodology

### 1. Memory Management Tool Design

The interaction history at time step $t$ is represented as:

$$
C_{t} = \langle p, \{a_{1}, o_{1}\}, \{a_{2}, o_{2}\}, \ldots, \{a_{t-1}, o_{t-1}\} \rangle \tag{1}
$$

where $p$ is the problem statement, $a_i$ is the agent action (text, reasoning, tool calls), and $o_i$ is the environment observation augmented with metadata (step number, remaining context length).

The agent invokes the memory tool:

```
compress(analysis, start_step_number, end_step_number, content, remaining_work)
```

- `analysis`: assessment of current progress and unresolved subtasks
- `start_step_number` $s$ and `end_step_number` $e$: span to compress
- `content` $c$: summary replacing the selected span
- `remaining_work` $f$: remaining subtasks appended to the end of the trajectory

The compression operation transforms the context as:

$$
C_{t} \xrightarrow{\mathcal{M}} C_{t}^{\prime} = \langle p, \{a_{1}, o_{1}\}, \ldots, \{a_{s-1}, o_{s-1}\}, \{c\}, \{a_{e+1}, o_{e+1}\}, \ldots, \{a_{t-1}, o_{t-1}\}, \{f\} \rangle \tag{2}
$$

### 2. Trajectory Synthesis and Curriculum Fine-Tuning

**Synthesis Workflow.** The base model generates task-solving rollouts; a proprietary model (GPT-5.1) handles only proactive-trigger judgment and memory-tool argument synthesis. A **context monitor** triggers compression based on two conditions:

- **Context budget pressure**: probabilistic scheduler—trigger probability becomes non-zero below 20% remaining budget, reaching 1 at 5%.
- **Proactive memory management**: three cases detected via LLM-as-a-judge:
  - *Subtask completion*: retain only the conclusion
  - *Low-information density*: verbose logs or irrelevant exploration
  - *Focus degradation*: long noisy context distracts from the core issue

**Quality Filtering.** Rejection sampling retains trajectories passing test cases, then rule-based cleaning masks defective assistant messages (rather than discarding whole trajectories). Filters include:
- Inappropriate reduction ratio (above 80% or below 20%)
- Overly short compression ranges
- Range misalignment (summary doesn't match declared step range)
- Low-quality responses (empty, repetitive, truncated, invalid tool calls)

**Curriculum Learning.** Two-stage training:
1. **Stage 1**: Train on full filtered synthetic trajectories to learn basic tool format and usage.
2. **Stage 2**: Targeted training on proactive memory trajectories (rubric-filtered) mixed with budget-based compression trajectories (filtered for effective information reuse), preventing catastrophic forgetting.

### 3. Memory-aware GRPO

**Trajectory Splitting.** Rollouts are checkpointed at compression steps and split into sub-trajectories, each starting from the exact compressed prefix observed online. Loss aggregation averages token-level objectives within each rollout first, then averages rollout-level losses across the batch:

$$
\mathcal{L} = \frac{1}{S} \sum_{i=1}^{S} \bar{\ell}_{i}, \quad \bar{\ell}_{i} = \frac{1}{N_{i}} \sum_{k=1}^{K_{i}} \sum_{t=1}^{T_{i,k}} \ell_{i,k,t} \tag{3}
$$

where $N_i = \sum_{k=1}^{K_i} T_{i,k}$ is the number of valid tokens in rollout $i$, and $S$ is the batch size.

**Step-level Credit Masking.** The Memory-aware GRPO objective is:

$$
\mathcal{J}_{\mathrm{MGRPO}} = \mathbb{E}_{i} \left[ \frac{1}{M_{i}} \sum_{k=1}^{K_{i}} \sum_{t=1}^{T_{i,k}} m_{i,k,t} \times \min \left( r_{i,k,t} \hat{A}_{i}, \operatorname{clip}(r_{i,k,t}, 1-\epsilon, 1+\epsilon) \hat{A}_{i} \right) \right] \tag{4}
$$

where $m_{i,k,t} \in \{0,1\}$ controls gradient contribution, and $M_i$ is the number of unmasked valid tokens. Masking strategies:
- **Memory Management Action Quality**: mask steps with poor reduction ratios, short ranges, or misalignment
- **Late Memory Management**: mask compression actions occurring after budget drops below threshold $\tau$
- **Overflow Failure**: in overflow trajectories, penalize only steps where budget is below $\tau$ but no compression is invoked
- **Invalid Tool Usage**: mask steps with invalid tool calls or repetitive content

## Empirical Validation / Results

### Main Results (SWE-Bench Verified)

| Method/Model | Base Model | Length Limitation | Resolve Rate |
|---|---|---|---|
| **<10B Models** | | | |
| Qwen3-4B-Instruct | - | 128k | 7.0 |
| Qwen3-4B-Instruct | - | 32k | 5.2 |
| SWE-Lego-8B | Qwen3-8B | 128k | 42.2 |
| **SWE-MEM SFT** | Qwen3-4B | 32k | **41.6** |
| **SWE-MEM SFT+RL** | Qwen3-4B | 32k | **43.4** |
| **~30B Models** | | | |
| Qwen3-Coder-30B-A3B | - | 256k | 51.6 |
| Qwen3-Coder-30B-A3B | - | 32k | 38.6 |
| Context Folding | Seed-OSS-36B | 32k | 58.0 |
| SWE-Compressor | Qwen2.5-Coder-32B | 64k | 57.8 |
| **SWE-MEM Workflow-only** | Qwen3-Coder-30B | 32k | **58.4** |
| **SWE-MEM SFT** | Qwen3-Coder-30B | 32k | **58.8** |
| **SWE-MEM SFT+RL** | Qwen3-Coder-30B | 32k | **60.2** |

### Efficiency Comparison

| Method | Resolve Rate | Token Usage | Relative Token Usage | Average Step | Relative Step Usage |
|---|---|---|---|---|---|
| Threshold-Compression [25] | 53.8 | 5.18M | 203.9% | - | - |
| SWE-Compressor | 57.8 | 2.75M | 108.3% | - | - |
| Context Folding | 58.0 | - | - | 96.5 | 194.9% |
| **SWE-MEM SFT+RL** | **60.2** | **0.91M** | **94.7%** | **77.0** | **123.5%** |

SWE-MeM achieves the best performance while maintaining the *lowest* token usage among memory-management baselines, and uses *fewer* tokens than the base ReAct agent.

### Ablation Study

- **Proactive vs. threshold-based invocation**: replacing proactive triggering drops resolve rate from 58.8% to 57.4%
- **Selective vs. full-trajectory summarization**: replacing selective span selection drops to 57.6%
- **Curriculum SFT vs. vanilla SFT**: improves from 40.8% to 41.6% (4B model); proactive invocation proportion increases from 2.3% to 16.1% (4B) and 4.1% to 14.7% (30B)
- **Memory-aware GRPO vs. vanilla GRPO**: consistently outperforms on both model scales
- **Memory tool removal**: with 256K context and no memory tool, 4B model drops from 43.4% to 37.6%—memory management provides a cleaner working context, not just overflow prevention

### Cross-Benchmark Generalization

| Model | Length | Multilingual | Pro |
|---|---|---|---|
| Qwen3-4B-Instruct | 256k | 7.3 | 2.6 |
| + SWE-MEM SFT+RL | 32k | **19.0** | **15.2** |
| Qwen3-Coder-30B-A3B | 256k | 35.3 | 28.9 |
| + SWE-MEM SFT+RL | 32k | **40.7** | **31.7** |

Learned memory management transfers across programming languages and provides clear gains on longer-horizon tasks.

## Theoretical and Practical Implications

**Theoretical Implications.**
- The work reframes memory management as a *learnable decision-making capability* rather than a fixed engineering heuristic, aligning with the broader trend toward trainable agent policies.
- Memory-aware GRPO introduces a principled approach to credit assignment in settings where the context state changes mid-trajectory, addressing a fundamental challenge in RL for agents with state-modifying actions.
- The two-stage loss aggregation prevents length bias in RL training—a general issue when rollouts have highly variable lengths.

**Practical Implications.**
- SWE-MeM demonstrates that **smaller models with effective memory management can compete with or exceed much larger models** using larger context windows (4B model with 32K context achieves 43.4% vs. 30B models with 128K context at similar levels).
- The framework reduces token usage below base ReAct agents, directly lowering inference costs.
- The curriculum training approach and quality filtering pipeline provide a practical recipe for training agents with tool-use capabilities.
- The Workflow-only variant (no training, external LLM for compression decisions) achieves 58.4%, offering a cost-effective deployment option before investing in fine-tuning.

## Conclusion

SWE-MeM presents a comprehensive framework for training long-horizon software engineering agents with proactive, on-demand memory management. The key contributions are:

1. **A flexible memory tool** enabling agents to decide when, what, and how to compress based on trajectory state.
2. **A training pipeline** combining trajectory synthesis, curriculum fine-tuning, and Memory-aware GRPO that jointly optimizes memory decisions and task-solving performance.
3. **State-of-the-art results** on SWE-Bench Verified (43.4% with 4B, 60.2% with 30B under 32K context), outperforming existing memory management methods in both performance and efficiency, with demonstrated transfer to SWE-Bench Multilingual and SWE-Bench Pro.

**Future directions** implied by the work include: extending the approach to other long-horizon agent domains beyond software engineering, exploring more sophisticated credit assignment mechanisms, and investigating whether the learned memory policies can transfer across different base models or scaffolds. The authors also suggest that memory management does more than prevent overflow—it provides a cleaner working context that improves reasoning quality—which opens questions about the interaction between memory organization and model reasoning capabilities.

---

_Markdown view of https://picx.dev/p/5igu2q, served by PicX — AI-generated visual whiteboard summaries of research papers._