Open Swarm
A local desktop mission control for running many coding agents in parallel on one pannable canvas.
- Source repo
- openswarm-ai/openswarm
- Stars
- ★ 821
- Last updated
- 3d ago
- License
- AGPL-3.0
- Primary language
- TypeScript
- FA score
- 40/100 · Major gaps
At a glance
- Works with
- Platform-specificClaude APIClaude Code (Partial support)
- You'll need
- Typical use
- Developers running several features at once: give each feature its own agent in a separate git worktree and watch them all on one canvas.
- Main limitation
- Core execution depends on claude-agent-sdk and Anthropic models/keys; moving to another model provider means writing your own adapter, as no multi-provider path is documented.
- Source review
- 40/100 · Major gaps
What does this agent do, and when should you use it?
Open Swarm is a locally-running orchestrator that manages multiple coding agents side by side. It ships as an Electron shell wrapping a React/TypeScript frontend on port 3000 and a FastAPI backend on port 8324, which talk over REST (/api/*) and WebSockets (/ws/*). The backend's Agent Manager drives each session through claude-agent-sdk and persists state as JSON files. Every agent works inside its own git worktree and branch, and every tool call is gated behind a human approval step. Nothing is relayed through a cloud backend or telemetry, but you supply your own Anthropic API key and pay for model usage.
The frontend renders a spatial dashboard: an infinite canvas where agent cards, view cards and embedded browser cards can be dragged and arranged, with multiple dashboards for different workspaces. The Agent Chat page streams tokens over WebSockets, tracks USD cost per session, and keeps history across restarts. Each tool request raises a Human-in-the-Loop approval that you can approve or deny individually or batch-handle from the dashboard, with per-tool policies (always allow, ask, deny). Editing an earlier message forks the conversation so you can move between branches. Five built-in modes (Agent, Ask, Plan, View Builder, Skill Builder) plus custom modes define system prompts and tool restrictions, and prompt templates are invoked inline with / slash commands. The Skills library syncs to ~/.claude/skills/ and can install from the Anthropic skills marketplace; the Tools library configures MCP servers over stdio, HTTP or SSE with automatic tool discovery, browses the MCP registry and Google's catalog, and includes Google Workspace OAuth. Views/Outputs produce HTML/JS/CSS artifacts rendered in iframes with vibe coding, a Python executor and auto-run. Git worktree isolation gives each agent its own branch, and a Diff Viewer shows uncommitted changes without leaving the app.
- Developers running several features at once: give each feature its own agent in a separate git worktree and watch them all on one canvas.
- Teams that need to sign off on agent actions: file writes and command executions funnel into a single approval queue, batch-handled with Shift+A / Shift+D.
- Exploration before execution: use Plan or Ask mode to get a proposal without touching code, then switch back to Agent mode to implement.
- Users who repeat the same workflows: encode them as prompt templates with structured input fields and call them with
/in the chat box. - Technical users extending tool reach: wire MCP servers or Google Workspace (Gmail, Calendar, Drive) into agents through the Tools library.
- Anyone who changes direction mid-session: edit an earlier message to fork a branch and compare approaches without losing the original thread.
How do you install or deploy this agent?
Option 1 — download the desktop build (currently macOS only):
https://github.com/openswarm-ai/openswarm/releasesGrab the latest release from GitHub Releases. No separate Python install is needed; the desktop package bundles a standalone Python 3.13 runtime. Windows and Linux builds are documented as planned but not yet available.
Option 2 — run the development setup from source. Prerequisites: Python 3.11+, Node.js 18+, Git.
git clone https://github.com/openswarm-ai/openswarm.git
cd openswarm
bash run.shThis starts the backend (port 8324), frontend (port 3000) and the Electron shell together. You can also run services individually:
bash backend/run.sh # API at http://localhost:8324 — docs at /docs
bash frontend/run.sh # App at http://localhost:3000The config file to copy is backend/.env.example to backend/.env; the Anthropic API key is not set there but in the in-app Settings page.
How do you use this agent?
On first launch, open the in-app Settings page and enter your Anthropic API key — it is required for normal use.
Create an agent card on the canvas and assign it a workspace; the agent begins work in its own git worktree and branch. Send a message in Agent Chat and the reply streams back token by token while a per-session USD cost counter updates.
When an agent wants to run a tool, a pending request appears on the dashboard:
Shift+A approve all pending requests
Shift+D deny all pending requestsCommon keyboard shortcuts:
D go to Dashboard
T go to Templates
1 – 9 open agent by position
? show shortcuts helpType / in the chat input to invoke prompt templates and skills. To add external tool reach, configure MCP servers (stdio, HTTP or SSE) on the Tools page and set GOOGLE_OAUTH_CLIENT_ID / GOOGLE_OAUTH_CLIENT_SECRET for Google Workspace OAuth. Ports and keys can be adjusted in backend/.env, for example BACKEND_PORT (default 8324).
What are this agent's strengths and limitations?
- Each agent gets its own git worktree and branch, so parallel workstreams don't collide, and the built-in Diff Viewer shows uncommitted changes in-app.
- All agents' tool requests land in one approval queue with per-request and batched (Shift+A / Shift+D) handling, plus per-tool policies of always allow, ask or deny.
- Fully local execution: the README states there is no cloud relay, no telemetry and no third-party backend, so sessions and cost data stay on your machine.
- Message branching: edit any earlier message to fork the conversation and move between alternative approaches without losing context.
- Tool integrations are MCP-native (stdio, HTTP, SSE) with automatic tool discovery and browsable MCP and Google registries.
- The desktop package bundles a standalone Python 3.13 runtime, so end users don't need Python preinstalled.
- Core execution depends on claude-agent-sdk and Anthropic models/keys; moving to another model provider means writing your own adapter, as no multi-provider path is documented.
- Official releases are macOS-only today; Windows and Linux builds are explicitly listed as planned but unavailable, leaving non-macOS users on the source route.
- Running it requires a paid Anthropic API key billed per use — the software is free, but model cost is not included.
- Source setup means juggling Python 3.11+, Node.js 18+ and Git, and optionally Google OAuth credentials for Workspace integration.
- License labeling looks inconsistent: README badge and text say MIT while repository metadata says AGPL-3.0, so confirm the actual terms before adopting.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Open Swarm This agent | 40 · Major gaps | — | ★ 821 | 3d ago | TypeScript | Claude API |
| Synapse AI — Multi-Agent Orchestration Platform | 70 · Some gaps | CLIFree + model costs | ★ 327 | 1mo ago | Python | OpenAI API · Claude API |
| DeterminFlow | 66 · Some gaps | Desktop appFree + model costs | ★ 760 | 15d ago | Python | — |
| Neuron AI — Agentic Framework for PHP | 45 · Major gaps | Library / SDKFree + model costs | ★ 2.1k | 7d ago | PHP | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
README claims '100% local, no telemetry' and documents HITL approvals, per-tool permissions (always allow/ask/deny), git worktree isolation and a diff viewer, which is real evidence of confirmation and least-privilege mechanisms, so user_confirmation scores 2. least_privilege is only 1: the same README lists Google Workspace OAuth, MCP registry proxies, skill sync into ~/.claude/skills/, a Python executor and an embedded browser, a broad permission surface with no permission inventory or sandbox boundary. data_flow_transparency and sensitive_data_handling are 1 each: storage, logging and transport of the API key and OAuth secrets are not described beyond 'set it in Settings'. dependency_security is 1: only requirements.txt and package-lock cache keys are visible, with no audit, pinning or vulnerability handling. external_effects is 1: auto-update, installer and registry proxies are external side effects with no scope or opt-out documentation. rollback is 1: worktrees and branches exist but no rollback/recovery procedure is documented. source_attribution is 1: the README badge says MIT while LICENSE is AGPL-3.0, a self-contradiction, and third-party origins are unlabeled.
self_consistency is 1: the README MIT badge directly conflicts with the AGPL-3.0 LICENSE, and the README says macOS-only while the CI workflows run Windows-only and state macOS legs were removed, so docs and engineering reality disagree. dependency_availability is 1: Python 3.11+/Node 18+ and a bundled Python 3.13 are listed, but there is no version pinning or availability verification evidence. failure_messages is 1: conftest and CI scripts show failure-path testing (preflight rigs, hostile-env scenarios), but user-facing error messages and recovery guidance are not visible in the provided files.
audience_and_scenarios is 2: the README clearly targets developers running multiple coding agents in parallel and offers both desktop and development paths. capability_boundaries is 1: five built-in modes plus custom modes are listed, but capability limits, unsupported cases and safety boundaries are not systematically stated. trigger_precision is 1: only slash commands and keyboard shortcuts are described, without precise trigger conditions or precedence. environment_fit is 1: the README claims a macOS desktop app with Windows/Linux planned, while CI is Windows-only, so environment fit is inconsistent between docs and implementation.
information_architecture is 2: the README is well structured with an architecture diagram, project structure, config table and shortcut table. install_notes is 2: run.sh, per-service startup and prerequisites are given, which is usable install guidance. naming_stability is 1: module and directory naming is fairly consistent, but no naming stability or compatibility commitment exists. examples_and_faq is 1: quick start and shortcut examples exist, but there is no FAQ or end-to-end usage example. known_limitations is 1: only the absence of Windows/Linux builds is mentioned; known limitations are not systematically listed. license is 1: the LICENSE file is full AGPL-3.0, but the README badge says MIT, so metadata and file conflict, which is deducted. versioning_changelog is 0: no CHANGELOG, version number or release notes. maintenance_responsibility is 1: a Contributing section and PR-welcome badge exist, but the publisher is unverified and maintenance responsibility and update path are unclear.
output_usability is 2: the spatial canvas, streaming chat, approvals, branching, diff viewer and cost tracking are concrete, usable outputs. marginal_value is 1: the incremental value over running agents in a terminal is argued but not compared or quantified. cost_benefit is 1: per-session USD cost tracking exists, but there is no overall cost-benefit analysis or resource-footprint statement.
claim_traceability is 1: most README feature claims have no corresponding file or test reference; only a few (e.g. the MCP gate) are backed by tests. cross_source_corroboration is 1: README, CI workflows and tests partially corroborate each other (MCP gate, worktrees), but key claims such as platform support contradict each other. fact_inference_separation is 1: the docs mix design intent with implemented fact and do not separate verified from unverified content.
- License self-contradiction: the README badge says MIT while the LICENSE file is AGPL-3.0; clarify the actual license and compliance obligations before use.
- Platform claims conflict with CI: the README describes a macOS desktop app with Windows/Linux planned, while workflows run Windows-only and state macOS legs were removed.
- Broad permission surface: Google Workspace OAuth, MCP registry proxies, skill writes into ~/.claude/skills/, a Python executor and an embedded browser exist, with no permission inventory or sandbox boundary documented.
- Storage, logging and transport of API keys and OAuth credentials are not described; sensitive-data handling must be assessed independently.
- No CHANGELOG or version number, unverified publisher, and an unclear update and maintenance path.
- This is a static source review; no build or run was executed, and test/determinism conclusions are out of scope.