mini-swe-agent
A minimal Bash-driven software-engineering agent for GitHub issues and command-line tasks.
Per-dimension scores and reasoning
Evidence shows: dependencies explicitly exclude known vulnerable versions of litellm (1.82.7/8) and openai (1.100.0/1.100.1) with reasons, indicating attention to dependency security. However, no user confirmation mechanism (e.g., before command execution) or rollback mechanism is found. Data flow transparency: README describes linear history but does not explicitly state how data is transmitted to external models. Sensitive data handling is not mentioned. External effects: agent executes bash commands, which may have side effects, but no sandbox default configuration is provided. Source attribution: README and pyproject clearly list authors and institutions. Deductions: lack of user confirmation and rollback mechanisms, insufficient explanation of data flow and sensitive data handling.
Evidence shows: tests cover various scenarios including timeout, step limits, cost limits, format errors, indicating good internal consistency. Dependencies are clearly listed in pyproject with problematic versions excluded, so dependency availability is good. Failure messages: tests verify handling of timeouts and format errors, but detailed error message documentation is not provided. Deduction: insufficient documentation of failure messages.
Evidence shows: README clearly states target users (developers, researchers) and use cases (CLI, batch inference, Python bindings). Capability boundaries: only bash tool is used, no other tools. Trigger precision: triggered via CLI commands and Python API, clearly described. Environment fit: supports multiple environments (local, docker, singularity, etc.). Deduction: no explicit mention of unsupported environments or limitations.
Evidence shows: README provides clear installation instructions, usage examples, FAQ links, and documentation links. Naming is stable, with multiple CLI entry points. Known limitations: README mentions some design choices (e.g., no shell session) but does not systematically list all limitations. License is MIT, clear. Versioning: v2 migration guide exists, but no detailed changelog. Maintenance responsibility: contribution guide and documentation exist. Deduction: known limitations and changelog are not detailed enough.
Evidence shows: output usability: CLI and Python bindings provided, output format clear. Marginal value: emphasizes simplicity and performance, but no detailed comparison with other tools. Cost-benefit: claims high performance and fast startup, but no specific cost data. Deduction: lack of specific performance data and cost comparison.
Evidence shows: performance claims (>74% SWE-bench) in README have external benchmark links, but no specific reproduction steps. Cross-source corroboration: external blog and benchmark links exist, but no independent verification. Fact-inference separation: README distinguishes facts (e.g., code line count) from inferences (e.g., performance claims). Deduction: performance claims lack detailed reproduction steps and independent verification.
- This agent executes arbitrary bash commands, which may have irreversible effects on the system; it is recommended to run in a sandboxed environment.
- No user confirmation mechanism is provided; commands are executed without user consent, so use with caution.
- Data flow transparency is insufficient; it is not clearly stated what data is sent to external models, so be cautious with sensitive data.
What does this agent do, and when should you use it?
mini-swe-agent is a Python software-engineering agent with a `mini` CLI and Python bindings. Its documented default composition uses `DefaultAgent`, `LitellmModel`, and `LocalEnvironment`. The agent uses Bash as its only action interface and appends each step to a linear message history passed back to the language model. Actions run independently through `subprocess.run` instead of a persistent shell session; the documented deployment options include local environments, Docker/Podman, Singularity/Apptainer, bubblewrap, and contree. The repository also documents batch inference and a trajectory browser, and claims a score above 74% on SWE-bench verified.
A user starts the command-line agent with mini, or constructs DefaultAgent(LitellmModel(model_name=...), LocalEnvironment()) in Python and calls agent.run("Write a sudoku game"). The agent appends the task and each step's result to a linear message history and passes that history to the language model; it does not require the model's tool-calling interface. Model-proposed actions are executed as Bash commands, one independently at a time through subprocess.run, so commands do not share persistent shell state. The documented interfaces cover local tasks, batch SWE-bench inference, and trajectory viewing, but the supplied material does not define a particular patch, commit, or report-file output format.
- A developer handling a GitHub issue from a local terminal can start the agent with
mini. - A Python tool author who wants a programmable engineering agent in a script can compose
DefaultAgent,LitellmModel, andLocalEnvironment, then callagent.run(...). - An evaluation researcher running batch SWE-bench inference and inspecting the full model-agent trajectory can use the documented batch-inference and trajectory-browser interfaces.
- A team that needs to execute agent actions in a container or isolated environment can use the documented Docker, Podman, Singularity/Apptainer, bubblewrap, or contree paths.
- A fine-tuning or reinforcement-learning researcher who wants to avoid a complex agent scaffold can use its Bash-only, linear-history control flow.
What are this agent's strengths and limitations?
- The control flow is intentionally small: the agent class is described as roughly 100 lines of Python, and its linear history makes the model context inspectable.
- Bash is the sole action interface, so the language model does not need tool-calling support.
- Each action runs through an independent
subprocess.runinvocation, avoiding persistent shell-session state and fitting the documented sandbox paths. - It offers a
miniCLI, Python bindings, batch inference, and a trajectory browser.
- Bash is the only core action interface; the repository itself does not provide dedicated structured tools or multi-tool interface experimentation.
- Because commands do not share a persistent shell session, workflows that rely on shell state across commands need adaptation.
- The supplied material does not provide concrete provider credentials, environment variables, or model-configuration steps.
- The README identifies this as v2, so users coming from v1 must follow the migration guide.
How do you install or deploy this agent?
For a quick trial: pip install uv && uvx mini-swe-agent, or pip install pipx && pipx ensurepath && pipx run mini-swe-agent. To install into the current environment: pip install mini-swe-agent, then run mini. From source: git clone https://github.com/SWE-agent/mini-swe-agent.git, then cd mini-swe-agent && pip install -e ., then run mini. Before use, select and configure a model for LitellmModel; the supplied material does not specify credential names, environment variables, or configuration parameters.
How do you use this agent?
After installation, run mini to start the CLI. For Python, use the documented pattern: agent = DefaultAgent(LitellmModel(model_name=...), LocalEnvironment()), then agent.run("Write a sudoku game"). Replace model_name=... with the name of a configured model; the supplied material does not provide the complete model-configuration command.
How does this agent compare with similar options?
The README presents mini-swe-agent as the default choice for a local CLI, simple control flow, faster sandboxing and benchmark runs, or fine-tuning and reinforcement learning without overfitting to a particular agent scaffold. For experimenting with multiple tool sets and interfaces or with different history processors, it recommends SWE-agent. Both are described as offering SWE-Bench performance and a trajectory browser.
FAQ
Does it require function calling or tool calling from the model?
Which execution environments are documented?
How are model credentials configured?
/completion and /response endpoint support, but does not provide concrete credential or configuration parameters.