SWE-agent: a yaml-driven agent interface, an EnIGMA mode still on 0.7, and a README that points elsewhere

The README opens by telling you to use mini-swe-agent instead

The first thing the README does is redirect you. A warning at the top states that most current development effort is on mini-swe-agent, that mini-swe-agent has superseded SWE-agent, and that it matches the performance of SWE-agent while being much simpler. The project's own general recommendation is to use mini-swe-agent instead of SWE-agent going forward, with a FAQ link for the details of the differences. That framing sets the ceiling on what this repository is today: a complete, working implementation held for research and reproduction, not the place where new work lands. The news list shows the same drift, with the July 24 item crediting mini-swe-agent with 65% on SWE-bench verified in 100 lines of python. If you are choosing between the two today, the maintainers have already answered, and anything you build on the 1.0 line here is work you may end up porting.

EnIGMA is pinned to 0.7 while the 1.0 line moves on

The cybersecurity mode is versioned separately from everything else. The README names EnIGMA as a mode for solving offensive cybersecurity capture the flag challenges, points to a leaderboard for its results, and then gives a version instruction in the same breath: please use SWE-agent 0.7 while EnIGMA is updated for 1.0. That is a mode living on an older tag than the main release line, which sits at v1.1.0. For a reader the consequence is concrete. If you want the capture the flag capability, you are checking out a 0.7 tree, not the current default branch, and you are running it against a dependency set that has moved since. The two halves of the project therefore have different version answers, and the README does not spell out what the 1.0 rewrite of EnIGMA changes beyond saying it is in progress.

Python 3.11 is the floor, and two litellm releases are excluded

The packaging metadata is narrow in two separate places. `pyproject.toml` sets `requires-python = ">=3.11"`, and the classifiers name Python 3.11, 3.12, and 3 only, alongside OS Independent and Intended Audience :: Developers. The version floor is a hard stop, so on 3.10 there is no supported install path, and the classifiers stop at 3.12 even though the floor is a minimum rather than a cap. The second narrowing sits in the dependency list, where the language model gateway is pinned as `litellm>=1.44.12,!=1.82.7,!=1.82.8`. Two specific releases are excluded rather than a whole range, so an environment that already holds 1.82.7 or 1.82.8 has to move litellm to another version.

`GITHUB_TOKEN` decides what the agent can do to your repositories

`.env.example` is four comment lines and one variable, and those comments decide the blast radius. `GITHUB_TOKEN` is described as used for GitHub API operations: querying repository metadata, cloning private repos, and opening pull requests. The scopes are spelled out as a pair, with `public_repo` for public repos covering read metadata and opening pull requests, and `repo` for private repos covering the same plus private repo access. Read that as a boundary rather than a detail. The minimum token that lets the agent act on public code is not the token that lets it clone and push into private code, and that token is a credential handed to a loop whose behaviour lives in a yaml file you write. The file ships empty, so the decision is deferred to whoever sets up the checkout.

Trajectories on disk, and a second citation if you used the summarizer

Two details point at how runs are recorded and reused. The release note for v1.1.0 reads 10s of thousands of training trajectories, and the top-level tree holds a `trajectories/` directory next to `config/`, `sweagent/`, `tests/`, and `tools/`, which is the shape of a project that writes its runs to disk instead of only to a terminal. There is also a usage condition that is easy to miss: if you used the summarizer, the interactive commands, or the offensive cybersecurity capabilities in SWE-agent, you are asked to cite the EnIGMA paper as well as the main one. So parts of the tool carry a different attribution obligation than the issue fixing headline implies, and the summarizer and the interactive commands are named as separate capabilities with their own requirement attached to them.

The newest tag is v1.1.0 from May 2025, and master kept moving

The tags and the default branch tell different stories about activity. The three most recent releases are v1.0.0 on 2025-02-13, v1.0.1 on 2025-02-28, and v1.1.0 on 2025-05-22, while the last push to the default branch is dated 2026-10-26. The repository is not archived, so this is not abandonment, it is a release cadence that stopped while commits continued. For anyone pinning a version the effect is straightforward: a tagged release gives you a tree from May 2025 and none of the work since, and for anyone reproducing a paper result those two choices differ by more than a year of commits. The README names no nightly or rolling channel to close that gap, so the choice is between an old tag and an unreleased default branch.

No install command here, only a codespace and four documentation links

There is no install command to copy out of the README. The entry points offered are a browser codespace at codespaces.new/SWE-agent/SWE-agent, then four documentation links: installation from source, hello world from the command line, benchmarking on SWE-bench in batch mode, and the FAQ. Everything else about running it lives behind those links, and the repository is documentation heavy in a way that confirms this. There is a `docs/` directory with `mkdocs.yml`, a build-docs workflow, a check-links-periodic workflow, and `mlc_config.json` for link checking. The operational detail is maintained as a docs site rather than in the README, so the README is best read as a map rather than a manual. It also means version specific setup advice ages in one place and not the other.

The dependency list is a web stack, not just a command line tool

The dependency list is longer than the yaml driven framing suggests. Alongside the agent scaffolding of `simple-parsing`, `rich`, `rich-argparse`, and `pydantic`, `pyproject.toml` pulls in `datasets`, `numpy`, and `pandas`, `ruamel.yaml` for configuration, `tenacity` for retries, `unidiff` for diffs, `GitPython` and `ghapi` for GitHub work, `python-dotenv` with `pydantic_settings` for settings, and then `flask`, `flask-cors`, and `flask-socketio`. That last group is a web stack, present in a package whose headline feature is a single yaml file and a command line agent. The consequence is an install footprint far heavier than the config story implies, and a project that ships HTTP and socketio components whether or not the interface you plan to use ever touches them.

Editorial conclusion

SWE-agent is a defensible choice for research, reproduction, and the batch benchmarking path, and a poor choice for anything new, because the maintainers direct new work to mini-swe-agent. Before you commit, check three things: whether your Python is 3.11 or newer, whether your environment holds litellm 1.82.7 or 1.82.8, since both are excluded, and which GitHub token scope you are willing to put in front of an autonomous loop. If the EnIGMA capture the flag mode is the reason you are here, you are on 0.7, not on the current default branch.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes