# SwarmClaw: a self-hosted agent runtime for teams that want their swarm on their own box

> SwarmClaw is an MIT-licensed TypeScript agent runtime that runs autonomous agents with memory, MCP tools, delegation and schedules across 23+ providers. It ships as a desktop app, a global npm CLI and a Docker image, and the last push to the repository was on 2026-06-30.

**swarmclawai/swarmclaw** — Open-source self-hosted AI agent runtime and multi-agent framework for autonomous agent swarms. Agent memory, MCP tools, schedules, delegation, and 23+ LLM providers (Claude, GPT, Gemini, OpenRouter, Ollama). A practical Claude Code and LangChain alternative.

- Repository: https://github.com/swarmclawai/swarmclaw
- Website: https://www.swarmclaw.ai
- Stars: 689 · Forks: 140
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/swarmclawai-swarmclaw

## What SwarmClaw is for, and who ends up running it

The README describes SwarmClaw as "the self-hosted AI agent runtime and multi-agent framework for autonomous agents." The problem it targets is not chat. It is the gap between a single LLM call and a system that keeps working while you are not watching: an agent that remembers earlier sessions, calls external tools, hands work to another agent, and wakes up on a schedule. The repository's own framing is a "practical Claude Code and LangChain alternative," which tells you the intended audience. If you already have Claude Code or a LangChain graph and you want the orchestration layer under your own control, this is aimed at you.

The secondary audience is less technical. The README offers a one-click desktop installer for macOS, Windows and Linux and labels it "recommended for non-technical users." That is an unusual split for an agent framework, and it shows in the repository layout: an electron/ directory and electron-builder.yml sit next to a Dockerfile and a docker-compose.yml. The same product is packaged three ways, and the data directories do not overlap. Desktop data lives in the OS app-data path; CLI and Docker installs keep their own state. Pick one path and stay on it, because the README does not describe a migration between them.

## How the runtime is put together: agents, memory, tools, delegation

The mechanism visible in the repository is a Next.js application with an Electron shell. package.json sets "main" to electron-dist/main.js, the build scripts run Next, and the Dockerfile copies .next/standalone plus a server.js entry point. So the runtime is a long-lived Node process serving an HTTP surface, not a library you import into your own program. The compose file exposes two ports, 3456 and 3457, and the Dockerfile sets PORT=3456 and HOSTNAME=0.0.0.0. Port 3456 serves the app and the health endpoint at /api/healthz; 3457 is exposed alongside it, and the README does not explain what it carries.

On top of that process sit the features the README names: agent memory, MCP tools, skills, delegation and schedules. The org chart screenshot in doc/assets/screenshots shows named agents (CEO, Developer, Researcher) with delegation edges and live activity, which is the mental model the project wants: you define roles, they hand tasks to each other, and the UI shows the traffic. Two details are worth pulling out. First, skills are learned from conversations and then reviewed, described as "reviewed conversation-to-skill learning," which means a human gate sits between a conversation and a reusable skill. Second, the provider list is broad by design: Anthropic, OpenAI, Gemini, OpenRouter, Ollama, DeepSeek, Groq, Together, Mistral, xAI, Fireworks, Nebius and DeepInfra appear in the logo table, and the README also lists delegated CLI backends including Claude Code, Codex, OpenCode, Gemini CLI, Copilot, Factory Droid, Cursor Agent, Qwen Code and Goose. Those two things are different: a provider is an API you send prompts to, a CLI backend is a program SwarmClaw drives. The README does not say how it decides between them, and that is a gap worth knowing about before you build a workflow around one.

## Installing SwarmClaw with npm and getting an agent to answer

The README lists the requirements plainly: Node.js 22.6+ (the .nvmrc matches CI, so `nvm use` picks the right version), npm 10+ or another supported package manager, and Docker Desktop recommended for sandbox browser execution. Provider CLIs are optional and only needed if you want the delegated CLI backends.

For a global install the README gives two commands, one for npm and one for yarn:

```bash
npm i -g @swarmclawai/swarmclaw
swarmclaw
```

```bash
yarn global add @swarmclawai/swarmclaw
swarmclaw
```

Running `swarmclaw` starts the runtime and opens the dashboard, which is where the org chart, agent chat and operator controls live. Expect a browser tab on the local port rather than a terminal prompt; the CLI is a launcher for the app, not a REPL.

If you would rather run it as a service, the repository ships a compose file. It pulls ghcr.io/swarmclawai/swarmclaw:latest, maps 3456 and 3457, mounts ./data into /app/data, and reads an optional ./.env.local:

```yaml
services:
  swarmclaw:
    image: ghcr.io/swarmclawai/swarmclaw:latest
    ports:
      - "3456:3456"
      - "3457:3457"
    volumes:
      - ./data:/app/data
    env_file:
      - path: ./.env.local
        required: false
```

Two things to notice. The healthcheck curls http://localhost:3456/api/healthz every 30s with 3 retries and a 10s start period, so you can tell a broken container from a slow one. And env_file is marked required: false, which means the container will start without any provider credentials and simply have nothing to talk to. Put your keys in .env.local before you expect an agent to reply.

The README also documents a setup script pair for source checkouts, `npm run setup:easy` and `npm run quickstart`, but it does not spell out what each one does beyond the script names.

## Where SwarmClaw gets in your way

The desktop install is the weakest documented path, and the README admits it. macOS releases are signed and notarized only "when Apple credentials are configured"; otherwise the build is ad-hoc signed and macOS may refuse it. The README gives two different remedies depending on the message you see. If Finder warns about an unidentified developer, right-click the app and choose Open. If macOS instead says the app is damaged, the cause is a quarantine attribute from Safari, and the fix is:

