Repos Worth Reading · 2026-09-05 · 1,433 words · 7 min read

SWE-agent and the agent-computer interface idea, paper and repo

What SWE-agent's ACI paper argued in 2024, what the repo's tools directory looks like at commit 3ea751c0, and why its own authors now recommend a 100-line successor.

swe-agent mini-swe-agent agent-computer interface swe-bench

Two repositories from the same group tell the story of how coding agents changed between 2024 and 2026. SWE-agent argued that a language model needs an interface designed for it, and built one. Its successor, mini-swe-agent, argues that a capable model needs almost nothing but bash, and the group's own docs now point newcomers to the successor. This is a reading of the paper, both repositories at named commits, and the one file that contains the whole loop.

The paper's claim

The SWE-agent paper (arXiv:2405.15793, by John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press) makes a claim about users, not models: "LM agents represent a new category of end users with their own needs and abilities, and would benefit from specially-built interfaces." The analogy in the abstract is to IDEs. Humans doing complex tasks get purpose-built tools; the paper proposes that language model agents should too, and calls the result an agent-computer interface, or ACI. The abstract says the interface "significantly enhances an agent's ability to create and edit code files, navigate entire repositories, and execute tests and other programs," and reports "state-of-the-art performance on both with a pass@1 rate of 12.5% and 87.7%, respectively," the two benchmarks being SWE-bench and HumanEvalFix.

Twelve and a half percent on the full SWE-bench test set was a big number in spring 2024. The original SWE-bench paper had reported that its best model resolved 1.96% of the 2,294 issues, a figure discussed in SWE-bench explained. SWE-agent's contribution was to show that the gap was partly interface, not only model.

What an ACI looks like in the repository

Read on 2026-09-05, SWE-agent/SWE-agent had 20,240 stars, 2,213 forks, 98 open issues, an MIT license, a latest release of v1.1.0 (2025-05-22), and a latest commit 3ea751c087f3 dated 2026-07-16 with the message "fix: map multimodal subset to sb-cli's swe-bench-m (#1458)". The repository description still carries the NeurIPS 2024 tag.

The tools/ directory at that commit is the ACI in file-system form. The listing I read contains fifteen entries: diff_state, edit_anthropic, filemap, forfeit, image_tools, multilingual_setup, registry, review_on_submit_m, search, submit, web_browser, windowed, windowed_edit_linting, windowed_edit_replace, and windowed_edit_rewrite. Read the names as design decisions:

• windowed and the three windowed_edit_* bundles are the paper's idea that a model should see a file through a window of lines rather than all at once, and should edit by line range. windowed_edit_linting is the one the paper made a point of: run a linter on each edit and refuse edits that break syntax, so the agent does not compound a typo across ten steps.
• search and filemap are the navigation half: find a string across the repository, and summarize a file's structure, rather than letting the model cat everything.
• submit, forfeit, and review_on_submit_m are the end of the episode: declare done, give up, or review before declaring done.
• edit_anthropic is an adapter to a vendor's own editor tool format, a sign that by 2025 the model providers were shipping their own ACIs.
• image_tools, web_browser, and multilingual_setup extend the interface beyond Python text.

The docs describe SWE-agent as letting "your language model of choice (e.g. GPT-4o or Claude Sonnet 4) to autonomously use tools to fix issues in real GitHub repositories," and as "Configurable & fully documented: Governed by a single yaml file." The config page gives the shape of that file: an agent section with templates (system prompt and per-instance instructions), tools (environment variables, bundles, registry variables, bash tool settings), history_processors (examples on the page are cache_control and image_parsing), and parse_function (for example function_calling). Bundles are referenced by path, tools/registry and tools/edit_anthropic being the examples shown. The default is config/default.yaml, and the page notes you can pass several files, "--config config/default.yaml --config my_config.yaml", with options "merged in a nested way."

agent:
  templates:
    system_template: ...
    instance_template: ...
  tools:
    bundles:
      - path: tools/registry
      - path: tools/edit_anthropic
    parse_function:
      type: function_calling
  history_processors:
    - type: cache_control

