OpenSwarm
Orchestrate development issues into reviewed, verified code changes.
Per-dimension scores and reasoning
Evidence: read-only defaults to true and is enforced per adapter; config writes .env with chmod 600; SECURITY.md provides reporting channels; dependency overrides fix known vulnerabilities. Deductions: user confirmation only in init wizard, not covering all destructive operations; data flow transparency only mentions ZDR and prompt caching, not detailed data flows; sensitive data handling has .env permissions but no key rotation; dependency security has overrides but no vulnerability scanning or audit evidence; external effects have sandbox and read-only but not all scenarios; rollback only mentions PR not auto-merge, no system-level rollback; source attribution only mentions copyright, not third-party code provenance.
Evidence: README and package.json descriptions align; CI has lint/typecheck/build/test; dependencies are common packages with overrides; failure messages are well-designed, e.g., review exit codes distinguish 1/2, sandbox unavailability gives specific fixes. Deductions: no dependency availability monitoring or lockfile; failure messages not covering all scenarios.
Evidence: targets developers, scenarios cover CLI, CI, daemon, Discord control; capability boundaries clear, e.g., read-only enforcement, sandbox fail-closed; trigger precision high, e.g., review exit codes, pr watch rounds; environment fit good, supports multiple OS and providers. Deductions: no explicit unsupported environments or limitations.
Evidence: README structure clear, with quick start, CLI commands, configuration; install notes detailed, including native deps and sandbox setup; naming stable, e.g., openswarm commands; examples and FAQ via GitHub Discussions; license MIT; CHANGELOG and versioning present; maintenance responsibility via SECURITY.md and Discussions. Deductions: naming stability not backed by historical version comparison; known limitations not explicitly listed; maintenance responsibility not clearly defined for contributors or maintainers.
Evidence: output usability high, e.g., review provides SARIF, JSON output; marginal value high, e.g., SWE-bench 3/3 resolved; cost-benefit has cost-aware routing and benchmark. Deductions: cost-benefit data only from README claims, no independent verification.
Evidence: README claims SWE-bench results but no detailed data or reproduction steps; benchmark directory exists but no independent verification; facts and inferences mixed, e.g., 'verified on real GitHub issues' without specific instances. Deductions: lack of traceable test results and independent sources.
- Publisher identity is unverified; use with caution.
- Dependencies include native modules (better-sqlite3, @lancedb/lancedb) that may require build toolchains.
- Autonomous mode requires API keys and external services (Linear, Discord); ensure key security.
- Read-only mode defaults to true, but users should understand its limitations and avoid processing untrusted input in non-read-only mode.
What does this agent do, and when should you use it?
OpenSwarm is a TypeScript and Node.js 22+ autonomous development orchestrator operated through a TUI, CLI, Discord, and a web dashboard. It takes work from Linear or a built-in SQLite tracker, filters it through DecisionEngine, and runs Worker and Reviewer pairs with optional Tester and Documenter stages in PairPipeline. Execution adapters cover Codex, OpenAI GPT, OpenRouter, Atlas Cloud, Ollama, LM Studio, and an opt-in Claude Code CLI fallback. The repository also includes a code entity registry, BS Detector, LanceDB long-term memory, and repository-scoped knowledge recall. It fits engineering teams willing to configure provider credentials, project paths, and verification commands in exchange for a self-hosted workflow spanning issue execution, review, and CI repair.
AutonomousRunner fetches Linear issues on a heartbeat, DecisionEngine applies scope, priority, and limit checks, then projectMapper resolves a project path before calling PairPipeline.run(). A Worker edits through the configured adapter, a Reviewer returns APPROVE, REVISE, or REJECT, and the loop can repeat before optional Tester and Documenter stages. openswarm review reviews working-tree changes; openswarm review --max splits a codebase into areas for reviewer subagents and can emit an audit report, Linear issues, JSON decisions, or SARIF; --fix repairs in isolated sandboxes and publishes a PR only after re-review and deterministic verification. openswarm fix detects npm, Cargo, or Python checks, groups failures by file, and reruns checks across repair rounds. The Code Registry writes functions, classes, and types to SQLite/FTS5, openswarm check --bs scans code-smell patterns, and completed-task outcomes are stored in LanceDB for later repository-specific prompt recall and search_memory queries.
- An engineering team using Linear that wants scheduled issue selection, implementation, review, and issue-state updates in one workflow.
- A team that needs PR review as a GitHub Actions merge gate, using the included composite action, JSON verdicts, or SARIF output.
- A maintainer of a Node, Rust, or Python repository who wants
openswarm fixto repair failing lint, typecheck, build, or test checks and rerun them. - A Discord-based development team that wants to dispatch work, inspect active tasks, control autonomous execution, and change providers with bot commands.
- A developer who wants to use local Ollama or LM Studio models for coding workflows while retaining Codex, GPT, or OpenRouter options.
What are this agent's strengths and limitations?
- Combines Linear or local issue intake, Worker/Reviewer orchestration, optional testing and documentation stages, and daemon operation in one toolchain.
- Supports several execution paths: OpenRouter models, ChatGPT OAuth through codex-responses, local Ollama/LM Studio, and a Claude Code CLI fallback.
review --max --fixcombines area-based review, dependency-closure grouping, isolated sandboxes, re-review, and deterministic verification gates.- Its code registry, risk and test mapping, BS Detector, and LanceDB repository knowledge loop extend beyond one-off task execution.
- Full autonomous operation requires Node.js 22+, native-module build support, provider authentication, and potentially Linear, Discord, or GitHub CLI integrations.
- Claude Code is an explicitly selected
claude -pfallback; it is not used as an automatic fallback. - Deterministic verification on Linux depends on bubblewrap and fails closed when unavailable; GitHub Actions and Docker may require extra system configuration.
review --max --fixonly publishes a PR after every area is re-approved and trusted deterministic checks pass, which adds process overhead for teams seeking direct edits.
How do you install or deploy this agent?
Requires Node.js 22+, at least one configured LLM provider, and a native build toolchain for better-sqlite3 and @lancedb/lancedb. Install and start with:
npm install -g @intrect/openswarm
openswarm init
openswarm doctor
openswarmThe setup wizard can configure ChatGPT OAuth, OpenRouter, GPT, Ollama, LM Studio, or an authenticated claude CLI. For manual setup, first run openswarm auth login or set OPENROUTER_API_KEY for OpenRouter. Autonomous operation can additionally use Linear OAuth/API credentials and Discord bot credentials.
How do you use this agent?
Run openswarm init in the repository to manage so the wizard writes config.yaml and .env; then use openswarm start for the background daemon, or run one task with openswarm run "Fix the bug" -p ~/my-project. For a full local pipeline without the daemon, use openswarm exec "Run tests" --local --pipeline. Review current changes with openswarm review, and repair detected check failures with openswarm fix. openswarm dash opens the dashboard on port 3847.
How does this agent compare with similar options?
Across its documented provider options, codex-responses uses ChatGPT OAuth with a native Responses API loop; codex delegates to the external Codex CLI; openrouter runs OpenSwarm's own agentic tool loop for OpenRouter models; local and lmstudio target local models; and Claude Code is an explicitly enabled CLI fallback.
FAQ
Is Linear required?
Can a PR review modify the reviewed checkout?
read-only defaults to true, and the reviewer is restricted to read-only access. review --max --fix is a separate, explicitly requested repair flow.What happens when the review gate cannot run?
openswarm review exits with code 2 when no verdict is produced. The documented CI guidance treats every non-zero exit as a failed check.Can it run without a cloud model?
local) or LM Studio (lmstudio); embeddings run locally through @huggingface/transformers.