SWE-agent

Last reviewed Aug 26, 2026 · 801 words

SWE-agent is a research harness, not a coding assistant, and it makes sense to self-host for one reason: you want an autonomous agent to work through a batch of issues against a repository, in reproducible Docker sandboxes, with a model of your choosing and a hard cost cap. That is a narrower job than the 20,000 stars suggest. If what you want is to sit at a terminal and pair with a model on your own code, Aider does that better and costs less per hour of your attention.

What it actually does when you run it

You hand it a repository and a problem statement, typically a GitHub issue URL. It clones the repo into a container, then loops: the model reads files through a purpose-built "agent-computer interface" of commands like open, scroll, search and edit that keep output short enough to fit in context, runs tests, and keeps going until it submits a patch or hits a limit. The output is a diff plus a trajectory file recording every step, which is the artefact researchers care about and the thing you should read when a run goes sideways. The project comes from the Princeton and Stanford group behind SWE-bench, so the defaults are tuned for benchmark runs rather than polish, exactly as the catalogue's "research focus" note warns.

Docker is the hard dependency; a GPU is not

The agent process itself is Python and light; the 2 GB RAM figure covers it plus one sandbox container. Each task gets a fresh container through the SWE-ReX execution layer, so the host needs a Docker socket the agent can reach and enough disk for repo checkouts and image layers. Nothing here needs a GPU unless you also host the model. A minimal run looks like this:

pip install sweagent
sweagent run \
  --agent.model.name=gpt-4o \
  --agent.model.per_instance_cost_limit=2.00 \
  --env.repo.github_url=https://github.com/SWE-agent/test-repo \
  --problem_statement.github_url=https://github.com/SWE-agent/test-repo/issues/1

The per_instance_cost_limit flag is the one to never omit. Agent loops re-send growing context on every turn, and a task the model cannot solve will happily burn through the cap and stop, which is the correct outcome.

Local models work in principle and disappoint in practice

Model names go through LiteLLM, so an Ollama endpoint or any OpenAI-compatible server is a flag away (--agent.model.name=ollama/model-name with an api_base pointing at your host). The honest result, at least on the hardware most self-hosters own: models small enough to run locally lose the thread of a 30-turn task, misuse the edit commands, and loop. The agent is only as good as the model's instruction following over long horizons, and the gap between a frontier API model and a quantised 14B on a consumer GPU is wider here than in chat. Local is worth it for cost-free experimentation with the scaffolding, or when the repo cannot leave the building. For results, budget for an API.

Batch mode is the self-hosting payoff

sweagent run-batch takes a set of instances (SWE-bench subsets are the built-in example, but a list of your own issues works) and runs them with a configurable number of parallel workers, writing trajectories and patches per instance. That is the workflow where a home server earns its keep: point it at every open "good first issue" in your project on a Friday evening, set a total cost limit, and review a folder of candidate patches on Monday. Treat the patches as pull requests from an enthusiastic contractor who did not run the full suite, because that is what they are. If you want to inspect the token spend and traces properly, routing calls through Langfuse is a small addition.

Where it sits next to the alternatives

OpenHands is the general-purpose agent with a web UI and a broader remit: browsing, long sessions, chat. Aider is the interactive terminal partner. SWE-agent is the batch, headless, reproducible one, and the project's smaller sibling mini-SWE-agent strips the scaffolding down to a tiny codebase for when you want to understand or modify the loop. Pick by workflow, not by benchmark table.

What I'd do

Install it on the box that already runs Docker, run it in batch against my own backlog with per_instance_cost_limit at a couple of dollars and a total cap I would not mind losing, and keep Aider for daily work. Skip the local-model route until you have a 24 GB-class GPU and a reason. It is a superb tool for exactly what it was built for; do not expect it to be Devin.