OpenSwarm: a Claude Code CLI orchestrator that turns Linear issues into worker/reviewer pipelines

The gap OpenSwarm fills between an issue tracker and a coding agent

A coding agent on its own does not know what to work on. Someone reads a Linear issue, copies the description into a terminal, pastes the relevant files, waits, then copies the result back into the issue and asks a colleague to review it. OpenSwarm removes the human relay. The README describes it as orchestrating multiple AI agents as autonomous code workers: it picks up issues from Linear or a built-in local tracker, runs Worker/Reviewer pair pipelines, reports through a pluggable notifier, and retains long-term memory in LanceDB. The target user is a small engineering team that already tracks work in Linear and is comfortable running a long-lived process on a machine with provider credentials. The local SQLite issue store means you can evaluate the pipeline without a Linear account at all, which matters if you want to judge the orchestration before you connect it to your real backlog.

Worker, reviewer, notifier: the four moving parts

The architecture visible in the README is a loop with four boundaries. On the input side sits a task backend: either Linear, connected through OAuth or an API key with an arrow-key team and project picker, or a local SQLite store that requires no account. In the middle sits the agent layer, which the project describes as Worker/Reviewer pair pipelines. A worker produces a change; a reviewer inspects it. The README's review commands add a second shape to this: openswarm review --max fans reviewer subagents over areas of a codebase and writes a report to .openswarm/audit/, then by default files PM-synthesized Linear issues capped at ten cohesive items with a master issue and sub-issues. With --fix, dependency-related findings are grouped, independent fix units run in isolated sandboxes, and a pull request is published only after every re-review and a trusted deterministic repository check passes. On the output side, a pluggable notifier sends to Discord, Slack, Telegram or a webhook. Memory is the fourth boundary: task outcomes are stored as per-repo knowledge in LanceDB and recalled into future prompts, so the worker accumulates repository-specific context rather than starting cold each time.

Hybrid routing and the L0 to L6 benchmark ladder

OpenSwarm does not assume one model. The README lists OpenAI Codex and GPT, any OpenRouter model, local servers through Ollama or LM Studio, and Claude Code via claude -p as an opt-in fallback. Routing is described as cost-aware and measured on an L0 to L6 benchmark ladder, which is the project's own scale rather than an external standard. The interesting claim is the hybrid mode: a frontier model diagnoses read-only while a lightweight model implements inside a verification loop. The README states this resolved 3 of 3 attempted SWE-bench Lite instances that every single lightweight model had failed, graded by the official harness, at a fraction of frontier-only cost. Three instances is a small sample and the project publishes a rubric at benchmarks/RUBRIC.md rather than a broad leaderboard. Treat it as a design rationale with a worked example, not as evidence that hybrid routing wins in general. The mechanism, however, is sound in principle: separating diagnosis from implementation lets you spend frontier tokens on understanding and cheap tokens on edits.

Getting a first run: init, doctor, and what lands in your repo

Installation is a global npm package. The README gives npm install -g @intrect/openswarm, then openswarm init for the interactive wizard, openswarm doctor to verify the environment, and openswarm with no arguments to launch the TUI chat. The wizard asks three questions: the AI provider for worker and reviewer, the task backend (local SQLite or Linear), and an optional notification channel. It writes .env with secrets at chmod 600, a validated config.yaml, and, if you mapped a Linear project, an openswarm.json that binds this repository to a Linear team and project. Re-running init in a repo that already has config.yaml is refused unless you pass --force, and init will not overwrite a config.yaml that symlinks into the daemon's global config. For CI, openswarm init --yes writes a sample config only. Provider wiring can also be done by hand: openswarm auth login for ChatGPT OAuth used by codex and gpt, openswarm auth login --provider openrouter, or an exported OPENROUTER_API_KEY, or simply an authenticated claude on PATH. Check state with openswarm auth status. The Atlas Cloud adapter is selected with adapter: atlascloud and an ATLASCLOUD_API_KEY. Single tasks run through openswarm run "Fix the bug" -p ~/my-project, and openswarm validate checks config.yaml.

Where the design pushes back: auth, daemon state and a fast release cadence

The setup path is the first real constraint. Provider authentication is not optional plumbing; it is a step the wizard walks you through, and the README lists several mutually exclusive ways to satisfy it. If your environment blocks browser OAuth, you are limited to API-key providers or a pre-authenticated claude binary. The second constraint is that OpenSwarm is a daemon with global state. The init guard against symlinked config.yaml exists precisely because a repository config can point at the daemon's global config, which means a mistake in one repo can affect every repo the daemon serves. Third, the release cadence is aggressive: v0.22.1, v0.23.0 and v0.24.0 all landed within roughly a week in September 2026. A project moving that fast has not frozen its config schema, so a config.yaml written today may need editing after an upgrade. The README does not describe a migration path for config changes. Finally, openswarm review --max --fix publishes a pull request only after re-review and a deterministic repository check, which is a sensible gate, but it also means the fix path is slower than a plain agent edit and depends on that check being configured correctly for your repository.

How it differs from running Claude Code or Codex directly

The obvious alternative is the agent CLI itself: claude -p or codex run by hand, or wrapped in a shell script. The difference is in what each tool owns. A CLI owns one conversation in one directory. OpenSwarm owns the queue, the pairing, the notification and the memory. It decides which issue to pull, runs a worker and then a reviewer against it, records the outcome as per-repo knowledge in LanceDB, and posts the result to Discord or Slack. That is a real difference in approach, not a wrapper: the CLI has no concept of a backlog and no durable memory across tasks. The cost is that you inherit a daemon, a config schema and a provider abstraction layer. If your workflow is one developer running one agent on one branch, the CLI is less machinery for the same result. If your workflow is a shared Linear board where issues sit unassigned, OpenSwarm is the layer that closes the loop.

Licence, upgrade cost and the maintenance question

OpenSwarm is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. This is a statement about the licence text, not legal advice; if you redistribute a modified version, read the LICENSE file in the repository yourself. The practical maintenance cost sits elsewhere. You are running a daemon that holds provider credentials in a chmod 600 .env inside the repository, so secret handling becomes part of your repository hygiene. The provider abstraction means an upstream API change from any of Codex, OpenRouter, Ollama, LM Studio or Claude Code can require an OpenSwarm release, and the September 2026 release history suggests the maintainers ship those fixes quickly but also that the surface is still moving. Budget for reading release notes before upgrading, and keep the config.yaml under version control so a schema change is visible as a diff rather than a runtime failure. The openswarm doctor command is the cheapest first check after any upgrade, since it inspects runtime, native dependencies, providers and ports in one pass.

Editorial conclusion

Adopt OpenSwarm if your issues already live in Linear and you want an agent to pick them up without a human relaying context, and if you are willing to run a daemon that writes a config.yaml and a chmod 600 .env into the repository. Do not adopt it if you need a stable, frozen interface for a regulated pipeline, or if you cannot accept that provider auth is a first-class setup step. Verify three things first: that openswarm doctor reports no missing native dependencies or port conflicts, that your chosen provider adapter actually authenticates through openswarm auth status, and that a single openswarm run "..." -p <dir> task completes end to end before you point it at the daemon.

Official sources

1. Intrect-io/OpenSwarm on GitHub
2. Issues
3. License: MIT
4. README
5. Releases