PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Shuzheng Gao, Wenhao Zeng, Zhaojian Yu, Jianqiao Wangni, Chaozheng Wang, Kai Cai, Shilin He, Michael R. Lyu

arXiv:2606.28434v1cs.SEcs.AI

TL;DR

Long-horizon coding agents must manage lengthy, noisy histories under limited context budgets, while existing compression methods do not jointly optimize memory management and issue resolution. SWE-MeM trains agents to make adaptive compression decisions using synthesized trajectories and Memory-aware GRPO. On SWE-Bench Verified, it reaches 43.4% and 60.2% resolve rates with 4B and 30B models, outperforming existing memory-management baselines in performance and efficiency.

  • Problem

    Long-horizon coding agents face context overflow and noisy histories, while existing memory-management methods use rigid compression and do not jointly optimize memory management with issue resolution.

  • Method

    SWE-MeM combines an adaptive memory tool, synthesized proactive memory-management trajectories, curriculum fine-tuning, and Memory-aware GRPO for joint memory and task-solving optimization.

  • Results

    43.4% and 60.2% resolve rates are achieved on SWE-Bench Verified with 4B and 30B models, respectively, outperforming existing memory-management methods in performance and efficiency.

  • Takeaways & Limitations

    Adaptive, jointly trained memory management improves SWE-Bench Verified performance while reducing interaction costs under a compact 32K context budget.

Abstract

from arXiv · show

Long-horizon software engineering agents often need to manage lengthy and noisy interaction histories under limited context budgets. Existing memory management methods typically rely on static compression workflows or impose rigid constraints on compression timing and granularity. Moreover, these approaches fail to jointly optimize memory management and issue resolution capabilities to improve performance while reducing token usage. We present SWE-MeM, a training framework for proactive and on-demand memory management in software engineering agents. SWE-MeM provides a flexible memory tool that lets agents decide when, what, and how to compress based on trajectory state, task progress, and remaining context budget. We train agents with synthesized proactive memory-management trajectories and Memory-aware GRPO, which jointly optimizes memory management and issue resolution through memory-aware trajectory splitting and step-level credit assignment. On SWE-Bench Verified, SWE-MeM achieves 43.4% and 60.2% resolve rate with 4B and 30B models, respectively, outperforming existing memory management baselines in both performance and efficiency.

1 Introduction

Long-horizon coding agents face noisy, overlong histories and rigid memory-management methods that reduce context without jointly optimizing task-solving efficiency. SWE-MeM lets agents adapt compression decisions to trajectory state and trains this capability jointly with issue resolution, achieving strong SWE-Bench Verified results under a 32K budget.

  • Motivation: Long-horizon software engineering trajectories can exceed LLM context windows and make task-relevant information difficult to use effectively.Intermediate actions and lengthy environment feedback accumulate in noisy histories.
  • Limitations of prior methods: Existing methods use threshold-based summarization, subtask folding, or learned compression to reduce context length.These approaches summarize full histories, fold completed subtasks, or compress earlier turns while preserving recent interactions.
  • Limitations of prior methods: Fixed compression rules cannot adapt to heterogeneous information value, because execution logs may be compressible while early code can remain essential later.Figure 1 illustrates the resulting tool-flexibility issue.
  • Limitations of prior methods: Existing methods may reduce peak context length while increasing total token usage or interaction steps, worsening overall efficiency.The paper frames this as a mismatch between context reduction and task-solving efficiency.
  • SWE-MeM: SWE-MeM provides a flexible memory tool for deciding when to compress, what to compress, and how to summarize selected context from trajectory state.The framework trains these decisions using synthesized proactive memory-tool trajectories and combines curriculum learning with Memory-aware GRPO.
  • Results: 43.4% and 60.2% resolve rates are achieved with Qwen3-4B-Instruct and Qwen3-Coder-30B-A3B, respectively, on SWE-Bench Verified.Under a 32K context budget, SWE-MeM outperforms existing memory-management methods with higher resolve rates and fewer interaction rounds.

2 Proposed Approach

