OpenSwarm calls itself fully local, and its only desktop build is macOS

Local means the orchestrator, not the models

The feature list puts it plainly: everything runs on your machine, with no cloud relay, no telemetry, and no third-party backend. The interesting question is what that sentence covers. The agents themselves need an Anthropic API key, and the configuration section says it is set in the app's Settings page rather than through an environment variable, so the inference call leaves the machine. The skills library is described as syncing directly into a hidden directory inside a home folder and as browsing the official Anthropic skills marketplace, which is another outbound surface. The desktop shell also carries an auto-updater fed by GitHub Releases. None of that contradicts the claim, which is about the relay and the storage of your conversations, but a reader who takes the bullet at face value will be surprised by the first API bill.

Windows and Linux are planned, and the Windows tooling is already in the tree

The desktop distribution story is one line: download the latest release for macOS. The next line is a blockquote saying Windows and Linux builds are planned but not yet available. The repository says otherwise, in a quieter way. At the root there is a PowerShell run script, a PowerShell publish script, and a Windows example environment file, all three named for the platform rather than tucked into a branch. The configuration table adds macOS code signing and notarization variables and a GitHub token for publishing releases, each marked as release builds only. So the Windows path exists in the tree ahead of the Windows build, and what is missing is packaging rather than intent. Worth knowing before you plan around a cross platform tool: the orchestration code runs on any machine that has the development prerequisites, but the downloadable artifact is macOS only.

One script starts three processes on two ports

Development needs Python 3.11 or newer, Node 18 or newer, and Git, then a clone and one shell script:

git clone https://github.com/openswarm-ai/openswarm.git
cd openswarm
bash run.sh

That script starts the backend on port 8324, the frontend on port 3000, and the Electron shell around them. The two halves can also be started on their own, and the comments give the addresses, including where the API documentation is served:

bash backend/run.sh     # API at http://localhost:8324 — docs at /docs
bash frontend/run.sh    # App at http://localhost:3000

The architecture section puts a React and TypeScript canvas in the frontend talking to a FastAPI service over both a REST path and a WebSocket path, which matches the feature list's claim that chat is streamed. End users do not need any of this, because the release bundles a standalone Python runtime, and that bundle is why the download is large.

One approval queue is the actual product

The reason for the app, in the page's own framing, is that running agents in a terminal works fine for one task and falls apart when you are juggling five across branches, approving tool calls in separate windows, and losing track of who is doing what. The fix is a single surface: every tool use request from every agent appears in one place, and you approve or deny with a click or a shortcut. Permissions are configurable per tool as always allow, ask, or deny, and requests can be batch approved from the dashboard. The keyboard table backs that up with a shift and A to approve everything pending and a shift and D to deny everything pending, a question mark for the shortcut list, D for the dashboard, T for templates, number keys one through nine to jump to an agent by its position on the canvas, and a slash in the chat input to invoke templates and skills as commands.

Each agent gets a worktree, so the diff is where the review happens

Parallelism is handled with git rather than with locking. Every agent operates in its own git worktree and branch, which is what prevents conflicts between parallel workstreams without any coordination layer. The consequence is that the useful artefact of a running agent is its diff, and the app has a viewer for exactly that: inspect uncommitted changes in any agent's worktree without leaving the interface. The spatial dashboard is the frame around it, an infinite canvas of draggable agent cards, view cards, and embedded browser cards, with multiple dashboards available for different workspaces. Chat is a full streaming interface over WebSockets with per session cost tracking in US dollars and history that survives restarts. Themes, light and dark, are driven by design tokens.

A mode that generates a view can also execute the Python behind it

Five modes ship by default, named Agent, Ask, Plan, View Builder, and Skill Builder, and custom modes can be added with their own system prompts and tool restrictions. The View Builder mode leads into the part with the largest consequence. Views are described as interactive HTML, JavaScript, and CSS artifacts rendered in iframes, with support for the model generating the view itself, for backend Python execution, for auto running with generated data, and for an agent gathering the data itself. So the same feature that lets a non programmer sketch a panel also opens a path where model written code runs on the backend. The project structure confirms where that lives, with an outputs app described as views and outputs, vibe coding, and a Python executor. The page presents all of this as capability and does not say what the executor is confined to.

The structure listing stops mid word and skips two product directories

The project structure section is a tree of backend apps, and it ends abruptly on an entry reading mcp_regist, the name of a directory cut in half. The entries before it are more informative than the heading suggests: agent lifecycle with streaming and worktree management, dashboard CRUD, a separate app for card positions and canvas state, templates, skills synced into the home directory, an app for MCP tool configuration and discovery, modes, outputs, settings, and a health check endpoint. The top level of the repository is wider than the page describes, holding the backend, frontend, and electron trees plus directories for end to end tests, a linter, a debugger, scripts, documentation, assets, and two directories named after product variants that the readme never explains. Two small root files do get referenced by implication rather than name: a node version file and a secret scanner configuration with its own ignore list.

Editorial conclusion

OpenSwarm fits a developer running several coding agents on one Mac at once, and the worktree isolation plus one approval queue are the parts worth having. Two things to weigh first. The local claim covers the orchestrator, not the models or the update channel, since agents need an Anthropic key and the shell checks GitHub for new builds. And a feature that executes Python the model wrote is a real capability to think about before you enable it on a machine with anything you care about.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. openswarm-ai/openswarm on GitHub
3. Project website
4. README
5. Releases