micro-swe-agent 1.0.0.dev3

Nano SWE Agent - A simple AI software engineering agent

The 100 line AI agent that solves GitHub issues & more

In 2024, SWE-bench & SWE-agent helped kickstart the agentic AI for software revolution. In 2025, we ask: What if the agent was 100x smaller, and still worked nearly as well?

micro is for

• 🧪 Researchers who want to benchmark, fine-tune or RL without assumptions, bloat, or surprises
• 🧑‍💻 Hackers & power users who like their tools like their scripts: short, sharp, and readable
• 🐳 Engineers who want something trivial to sandbox & to deploy anywhere

Here's some details:

• 🐜 Minimal: Just 100 lines of python (+100 total for env, model model, script) — no fancy dependencies!
• 💪 Powerful: Resolves XX% of GitHub issues in the SWE-bench verified benchmark.
• 🤗 Friendly: Comes with two convenient UIs that will turn this into your daily dev swiss army knife!
• 🍀 Environments: In addition to local envs, you can use docker, podman, singularity, apptainer, and more
• 🎓 Cutting edge: Built by the Princeton & Stanford team behind SWE-bench and SWE-agent.

More motivation (for research)

SWE-agent jump-started the development of AI agents in 2024. Back then, we placed a lot of emphasis on tools and special interfaces for the agent. However, one year later, a lot of this is not needed at all to build a useful agent! In fact, micro-SWE-agent

• Does not have any tools other than bash — it doesn't even use the tool-calling interface of the LMs. This means that you can run it with literally any model. When running in sandboxed environments you also don't need to to take care of installing a single package — all it needs is bash.
• Has a completely linear history — every step of the agent just appends to the messages and that's it. So there's no difference between the trajectory and the messages that you pass on to the LM.
• Executes actions with subprocess.run — every action is completely independent (as opposed to keeping a stateful shell session running). This makes it trivial to execute the actions in sandboxes (literally just switch out subprocess.run with docker exec) and to scale up effortlessly.

This makes it perfect as a baseline system and for a system that puts the language model (rather than the agent scaffold) in the middle of our attention.

More motivation (as a tool)

Some agents are overfitted research artifacts. Others are UI-heavy tools, highly optimized for a specific user experience. Both variants are hard to understand.

micro wants to be

• Simple enough to understand at a glance
• Convenient enough to use in daily workflows
• Flexible to extend

A hackable tool, not a black box.

Unlike other agents (including our own swe-agent), it is radically simpler, because it

• Does not have any tools other than bash — it doesn't even 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).

Simple UI (micro)	Textual UI (micro2)
Python bindings	More in the docs
agent = DefaultAgent( LitellmModel(model_name=...), LocalEnvironment(), ) agent.run("Write a python sudoku game for me")	TBD

🔥 Try it!

(This will get simpler once we publish to pypi)

pip install pipx
# Simple UI
pipx run --spec git+ssh://[e-mail]/SWE-agent/micro-swe-agent micro
# Textual UI
pipx run --spec git+ssh://[e-mail]/SWE-agent/micro-swe-agent micro2

Details

pipx will install micro-swe-agent in an isolated environment and directly run it. If the invocation doesn't immediately work, you might need to run pipx ensurepath. After the first time, it's enough to just run pipx run micro-swe-agent.

Example prompts

• Implement a Sudoku solver in python in the sudoku folder. Make sure the codebase is modular and well tested with pytest.
• Please run pytest on the current project, discover failing unittests and help me fix them. Always make sure to test the final solution.
• Help me document & type my codebase by adding short docstrings and type hints.

🚀 Developer version

git clone https://github.com/SWE-agent/micro-swe-agent.git
cd micro-swe-agent
pip install -e .

And welcome your new friend:

# Simple UI (microsweagent/run/local.py)
micro
# Textual UI (microsweagent/run/local2.py)
micro2

⚙️ Configure

All global configuration can be either set as environment variables, or in the .env file (the exact location is printed when you run micro).

# set default config for micro
MSWEA_LOCAL_CONFIG_PATH="/path/to/your/own/config"
# set default model
MSWEA_MODEL_NAME="claude-sonnet-4-20250514"

⚡️ Power up

We provide several different entry points to the agent, for example hello world, or the default when calling micro.

Want to cook up your custom version and the config is not enough? Just follow the recipe below:

1. What's the control flow you need? Pick an agent class (e.g., simplest example, with human in the loop)
2. How should actions be executed? Pick an environment class (e.g., local, or docker)
3. How is the LM queried? Pick a model class (e.g., litellm)
4. How to invoke the agent? Bind them all together in a run script, possibly reading from a config (e.g., hello world, or micro entry point)

We aim to keep all of these components very simple, but offer lots of choice between them -- enough to cover a broad range of things that you might want to do.

You can override the default entry point by setting the MSWEA_DEFAULT_RUN environment variable to the import path of your run script.

❤️ Contributing

We happily accept contributions!

Areas of help

• Support for more models (anything where litellm doesn't work out of the box)
• Documentation, examples, tutorials, etc.
• Support for more environments & deployments (e.g., run it as a github action, etc.)
• Take a look at the issues and see if there's anything you'd like to work on!

Design & Architecture

• micro-swe-agent aims to stay minimalistic & hackable
• To extend features, we prefer to add a new version of the one of the four components above, rather than making the existing components more complex
• Components should be relatively self-contained, but if there are utilities that might be shared, add a utils folder (like this one). But keep it simple!
• If your component is a bit more specific, add it into an extra folder (like this one)
• Our target audience is anyone who doesn't shy away from modifying a bit of code (especially a run script) to get what they want
• Therefore, not everything needs to be configurable with the config files, but it should be easy to use with a run script
• Many LMs write very verbose code -- please clean it up! Same goes for the tests. They should still be concise and readable.
• Please install pre-commit (pip install pre-commit && pre-commit install) and run it before committing. This will enforce our style guide.