SWE-MeM equips software engineering agents with flexible, proactive memory management and trains them to use it through synthesized trajectories and memory-aware reinforcement learning. Its design preserves compressed context state during training while addressing trigger timing, trajectory quality, and rollout-length variability.

  • Memory Management Tool: SWE-MeM lets agents decide when to invoke compression, which span to compress, and how to summarize it instead of following fixed workflows.The selected span can include lengthy logs, failed exploratory attempts, or obsolete observations, and compressed summaries may be compressed again later.
  • Memory Management Tool: The memory operation replaces a selected trajectory span with a summary while preserving temporal ordering and reducing context length.The resulting memory entries remain available for later progressive compression as the trajectory grows.
  • Synthesized Memory Trajectories: SWE-MeM synthesizes task-solving trajectories with memory-management actions and uses a context monitor to trigger compression from budget pressure or proactive trajectory-state judgments.Budget pressure becomes probabilistic below 20% remaining budget and reaches certainty at 5%; proactive cases include subtask completion, low-information density, and focus degradation.
  • Trajectory Quality Filtering: Trajectory quality filtering retains test-passing rollouts and masks locally defective assistant messages rather than discarding entire trajectories.Compression defects include inappropriate reduction ratios, overly short ranges, and range misalignment; non-compression defects include empty, repetitive, truncated, or invalid responses.
  • Curriculum Fine-Tuning: A two-stage curriculum first teaches basic memory-tool usage, then emphasizes high-quality proactive memory behavior while retaining budget-based examples to avoid catastrophic forgetting.The targeted stage also evaluates whether agents reuse compressed information, avoid redundant reacquisition, and maintain coherent progress.
  • Memory-aware GRPO: Memory-aware GRPO splits rollouts at compression steps and aggregates valid token losses within each rollout before averaging across rollouts to preserve training-inference consistency and reduce length bias.Each sub-trajectory begins from the compressed prefix observed online, while equal rollout-level weighting prevents long trajectories from dominating optimization.

3 Experiment

SWE-MeM is evaluated on SWE-Bench Verified against ReAct agents, existing memory-management methods, and its own workflow and training variants. It improves resolve rates at both model scales while using a compact 32K context limit.

  • Main results: SWE-MeM outperforms baseline methods at both 4B and 30B scales while using a compact 32K context limit.The experiments report resolve rate as the primary evaluation metric.
  • Main results: 58.4% resolve rate is achieved by the 30B Workflow-only configuration without model training, substantially outperforming the corresponding Qwen3-Coder-30B-A3B ReAct baseline.The result indicates that the proposed memory-management workflow can improve performance without training when proprietary-model assistance supplies compression decisions.
  • Main results: 60.2% resolve rate is reached after 30B RL training, while SWE-MeM also improves the corresponding base model from 51.6% to 58.8% after SFT.The paper reports consistent gains over existing memory-management baselines, including Context Folding’s improvement from 55.2% to 58.0% on Seed-OSS-36B.

4 Further Analysis

Further analyses examine efficiency, design choices, training procedures, the memory tool, and transfer to harder benchmarks. The results support selective, proactive memory management as both an efficiency and performance mechanism.

  • Efficiency analysis: SWE-MeM achieves the best task performance with the lowest reported token usage among the evaluated memory-management methods.It also uses fewer tokens than the corresponding ReAct agent, while most competing methods increase total token usage.
  • Efficiency analysis: Selective compression increases interaction steps much less than Context Folding, suggesting less redundant context and re-exploration.The reported comparison concerns interaction-step overhead alongside token usage.
  • Agent design: 57.4% and 57.6% resolve rates result when proactive invocation and selective span selection are replaced by threshold-based invocation and full-trajectory summarization.The ablation is conducted only on the 30B model because the original 4B model is too weak for a stable comparison.
  • Curriculum SFT: 41.6% versus 40.8% resolve rate shows curriculum SFT outperforming vanilla SFT for the 4B model.Proactive tool invocations also rise from 2.3% to 16.1% for 4B and from 4.1% to 14.7% for 30B after second-stage training.
  • Memory-aware GRPO: Memory-aware GRPO consistently outperforms vanilla GRPO on both model scales.The analysis identifies loss aggregation and step-level credit assignment as important for long-horizon RL training.
  • Memory tool: Removing the memory tool lowers the 4B resolve rate from 43.4% to 37.6% despite expanding the context window to 256K.The authors interpret this as evidence that memory management helps maintain a cleaner working context, not merely avoid context overflow.
  • Transfer evaluation: On SWE-Bench Multilingual, resolve rates rise from 7.3% to 19.0% for 4B and from 35.3% to 40.7% for 30B under a 32K context limit.The evaluation also covers SWE-Bench Pro, which emphasizes longer-horizon issue-resolution tasks.
  • Transfer evaluation: On SWE-Bench Pro, resolve rates rise from 2.6% to 15.2% for 4B and from 28.9% to 31.7% for 30B.These improvements are reported against corresponding base models using a smaller 32K context than the base models’ 256K context.

5 Related Work