That sketch is my rendering of the page's structure, not a copy of default.yaml, which I did not open. The point is the shape: the interface is data, swapped per model and per task, and the agent loop is generic.

The successor that removes the interface

The same docs "Getting Started" page now says, in a callout, "We now recommend mini-swe-agent instead of SWE-agent: Same performance, much more simple & flexible." Read on 2026-09-05, SWE-agent/mini-swe-agent had 6,969 stars, 974 forks, 60 open issues, an MIT license, a latest release of v2.4.6 (2026-07-23), and latest commit 04d809ceab9d (2026-09-03). Its README frames the question directly: "What if our agent was 100x simpler, and still worked nearly as well?"

The README's list of what mini is: "Minimal: Just some 100 lines of python for the agent class," "Performant: Scores >74% on the SWE-bench verified benchmark; starts much faster than Claude Code," "Deployable: Supports local environments, docker/podman, singularity/apptainer, bublewrap, contree, and more," and "Compatible: Supports all models via litellm, openrouter, portkey, and more." The research motivation section is the direct answer to the 2024 paper: "Back then, we placed a lot of emphasis on tools and special interfaces for the agent. However, one year later, as LMs have become more capable, a lot of this is not needed at all to build a useful agent." Three design rules follow, and I quote them because each undoes an ACI decision:

• "Does not have any tools other than bash — it doesn't even need to use the tool-calling interface of the LMs."
• "Has a completely linear history — every step of the agent just appends to the messages and that's it."
• "Executes actions with subprocess.run — every action is completely independent (as opposed to keeping a stateful shell session running)."

The third rule is the one the README calls "a big deal": with no persistent shell, running in a sandbox is "literally just switch out subprocess.run with docker exec."

The whole loop in one file

I fetched src/minisweagent/agents/default.py from main on 2026-09-05. Its AgentConfig holds the system and instance templates, a step limit, a cost limit, a wall-clock limit, a threshold for consecutive format errors, and output paths. DefaultAgent.run() seeds the messages with the system and user prompts, then calls step() until a message with role == "exit" appears. Each step() calls query() for a model response and then execute_actions(), which hands each action in the response's extra["actions"] list to env.execute() and appends the formatted output as an observation message.

The termination conditions are checked inside query() before the call counter increments, and they are plain comparisons:

The three comparisons below are my paraphrase of the checks in query(); any one of them ends the run.

0 < config.step_limit <= n_calls
0 < config.cost_limit <= cost
0 < config.wall_time_limit_seconds <= elapsed_seconds

A FormatError (the model did not produce a parseable action) charges the cost and increments an error counter, and the run ends after max_consecutive_format_errors. The trajectory is serialized with the model stats, config, exit status, submission, and full message list in a format the file names "mini-swe-agent-1.1". Those four limits are the entire budget model of the agent, and they are the starting point for the stopping rules in when to stop the agent.

What changed between 2024 and 2026

Reading the two repositories side by side, three things changed. First, where the interface lives: in 2024 it was fifteen tool bundles the harness authors wrote; in 2026 it is the shell the model already knows, plus whatever the model provider ships as native tools (edit_anthropic is the bridge between the eras). Second, what the harness is responsible for: SWE-agent managed a stateful session with windowed views and linting; mini-swe-agent manages a message list and four limits. Third, the evidence: the paper's 12.5% on the full test set and the README's ">74%" on the 500-task Verified subset are not the same benchmark, and the second number is a README claim I did not reproduce, so I record it as a claim rather than a result. Even with that caveat, the group that invented the ACI now says most of it is unnecessary for current models, and that is the finding.

What did not change is the shape of the loop: prompt, model call, action, observation, repeat, with a budget and an exit. That shape is the subject of what a coding-agent harness actually is, and mini-swe-agent's default.py is the shortest real implementation of it I have read.

What I did not verify: I did not run either agent in this session. The docs pages are the live versions on 2026-09-05; the repository metadata, the tools/ listing, and the README are pinned to the commits named above, and default.py was read from main on the same day.