```bash
xattr -dr com.apple.quarantine /Applications/SwarmClaw.app
```

That is a reasonable workaround to document, but it is also a signal: if you are deploying to people who cannot run a terminal command, the signed build is the one you need, and the README does not promise it will exist for every release.

The larger limitation is structural. SwarmClaw is a long-running server with a database and a data directory. The Dockerfile installs git, python3, make and g++ specifically because better-sqlite3 needs to compile, and it retries `npm ci` up to three times. That is a build that wants a real machine, not a serverless function. The compose file binds ./data to /app/data, and nothing in the README describes rollback, backup or schema migration for that directory. If you run agents that accumulate memory over months, you own that data and its upgrades yourself.

Finally, the provider breadth cuts both ways. Twenty-three providers and nine CLI backends is a lot of surface to keep working, and the README does not publish a compatibility matrix saying which combinations are supported together. The release cadence visible in the tags (v1.9.38 on 2026-06-08, v1.9.39 on 2026-06-11, v1.9.40 on 2026-06-30) suggests active work, but the last push to the repository was on 2026-06-30, so treat the current state as a snapshot rather than a moving target you can rely on for daily fixes.

## SwarmClaw against CrewAI and LangChain

The README positions SwarmClaw against LangChain and Claude Code, and the search data shows people comparing it to CrewAI as well. The difference is where the runtime lives. LangChain is a Python library: you write the orchestration code, you own the process, and the framework is a dependency inside your application. CrewAI follows a similar shape, defining crews and tasks in Python and executing them in your script. SwarmClaw inverts that. The orchestration is the product, it runs as a server you deploy, and you configure agents through a dashboard instead of composing them in code. That is a real trade. You get persistence, schedules and a UI for free; you give up the ability to embed the agent loop in an existing Python service.

Against Claude Code the split is narrower. Claude Code is a coding agent in a terminal, and SwarmClaw lists it as one of the CLI backends it can delegate to. So the honest comparison is not either/or: SwarmClaw can drive Claude Code as one worker among several. What SwarmClaw adds is the layer around it, which is memory, scheduling and multi-agent delegation. If your work is one developer pair-programming in one repository, that layer is overhead. If your work is several agents with different roles and a queue of recurring jobs, it is the part you would otherwise write yourself.

## Maintenance, licensing and what an upgrade actually costs

SwarmClaw is MIT licensed, and package.json declares "license": "MIT" with publishConfig pointing at the public npm registry. MIT is permissive: you can run it commercially, modify it and ship it inside a product, provided you keep the copyright and licence notice. That is the whole of it. Nothing here is legal advice, and if you are embedding it in something you sell, read the LICENSE file in the repository root rather than this paragraph.

The maintenance picture is mixed and worth stating plainly. The repository is not archived. The last push was on 2026-06-30, and the most recent release tag is v1.9.40 from the same day. There is a CI workflow, a CONTRIBUTING.md, a CLAUDE.md and a tests/ directory, so the project has the furniture of a maintained codebase. But the version numbers move in small increments (1.9.38 to 1.9.39 to 1.9.40 inside three weeks), which usually means frequent patch releases rather than long stable plateaus. Budget for upgrading more often than you would for a library that ships twice a year.

The upgrade cost itself is the data directory. The compose file mounts ./data into the container, the Dockerfile creates /app/data, and the desktop app keeps its state in the OS app-data path instead. Upgrading the image replaces the code, not the volume, so your agents' memory survives an image pull. What the README does not document is whether a newer version migrates that data forward, or what happens if it does not. Snapshot ./data before you pull a new tag, and check the health endpoint at /api/healthz after the container comes back, because that is the only readiness signal the compose file defines.

## Conclusion

Adopt SwarmClaw if you want a self-hosted runtime where agents keep durable memory, call MCP tools and delegate to each other, and you are comfortable running Node 22.6+ or the Docker image on port 3456. Skip it if you need a managed service with an uptime commitment, or if you only want a coding assistant inside one editor. Verify first that your provider keys work, that ./data is mounted on a volume you actually back up, and that the /api/healthz healthcheck passes before you point anything real at it.

## FAQ

### Does SwarmClaw use AI?

Yes. SwarmClaw is an AI agent runtime, and it connects to 23+ LLM providers including Claude, GPT, Gemini, OpenRouter and Ollama, plus delegated CLI backends such as Claude Code and Codex.

### Is SwarmClaw free?

The project is MIT licensed, so the runtime itself is free to use, modify and self-host. Any cost comes from the model providers you connect it to, which the README does not price.

### What is SwarmClaw and how does it work?

It is a self-hosted AI agent runtime and multi-agent framework. A Node process serves a dashboard where you define agents with memory, MCP tools, skills, delegation and schedules, and those agents run against whichever LLM provider you configure.

### How does SwarmClaw run agents?

The README describes autonomous agents and orchestrators with heartbeats, schedules and delegation, shown in an org chart view with live activity. The runtime is a long-lived server, so agents keep running after you close the browser tab.

## Sources

- [License: MIT](https://github.com/swarmclawai/swarmclaw/blob/main/LICENSE)
- [Project website](https://www.swarmclaw.ai)
- [README](https://github.com/swarmclawai/swarmclaw/blob/main/README.md)
- [Releases](https://github.com/swarmclawai/swarmclaw/releases)
- [swarmclawai/swarmclaw on GitHub](https://github.com/swarmclawai/swarmclaw)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/swarmclawai-swarmclaw