Related work spans software-engineering agents and methods for managing context in extended interactions. SWE-MeM builds on this progression toward adaptive context-management policies for coding agents.

  • Software-engineering agents: Software-engineering research progressed from atomic code capabilities to autonomous repository-level task solving.Earlier work covered generation, repair, summarization, translation, and test generation; later work developed repository-level agent scaffolds.
  • Context management: Context management is critical for agents operating long-horizon tasks across hundreds of interaction rounds.Prior approaches include token-level pruning, code-specific optimization, context folding, routing, adaptive pruning, trajectory reduction, and trainable policies.

6 Conclusion

SWE-MeM combines proactive and on-demand memory management with trajectory synthesis and Memory-aware GRPO. On SWE-Bench Verified, it reaches 43.4% and 60.2% resolve rates in the 4B and 30B settings while outperforming existing memory-management baselines in performance and efficiency.

  • SWE-MeM combines a flexible memory tool, trajectory synthesis with curriculum fine-tuning, and Memory-aware GRPO for long-horizon software engineering agents.
  • 43.4% and 60.2% resolve rate are achieved in the 4B and 30B settings, respectively, on SWE-Bench Verified.
  • SWE-MeM outperforms existing memory management baselines in both performance and efficiency.

A.1 Detailed Trajectory Synthesis Procedure

The trajectory synthesis procedure monitors context-budget pressure and proactive conditions during rollout, then uses a proprietary model to generate memory operations when compression is triggered. Each operation replaces a selected span with compressed content and appends a remaining-work summary, while ordinary agent interaction continues otherwise.

  • Step 1: rollout initialization: Algorithm 1 constructs memory-management trajectories by initializing a conversation with the task prompt, context budget, base model, and proprietary model.The base model generates ordinary agent actions, while the proprietary model provides synthetic memory-management supervision.
  • Step 2: budget-aware monitoring: At each iteration, the procedure computes remaining token budget, initializes compression state, and evaluates whether compression should be triggered.The monitor uses budget pressure and proactive memory-management conditions, and may skip monitoring briefly after a recent compression action.
  • Step 3: generating the compression action: When compression is triggered, the proprietary model reflects on progress, selects a valid span, and generates compressed content with a concrete remaining-work plan.The selected span is constrained to avoid illegal overlaps with previously compressed content.
  • Step 4: trajectory update and continued rollout: After synthesis, the selected source span is replaced by compressed content and the remaining-work summary is appended; otherwise, the base model continues interacting with the environment.

A.2 Detailed Description of Trajectory Splitting Process

SWE-MeM represents post-compression histories as mixed trajectories that retain unselected context, replace selected spans, and append remaining-work information. Rollouts are split at compression boundaries, while prompts govern when compression occurs, which content is eligible, and how the resulting operation is represented.

  • Trajectory update: Each memory event replaces only a selected source range while retaining context before and after that span.The compressed context therefore combines retained original rounds, one compressed span, and an appended remaining-work item rather than summarizing the entire prefix.
  • Trajectory splitting: Trajectory splitting creates segments that begin from the partially compressed context available to the agent at deployment time.This preserves consistency between training and inference states.
  • Dynamic memory management: Algorithm 1 monitors remaining budget and invokes either budget-pressure or proactive compression before ordinary agent actions continue.
  • Compression conditions: The context monitor prompt allows compression for completed subtasks, consecutive low-density content, or serious unresolved issues, while excluding high-density or potentially useful content.The prompt specifically treats early exploration, successful file modifications, useful test failures, and untested reproductions as high-density cases that should not be compressed.
  • Compression conditions: Low-density compression requires recent content to be self-contained and unrelated to subsequent work, with the last 3-5 rounds all qualifying as low density.
  • Compression conditions: Critical-issue compression alerts the agent to high-risk patch flaws, repeated unresolved core problems, or premature finalization with unaddressed risks.The prompt instructs the system to use this alert conservatively and still compress when the condition applies.
  • Prompt outputs: The decision prompt returns whether to compress, a compression type, and a first-person reason; the generation prompt then operates on the input trajectory.

B.1 Dataset Details

SWE-MeM training data is constructed from SWE-ReBench and SWE-Gym, with filtered synthetic trajectories for supervised fine-tuning and a non-trivial subset for reinforcement learning. Evaluation uses SWE-Bench-Verified alongside multilingual and more difficult long-horizon benchmarks, with future commits removed to prevent leakage.

  • SWE-MeM constructs supervised fine-tuning and reinforcement-learning data from SWE-ReBench and SWE-Gym.
  • SFT synthesis uses Qwen3-Coder-30B-A3B-Instruct, GPT-5.1, three rollouts per problem, and filtering that retains one trajectory for fully correct problems.
  • 2,194 training instances remain after ground-truth evaluation, reference-patch filtering, and best-of-n verification for the RL subset.The procedure removes trivially easy and completely intractable samples.
  • Evaluation covers SWE-Bench-Verified, SWE-bench Multilingual, and SWE-bench Pro, using issue resolve rate as the main metric.Future commits are removed from the evaluation environment to avoid unintended repository-history leakage.

