# SWE Context Bench: A Benchmark for Context Learning in Coding
**Authors**:
- Jared Zhu (Independent Researcher)
- Minhao Hu (University of Oxford)
- Junde Wu (University of Oxford)
## Abstract
Large language models are increasingly used as programming agents for repository level software engineering tasks. While recent benchmarks evaluate correctness in realistic codebases, they largely treat tasks as independent and do not assess whether agents can reuse experience across related problems. As a result, the ability of agents to accumulate, retrieve, and apply prior experience, as well as the efficiency gains from such reuse, remains difficult to measure. We introduce SWE-ContextBench, a benchmark designed to explicitly evaluate experience reuse in programming agents. Built on SWE-Bench Lite, SWE-ContextBench augments 300 base tasks with 99 related tasks derived from real dependency and reference relationships among GitHub issues and pull requests, forming task sequences with shared context. The benchmark evaluates agents along three complementary dimensions: prediction accuracy, time efficiency, and cost efficiency. Using SWE-ContextBench, we study multiple experience reuse settings, including oracle guided and autonomous retrieval, as well as full execution trajectories and compact summaries. Our results show that correctly selected summarized experience improves resolution accuracy and substantially reduces runtime and token cost, particularly on harder tasks. In contrast, unfiltered or incorrectly selected experience provides limited or negative benefits. These findings highlight the importance of experience representation and retrieval quality, and position SWE-ContextBench as a principled benchmark for studying experience reuse in programming agents.
## 1 Introduction
Large language models (LLMs) are increasingly deployed as programming agents, supporting tasks such as code generation, bug fixing, and navigation of complex code repositories. Early code benchmarks primarily evaluated isolated synthesis tasks and focused on functional correctness. However, these benchmarks have become saturated, with near perfect performance on HumanEval Chen (2021) and MBPP Austin et al. (2021). To address this limitation, recent benchmarks extend evaluation to repository level software engineering settings, where models must reason over larger codebases and generate code changes evaluated in realistic repository contexts Jimenez et al. (2023); Liu et al. (2023).
Despite these advances, existing agent benchmarks remain focused on solving individual tasks from scratch. They primarily evaluate parametric memory encoded in model weights Yang et al. (2024); Zeng et al. (2025) and short term activation memory constrained by context windows Yu et al. (2025); Zhou et al. (2025), without assessing how agents accumulate or reuse experience across tasks. As a result, each task is treated as an independent episode, preventing explicit evaluation of experience reuse and its impact on efficiency. Prior studies suggest that incorporating memory of past interactions enables agents to learn from previous mistakes and generalize knowledge across related tasks (Chhikara et al. (2023)). This observation aligns with real world software development, where recurring problem patterns and incremental refinement are common, and engineers routinely learn from past successes and failures.
<details>
<summary>fig1_cover_image.png Details</summary>
### Visual Description
\n
## Diagram: Comparison of Benchmark Paradigms for AI Agents
### Overview
The image is a conceptual diagram comparing three different benchmarking approaches for evaluating AI agents. It is divided into three distinct panels, labeled (a), (b), and (c). Panels (a) and (b) are presented with a light pink background and are associated with negative outcomes (indicated by red, angry face icons). Panel (c) is presented with a light green background and is associated with a positive outcome (indicated by a green, happy face icon). The diagram illustrates a shift from isolated task evaluation to a context-aware, experience-reusing paradigm.
### Components/Axes
The diagram is segmented into three primary regions:
1. **Panel (a) - Top Left:**
* **Title:** `(a) Agent Benchmark: Independent Tasks`
* **Icon:** A red, angry face emoji (😡) is positioned to the right of the title.
* **Content:** Two example tasks are listed, each preceded by a small icon of a robot sitting at a computer.
* Task 1: `Fix the bug: Changing an IntegerField to a ForeignKey generates ...`
* Task 2: `Fix the bug: Changing the type of a ForeignKey and changing ...`
2. **Panel (b) - Bottom Left:**
* **Title:** `(b) Long Context Benchmark: Information Retrieval`
* **Icon:** A red, angry face emoji (😡) is positioned to the right of the title.
* **Content:** One example task is shown, preceded by a small icon of a robot gesturing.
* Task: `Please identify the fictional character who occasionally breaks the fourth wall with the audience?`
3. **Panel (c) - Right Side:**
* **Title:** `(c) SWE-ContextBench`
* **Icon:** A green, happy face emoji (🙂) is positioned to the right of the title.
* **Content:** This panel illustrates a process flow.
* **Central Element:** A large, light-green oval labeled `Experience Pool`. Inside this oval, two text bubbles are shown:
* Left bubble: `The issue was that `BaseFormSet``
* Right bubble: `When changing a ForeignKey field type and updating ..`
* **Flow Arrow:** A green, curved arrow originates from the right text bubble within the Experience Pool and points downward to a task below.
* **Label:** The arrow is labeled `Experience Reuse`.
* **Target Task:** At the bottom of the panel, a robot icon at a computer is shown next to the task: `Fix the bug: Changing the type of a ForeignKey and changing ...`
### Detailed Analysis
* **Textual Content:** All text is in English. The ellipses (`...`) in the task descriptions indicate that the text is truncated.
* **Spatial Relationships:**
* Panels (a) and (b) are stacked vertically on the left, sharing a similar visual style (pink background, angry icon) to group them as "traditional" or "problematic" approaches.
* Panel (c) occupies the entire right side, using a contrasting green background and happy icon to signify a proposed solution or improved method.
* The `Experience Pool` is the central visual element in panel (c), suggesting it is the core resource.
* The `Experience Reuse` arrow creates a direct visual link between past knowledge (in the pool) and a current task, demonstrating the proposed mechanism.
* **Iconography:**
* The robot icons differentiate the type of agent or task: a focused coder for bug-fixing tasks (panels a and c) and a gesturing presenter for an information retrieval task (panel b).
* The angry vs. happy face icons are clear, non-textual indicators of the presumed effectiveness or desirability of each benchmarking paradigm.
### Key Observations
1. **Contrast in Evaluation:** The diagram explicitly contrasts benchmarks that evaluate agents on `Independent Tasks` (a) or pure `Information Retrieval` (b) with one that evaluates them within a `Context` (c) where they can reuse prior experience.
2. **Shared Task Example:** The task `Fix the bug: Changing the type of a ForeignKey and changing ...` appears in both panel (a) and panel (c). This is a critical link, showing the same problem type being approached under different benchmarking frameworks.
3. **From Isolation to Context:** Panel (a) shows tasks in isolation. Panel (c) shows a task connected to a repository of past experiences (`BaseFormSet` issue, previous ForeignKey changes), implying that solving the new task benefits from this context.
4. **Visual Sentiment:** The use of color (pink/red for negative, green for positive) and emojis creates an immediate, strong visual argument about the relative merits of the approaches.
### Interpretation
This diagram argues that traditional agent benchmarks are flawed because they test capabilities in a vacuum. The `Agent Benchmark` (a) presents isolated coding tasks without context, and the `Long Context Benchmark` (b) tests retrieval of discrete facts from a large context, which may not reflect real-world problem-solving.
The proposed `SWE-ContextBench` (c) represents a more ecologically valid evaluation. It posits that a software engineering (SWE) agent's true capability is demonstrated not by solving a bug from scratch, but by its ability to **reuse relevant past experiences** (stored in an "Experience Pool") to inform its approach to a new, similar problem. The arrow labeled "Experience Reuse" is the core thesis: effective agents should leverage historical context (e.g., knowledge about `BaseFormSet` or previous field-type changes) to solve current tasks more efficiently and accurately.
The diagram suggests that benchmarks failing to account for this contextual reuse (the angry-faced panels) provide an incomplete or misleading picture of an agent's practical utility, while benchmarks that incorporate it (the happy-faced panel) are better aligned with real-world software development workflows.
</details>
Figure 1: Comparison with existing agent benchmark and long context benchmark.
In parallel, many recent agent models introduce external context augmentation by retrieving relevant information from outside the current task trajectory (Chhikara et al. (2025); Li et al. (2025); Xu et al. (2025)). However, existing long context and memory related benchmarks still fall short of evaluating experience reuse. Benchmarks such as BrowseComp (Wei et al. (2025)), WideSearch (Wong et al. (2025)), GAIA (Mialon et al. (2023)), and LoCoMo (Maharana et al. (2024)) primarily assess information retrieval, tool use, or long context reasoning within isolated tasks. They evaluate whether an agent can access relevant information, but not whether it can retain, adapt, and reuse experience acquired from prior tasks to improve future problem solving.
As a result, the experience reuse capability of coding agents remains difficult to quantify from both agent centric and context based benchmark perspectives. Existing benchmarks largely emphasize solution correctness, offering limited insight into whether experience reuse leads to faster solving or reduced computational cost. This gap makes it essential to construct a new benchmark that explicitly evaluates experience reuse across tasks. An effective agent should not only solve tasks correctly, but also exploit prior experience to solve related tasks more efficiently. Accordingly, we propose to evaluate agents from multiple complementary perspectives, including task accuracy, experience aware solving time that reflects whether relevant prior tasks can be located and reused, and token efficiency that measures whether previous reasoning processes can be reused to reduce overall computational cost.
In this paper, we propose SWE-ContxetBench, a benchmark designed to bridge agent level software engineering evaluation and context reuse assessment. SWE-ContextBench is constructed based on SWE-Bench Lite, where related issues are systematically collected and organized to form task sequences with shared context. By explicitly modeling task relatedness, our benchmark enables direct evaluation of whether agents can locate, adapt, and reuse prior experience when solving new tasks. As a result, SWE-ContextBench offers a principled and realistic testbed for studying experience reuse in programming agents, complementing existing programming and context benchmarks.
## 2 SWE-ContxetBench
### 2.1 Motivation
An ideal programming agent should solve tasks correctly, efficiently, and with minimal computational cost. Beyond improving the base model capacity, a key capability of such an agent is the ability to reuse prior experience. When encountering a new problem, the agent should be able to identify previously solved similar cases, adapt relevant solutions, and apply them to the current task, rather than solving each problem entirely from scratch. This mirrors human problem solving behavior, where prior exposure to similar problems often leads to faster and more reliable solutions.
Experience reuse has two important implications. First, it can improve solution quality by reducing unnecessary or redundant reasoning steps. Second, it can significantly improve efficiency by shortening solving time and lowering computational cost. Once a relevant prior case is identified, many intermediate reasoning steps can be skipped or simplified, leading to faster convergence and reduced token usage. These benefits are particularly important for programming agents operating in realistic software engineering settings, where similar issues frequently recur across a codebase.
Despite the importance of experience reuse, existing benchmarks do not explicitly measure whether agents can exploit prior experience to improve efficiency. Most benchmarks evaluate task correctness in isolation, without distinguishing between agents that solve problems by reusing prior knowledge and those that repeatedly reason from scratch. This motivates the need for a benchmark that explicitly evaluates experience reuse and its impact on both performance and efficiency.
### 2.2 Desiderata: What should an ideal benchmark evaluate?
Motivated by the above observations, an ideal benchmark for evaluating programming agents should assess not only whether tasks are solved correctly, but also whether prior experience is effectively reused to improve efficiency. We identify three key evaluation dimensions. 1) Accuracy. Accuracy measures whether an agent produces correct solutions. This requires objective and quantitative criteria. Well maintained GitHub repositories provide a natural evaluation setting, as issues are associated with human verified fixes and validated through test suites. Newly added or modified tests offer a reliable mechanism to determine whether a proposed solution successfully resolves the issue. 2) Time efficiency. Time efficiency evaluates whether an agent can solve tasks more quickly by leveraging prior experience. Given a pool of previously solved related issues, an effective agent should be able to locate relevant cases and use them to reduce the overall solving time. This can be measured quantitatively through wall clock time or search behavior, such as whether relevant files or prior issues are identified during problem solving. 3) Cost efficiency. Cost efficiency measures the computational resources required to solve a task. When prior experience is successfully reused, the agent can skip redundant reasoning processes, leading to lower token usage and reduced computational cost. Token consumption thus serves as a practical and quantitative proxy for evaluating whether experience reuse translates into tangible efficiency gains. Together, these three dimensions provide a principled framework for evaluating programming agents. Accuracy ensures solution correctness, while time and cost efficiency capture whether agents can effectively reuse prior experience to solve related tasks faster and more economically. A benchmark designed around these criteria can therefore directly measure experience reuse, rather than treating all tasks as independent problems.
### 2.3 Data Construction
#### 2.3.1 Base Dataset Selection
We build our benchmark on SWE-Bench Lite Jimenez et al. (2023), which consists of 300 instances drawn from real-world GitHub repositories. Each instance includes a problem description in the form of a GitHub issue and the corresponding code changes made in pull requests and validated by repository test suites. Compared to the full SWE-Bench, SWE-Bench Lite significantly reduces evaluation cost while preserving realistic repository complexity and task difficulty, making it well suited for controlled agent evaluation at scale.
#### 2.3.2 Experience Trajectory Collection
For each instance in SWE-Bench Lite, we first run a base programming agent to solve the task and record the full reasoning and interaction trajectory, including tool calls, file navigation, and intermediate reasoning steps. These trajectories are stored as past experience and serve as the experience pool that agents may later retrieve from when solving related tasks. This design enables explicit evaluation of whether agents can leverage prior experience rather than repeatedly reasoning from scratch.
#### 2.3.3 Identification of Related Task Instances
To construct task sequences with shared context, we systematically analyze the pull request and issues associated with each SWE-Bench Lite instance. For each instance, we examine whether the corresponding pull request or issue references additional issues or pull requests and verify their resolution relationships. For each related case, we extract the issue description and the associated pull request that introduces the code changes. Specifically, we consider the following cases as related task instances to the to the SWE-Bench Lite:
- Multi-issue resolution: A single pull request resolves multiple issues, but only one appears in SWE-Bench Lite. The remaining issues are treated as additional task instances paired with the same pull request.
- Pull-request-to-issue references: A SWE-Bench Lite pull request references other issues. If resolved by the same pull request, they form related task instances. If resolved by different pull requests, each issue is paired with its corresponding resolver.
- Pull-request-only references: A SWE-Bench Lite pull request references another pull request rather than an issue. The corresponding issue resolved by the referenced pull request is identified and treated as a valid task instance.
- Issue-to-issue references: An issue references other issues. Each referenced issue is paired with its resolving pull request to form a related task instance.
- Issue-to-pull-request references: An issue references one or more pull requests. The resolved issues associated with those pull requests are used to construct related task instances.
- Multi-reference cases: An issue or pull request references other pull requests. Referenced pull requests with sufficiently detailed descriptions are treated as task instances, with their descriptions used as issue descriptions.
Across the dataset, we identify 89 such interdependent task instances. These subtypes reflect common software development patterns, including a single pull request resolving multiple issues, issues referenced and resolved across different pull requests, and chains of references spanning issues and pull requests. Each candidate task instance is manually verified to ensure that it corresponds to a meaningful software engineering task with a clear problem description and an identifiable resolution.
#### 2.3.4 Recursive Context Expansion
Starting from the 89 task instances identified above, we apply the same identification rules to each newly discovered issue or pull request. We examine their discussions to identify additional referenced issues or pull requests. This recursive process yields 10 additional interdependent task instances, forming new task sequences suitable for evaluating experience reuse.
#### 2.3.5 Resulting Benchmark Tasks
The final benchmark consists of collections of related software engineering tasks derived from real-world repositories. It includes 300 experience tasks, whose solution trajectories form a reusable experience pool, and 99 related tasks constructed through explicit dependency and reference analysis. Both experience and related tasks span 12 repositories, with repository-level statistics summarized in Table 1.
The 99 related tasks are derived from common software development patterns captured by the identification subtypes introduced in Section 2.3.3. Specifically, we identify 11 tasks from multi-issue resolution, where a single pull request resolves multiple issues. We identify 20 tasks from pull-request-to-issue references, including 11 issues resolved by the same pull request as the original experience task and 9 issues resolved by different pull requests. We further identify 13 tasks from pull-request-only references, where a pull request references another pull request and the corresponding resolved issue can be identified. In addition, we identify 27 tasks from issue-to-issue references, including 24 issues resolved by their own corresponding pull requests and 3 issues that share the same pull request as the original issue. We identify 9 tasks from issue-to-pull-request references, of which 5 correspond to a single new resolved issue and 4 reference multiple pull requests. Finally, we identify 9 tasks from multi-reference cases, where issues or pull requests reference other pull requests with sufficiently detailed descriptions and no explicit issue. Beyond these first-order relations, we identify 10 additional related tasks through recursive context expansion, reflecting second-order dependencies in issue and pull request discussions.
By preserving real codebases, realistic issue descriptions, and validated code changes, the benchmark enables direct measurement of whether agents can locate, adapt, and reuse prior experience when solving new but related programming tasks.
Table 1: Repository-level distribution of experience tasks and related tasks in SWE-ContextBench.
| Experience Tasks Related Tasks | 114 36 | 77 26 | 23 10 | 23 12 | 17 2 | 16 2 | 6 1 | 6 3 | 6 2 | 5 2 | 4 2 | 3 1 | 300 99 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
#### 2.3.6 Resulting Benchmark Structure
The experience pool consists of solution trajectories from 300 experience tasks, as described in Section 2.3.2. For the 99 identified related tasks, the dataset contains two main components: task construction data and test-based evaluation data.
Task construction. Each related task is derived from a GitHub pull request. For each task, we include the repository state before the fix (base_commit), the problem statement, and the code changes that resolve the problem. The base_commit corresponds to the base branch SHA of the pull request and represents the repository state prior to applying the fix.
Task instances are constructed using an automated pipeline that extracts key information from GitHub pull requests via the GitHub API. The problem statement is obtained by parsing the associated GitHub issue, including its title and description. For Django repositories, problem statements are retrieved directly from the Django Trac ticket system.
The ground-truth solution is obtained from the pull request’s unified diff and is separated into two components: a test_patch and a solution_patch. The test_patch contains modifications to test files, identified by file paths containing keywords such as “test”, “tests”, “e2e”, or “testing”. The solution_patch contains changes to implementation files. To ensure correct execution, we detect the appropriate Python version by analyzing repository configuration files (e.g., pyproject.toml, setup.py, setup.cfg) or, when unavailable, by inferring it from the pull request creation date.
Test-based evaluation. For evaluation, we construct a rigorous test-based validation framework. Starting from the base_commit, we create an isolated conda environment with the detected dependencies and run the existing test suite to obtain baseline results (results_before). We then apply the test_patch, which introduces tests that specify the expected behavior, followed by the solution_patch. After applying both patches, we re-run the test suite to obtain results_after.
Evaluation is based on two test sets. The FAIL_TO_PASS set consists of tests that were failing, erroring, or absent in results_before but pass in results_after, indicating that the fix successfully addresses the target issue. The PASS_TO_PASS set includes tests that pass both before and after patching, ensuring that the solution does not introduce regressions. Together, these criteria ensure that a valid solution both fixes the intended problem and preserves existing correct behavior.
On average, each of the 99 related tasks contains 5.09 FAIL_TO_PASS tests and 128.32 PASS_TO_PASS tests. This indicates that each task is typically validated by a small number of tests that directly capture the intended fix, alongside a much larger set of regression tests that ensure existing functionality is preserved. Table 2 reports the repository-level averages of FAIL_TO_PASS and PASS_TO_PASS tests across all related tasks.
Table 2: Repository-level average numbers of FAIL_TO_PASS and PASS_TO_PASS tests across the 99 related tasks, along with their overall averages.
| FAIL_TO_PASS PASS_TO_PASS Overall | 4.39 115.64 120.03 | 2.69 122.77 125.46 | 4.50 118.30 122.80 | 1.58 145.42 147.00 | 1.50 79.50 81.00 | 1.00 28.00 29.00 | 4.00 170.00 174.00 | 1.67 78.33 80.00 | 2.00 93.50 95.50 | 8.50 577.70 586.00 | 87.50 150.00 237.50 | 2.00 159.00 161.00 | 5.09 128.32 133.41 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
## 3 Experimental
### 3.1 Experimental Setup
To construct the experience pool, we run a base programming agent based on Claude Code (Claude Sonnet 4.5) on the 300 experience tasks. For each task, the agent is provided only with the repository name, base commit, and problem statement. The full interaction trajectory, including file navigation and intermediate reasoning, is recorded as reusable experience. All experience tasks are executed independently in isolated environments to prevent information leakage across tasks.
When evaluating the 99 related tasks, each task is also executed independently in a fresh environment. Experience reuse is enabled only through explicit retrieval from the experience pool, with no implicit state carryover between runs. For each task, the agent is provided with the repository name, base commit, and problem statement. A clean testbed is created by cloning the repository and checking out the base commit, followed by dependency installation. The agent then analyzes the problem statement and generates code modifications within the testbed, excluding test files. All changes are staged and extracted as a unified diff. The resulting patch is saved, and the testbed is removed after completion. This setup ensures isolated and reproducible evaluation across all tasks.
### 3.2 Experience Reuse Settings
We evaluate performance under five settings that differ in how prior experience is exposed to the agent. These settings allow a controlled comparison of prediction performance across different experience access and retrieval configurations.
- No-Experience (Baseline): The agent is provided only with the repository name, base commit, and problem statement. It has no access to the experience pool.
- Free Experience Reuse: The agent is given full access to the original experience pool and may decide whether to retrieve and use any past experience when solving the task.
- Oracle Experience Reuse: The agent is explicitly provided with the most relevant past experience trajectory, identified using the factual task relationships defined in Section 2.3.3.
- Free Summary Reuse: We construct a summary experience pool by extracting the final summary section from each experience trajectory. The agent is given full access to this summarized pool and may decide whether and which summaries to use.
- Oracle Summary Reuse: The agent is explicitly provided with the summary of the most relevant past experience, identified based on the known task relationships.
The summary files contain an average of 204.5 words, whereas the full experience trajectories contain an average of 24,765 words, resulting in a substantially more compact representation of prior experience.
### 3.3 Prediction Accuracy
Table 3: Prediction accuracy on 99 SWE-ContxetBench related tasks under different experience reuse settings. Metrics include patch applicability, test-level and task-level pass rates for bug-fixing (FAIL_TO_PASS) and regression (PASS_TO_PASS) tests, and the overall SWE-ContxetBench resolution rate.
| No-Experience (Baseline) Free Experience Reuse Oracle Experience Reuse | 3 2 4 | 19.84% 22.36% 21.19% | 99.14% 97.16% 99.45% | 27.08% 26.80% 28.42% | 88.54% 85.57% 89.47% | 26.26% 26.26% 27.27% |
| --- | --- | --- | --- | --- | --- | --- |
| Free Summary Reuse | 7 | 20.00% | 97.40% | 23.91% | 85.87% | 22.22% |
| Oracle Summary Reuse | 6 | 27.48% | 97.44% | 36.56% | 84.95% | 34.34% |
We evaluate five approaches on 99 SWE-ContxetBench related task instances. Table 3 reports results across six metrics. Patch N/A counts instances where the generated patch could not be applied; these instances are excluded from all other metrics. FAIL_TO_PASS Tests and PASS_TO_PASS Tests report test-level success rates for bug-fixing and regression tests, respectively. Their task-level counterparts, FAIL_TO_PASS Tasks and PASS_TO_PASS Tasks, measure the percentage of instances in which all tests of the corresponding category pass. Resolved is the official SWE-ContxetBench resolution rate over all 99 instances, where an instance is resolved if all FAIL_TO_PASS tests pass.
Oracle Summary Reuse achieves the highest resolution rate at 34.34%, compared to 26.26% for the No-Experience baseline. In contrast, Oracle Experience Reuse, which provides the full prior execution trajectory, yields only a modest improvement to 27.27%. This suggests that concise summaries are more effective than raw execution traces when the relevant experience is known. The gap between Oracle and Free variants is much larger for summaries than for full experiences. Oracle Summary Reuse outperforms Free Summary Reuse by 12.12% points, whereas the difference between Oracle and Free Experience Reuse is only 1.01% points. Free Summary Reuse is the only setting that underperforms the baseline, while Free Experience Reuse matches it, indicating that incorrectly selected summaries can be misleading, whereas irrelevant full experiences are less harmful.
Patch application failures are comparable across methods, ranging from 2 to 7 instances, with Free Summary Reuse exhibiting the most failures. All approaches maintain high PASS_TO_PASS test pass rates (97–99%), indicating that patches rarely introduce regressions. At the task level, 85–90% of instances remain regression-free, although Oracle Summary Reuse shows a lower PASS_TO_PASS Tasks score, suggesting a trade-off between aggressive bug fixing and preserving existing behavior.
Finally, test-level FAIL_TO_PASS rates (19–27%) are consistently lower than task-level rates (24–37%). This reflects the all-or-nothing nature of task resolution: resolved instances pass all bug-fixing tests, while unresolved ones fail most of them. Oracle Summary Reuse exhibits the largest gap, consistent with it resolving the most instances.
### 3.4 Time Efficiency
We measure wall-clock running time for each approach when solving the 99 related tasks, resulting in 495 total runs. All tasks are executed under identical evaluation settings, and running time is measured from environment setup to patch generation.
Among the five approaches, Oracle Summary Reuse achieves the lowest average running time, at 356.95 seconds per task. It is followed by Free Summary Reuse (376.77 s), the No-Experience baseline (381.95 s), Oracle Experience Reuse (399.43 s), and Free Experience Reuse (406.77 s). Relative to Oracle Summary Reuse, Free Experience Reuse is 13.96% slower on average, while Free Summary Reuse trails by only 5.55%.
Median running times across all approaches are closely clustered between 331 and 356 seconds, suggesting that average differences are driven primarily by tail behavior rather than uniform slowdowns. In particular, Free Experience Reuse exhibits the highest variance and the largest maximum running time, exceeding 2,100 seconds in the worst case. This indicates that autonomous experience selection can occasionally lead to prolonged exploration before converging on a solution. In contrast, Oracle Summary Reuse shows the most stable runtime distribution, consistent with the efficiency benefits of concise and correctly selected context.
The runtime advantage of oracle-guided summary reuse becomes more pronounced for harder tasks. When grouping tasks by baseline runtime as a proxy for difficulty, oracle summary reuse offers limited gains on low-complexity tasks but yields substantial speedups on more complex ones. For the most time-consuming tasks, it reduces average runtime by over 60%, corresponding to several minutes saved per instance. This suggests that precise and compact experience reuse is especially beneficial as task complexity increases.
### 3.5 Cost Efficiency
We analyze token usage and estimated API cost across the five experience reuse settings evaluated on SWE-ContextBench related tasks. Across all settings, total token consumption is dominated by cache read tokens, which account for more than 97% of total usage. This reflects the agentic workflow, in which the model repeatedly accesses repository context during issue resolution.
Oracle Summary Reuse achieves the lowest average cost at $0.77 per instance and the fewest total tokens, primarily due to its compact prompts and reduced cache usage. In contrast, Free Experience Reuse incurs the highest average cost at $0.98 per instance, representing a 27.3% increase over Oracle Summary Reuse. This increase is driven by substantially higher cache creation and cache read volumes, indicating more extensive repository exploration.
The No-Experience (Baseline) setting lies between these extremes, with an average cost of $0.79 per instance. Oracle Experience Reuse shows only a modest cost increase relative to the baseline, suggesting that providing full experience trajectories does not substantially reduce exploration overhead. Free Summary Reuse introduces a moderate cost increase to $0.85 per instance, reflecting additional cache reads despite the shorter summarized context.
Across all settings, input and output tokens contribute only a small fraction of total usage, averaging fewer than 600 and 200 tokens per instance, respectively. Cache usage is therefore the primary driver of cost differences. Approaches that rely on autonomous experience selection, particularly Free Experience Reuse and Free Summary Reuse, tend to trigger more extensive repository access, leading to higher token consumption and cost.
## 4 Conclusion
This paper presents SWE-ContextBench , a benchmark that enables direct evaluation of experience reuse in repository level programming agents. By organizing related software engineering tasks into contextually linked sequences, the benchmark moves beyond isolated task evaluation and captures an important aspect of real world development, namely learning from prior solutions. Through systematic experiments, we show that experience reuse can improve both effectiveness and efficiency when experience is compactly represented and correctly selected. Oracle guided summary reuse achieves the highest resolution rates and the lowest runtime and cost, while autonomous reuse without reliable selection offers limited benefits and may degrade performance. These results indicate that experience reuse is not inherently beneficial and that its impact depends on how experience is represented and retrieved. SWE-ContextBench complements existing programming and memory benchmarks by providing a controlled setting to study experience reuse across tasks. We hope this benchmark will support future research on memory augmented agents, experience retrieval strategies, and efficient software engineering systems that learn cumulatively rather than solving each task from scratch.
## References
## References
- J. Austin, A. Odena, M. Nye, M. Bosma, H. Michalewski, D. Dohan, E. Jiang, C. Cai, M. Terry, Q. Le, et al. (2021) Program synthesis with large language models. arXiv preprint arXiv:2108.07732. Cited by: §1.
- M. Chen (2021) Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374. Cited by: §1.
- P. Chhikara, D. Khant, S. Aryan, T. Singh, and D. Yadav (2025) Mem0: building production-ready ai agents with scalable long-term memory. arXiv preprint arXiv:2504.19413. Cited by: §1.
- P. Chhikara, J. Zhang, F. Ilievski, J. Francis, and K. Ma (2023) Knowledge-enhanced agents for interactive text games. In Proceedings of the 12th Knowledge Capture Conference 2023, pp. 157–165. Cited by: §1.
- C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan (2023) Swe-bench: can language models resolve real-world github issues?. arXiv preprint arXiv:2310.06770. Cited by: §1, §2.3.1.
- Z. Li, S. Song, H. Wang, S. Niu, D. Chen, J. Yang, C. Xi, H. Lai, J. Zhao, Y. Wang, et al. (2025) MemOS: an operating system for memory-augmented generation (mag) in large language models. arXiv preprint arXiv:2505.22101. Cited by: §1.
- T. Liu, C. Xu, and J. McAuley (2023) Repobench: benchmarking repository-level code auto-completion systems. arXiv preprint arXiv:2306.03091. Cited by: §1.
- A. Maharana, D. Lee, S. Tulyakov, M. Bansal, F. Barbieri, and Y. Fang (2024) Evaluating very long-term conversational memory of llm agents. arXiv preprint arXiv:2402.17753. Cited by: §1.
- G. Mialon, C. Fourrier, T. Wolf, Y. LeCun, and T. Scialom (2023) Gaia: a benchmark for general ai assistants. In The Twelfth International Conference on Learning Representations, Cited by: §1.
- J. Wei, Z. Sun, S. Papay, S. McKinney, J. Han, I. Fulford, H. W. Chung, A. T. Passos, W. Fedus, and A. Glaese (2025) Browsecomp: a simple yet challenging benchmark for browsing agents. arXiv preprint arXiv:2504.12516. Cited by: §1.
- R. Wong, J. Wang, J. Zhao, L. Chen, Y. Gao, L. Zhang, X. Zhou, Z. Wang, K. Xiang, G. Zhang, et al. (2025) Widesearch: benchmarking agentic broad info-seeking. arXiv preprint arXiv:2508.07999. Cited by: §1.
- W. Xu, Z. Liang, K. Mei, H. Gao, J. Tan, and Y. Zhang (2025) A-mem: agentic memory for llm agents. arXiv preprint arXiv:2502.12110. Cited by: §1.
- J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press (2024) Swe-agent: agent-computer interfaces enable automated software engineering. Advances in Neural Information Processing Systems 37, pp. 50528–50652. Cited by: §1.
- H. Yu, T. Chen, J. Feng, J. Chen, W. Dai, Q. Yu, Y. Zhang, W. Ma, J. Liu, M. Wang, et al. (2025) MemAgent: reshaping long-context llm with multi-conv rl-based memory agent. arXiv preprint arXiv:2507.02259. Cited by: §1.
- A. Zeng, X. Lv, Q. Zheng, Z. Hou, B. Chen, C. Xie, C. Wang, D. Yin, H. Zeng, J. Zhang, et al. (2025) Glm-4.5: agentic, reasoning, and coding (arc) foundation models. arXiv preprint arXiv:2508.06471. Cited by: §1.
- Z. Zhou, A. Qu, Z. Wu, S. Kim, A. Prakash, D. Rus, J. Zhao, B. K. H. Low, and P. P. Liang (2025) MEM1: learning to synergize memory and reasoning for efficient long-horizon agents. arXiv preprint arXiv:2506.15841. Cited by: §1.