B.2 Training Details

Training uses Qwen3 base models with OpenHands under a 32,768-token context limit, followed by supervised fine-tuning and reinforcement learning with specified curricula and optimization settings.

  • Qwen3-Coder-30B-A3B-Instruct and Qwen3-4B-Instruct-2507 serve as the base models for all experiments.
  • OpenHands is used as the agent scaffold, with a 32,768-token context limit throughout data collection, supervised fine-tuning, and reinforcement learning.
  • Supervised Fine-Tuning: Supervised fine-tuning uses VeOmni with global batch size 128, learning rate 2 × 10−5, cosine scheduling, and three epochs, followed by curriculum tuning on proactive-memory data.The second-stage pass uses learning rate 2 × 10−6 for one epoch.
  • Reinforcement Learning: Reinforcement learning uses Verl with batch size 64, eight rollout samples per instance, learning rate 2 × 10−6, τ=0.05, and rollout temperature 1.0.DAPO clipping and R3 Rollout Routing Replay are also enabled, with replay applied only in 30B RL training.
  • The section also presents real memory-management invocations and complete trajectories containing memory-management actions.

C.1 Memory Management Action Examples

The examples show memory actions preserving the reasoning needed for future work while compressing redundant trajectory details. They also illustrate how agents assess progress, validate fixes, and identify unresolved limitations before deciding what to retain.

  • Validation and limitations: Incomplete Django debugging is represented by explicit unresolved limitations, including an unverified patch, missing full test execution, and continued failure for descriptor-based fields.These summaries distinguish confirmed reproduction and partial implementation from a validated solution.
  • Compression decisions: Memory compression is most useful after substantial verification, while final patch inspection and final validation should remain available for subsequent reasoning.The trajectory identifies mid-to-late testing segments as better compression targets than the final verification rounds or early root-cause analysis.
  • Completed debugging trajectories: A Sphinx example compresses successful verification into the result that enum formatting is corrected while non-enum behavior remains unchanged.Direct calls, custom scripts, relevant test suites, and integration checks were used to validate the localized change.
  • Validation and limitations: The examples retain environmental warnings separately from core validation, treating a failed temporary-module import as an integration-script issue rather than evidence against the patch.The Sphinx build succeeded, while the ad hoc import-based check was considered unreliable for evaluating the fix.
  • Completed debugging trajectories: The memory summaries preserve the problem, relevant code paths, reproduction evidence, implemented changes, and verification status across completed debugging phases.This structure retains both the trajectory’s key accomplishments and the information needed to continue or assess the fix.

C.2 Trajectory Examples

The trajectory examples show memory management compressing distinct stages of issue resolution, including setup, reproduction, diagnosis, and validation. They also illustrate backward compression and progressive recompression, while preserving later verification outcomes.

  • Case A: scikit-learn-14087-0: Case A follows scikit-learn debugging from reproduction and diagnosis to broader regression testing.The trajectory includes an initial reproducer, branch tracing for binary versus multinomial handling, targeted tests, and final verification.
  • Case A: scikit-learn-14087-0: Memory Management 1 compresses the early setup, code reading, and first reproducer attempts from rounds 5--23.The compressed block covers locating LogisticRegressionCV and exposing the refit=False failure.
  • Case A: scikit-learn-14087-0: Memory Management 2 compresses the detailed diagnosis from rounds 24--33, including branch tracing and isolating the exact failing path.The subsequent validation stage covers reproducer checks, multinomial and refit=True probes, and focused logistic-regression tests.
  • Case A: scikit-learn-14087-0: Memory Management 3 compresses rounds 34--54, including reproducer re-checks, broader logistic tests, and exact-issue checks before regression confirmation.The trajectory ends after the regression suite confirms that the fix generalizes cleanly.
  • Case B and Case C: Case B demonstrates non-monotonic summary order, while Case C demonstrates progressive recompression of an already summarized range.In Case B, the agent compresses a mid-trajectory block, then an earlier setup block, and then a later diagnosis block; in Case C, rounds 3--10 are recompressed as the range extends to rounds 3--21.
Loading 2606.28434v1…