SwarmClaw: a self-hosted runtime for agent swarms, judged on what the README actually shows

The gap SwarmClaw is aiming at

Most agent projects force a choice between two shapes. You get a single coding assistant bound to one vendor, or a library where you assemble the loop, the memory store and the tool plumbing yourself. SwarmClaw positions itself between those: a self-hosted runtime where agents are first-class objects with memory, tools, schedules and reporting lines, and where the model behind each agent is a configuration detail rather than an architectural commitment. The README describes it as "a practical Claude Code and LangChain alternative", which is a fair summary of the intent. The audience is engineers who want agents that keep running when their laptop closes, and who want to point different agents at different providers without rewriting glue code. It is not aimed at someone who wants a hosted product with a support contract. Everything here runs on infrastructure you own, which is the point and also the cost.

What the runtime actually holds: memory, tools, schedules, delegation

The README names five capabilities that make up the runtime: durable agent memory, MCP tools, skills, delegation and schedules, plus what it calls reviewed conversation-to-skill learning. The org chart screenshot shows CEO, Developer and Researcher agents with delegation edges and live activity, so the mental model is a hierarchy of agents that hand work to each other rather than a flat pool. Heartbeats and schedules are listed separately, which suggests two distinct triggers: periodic wake-ups and calendar-style runs. The conversation-to-skill path is the most interesting claim and the least specified. The word "reviewed" implies a human approval step before a conversation becomes a reusable skill, but the README does not say who reviews, where the review happens, or what the artifact looks like on disk. Treat that as a feature to inspect in the repository before you build a workflow around it. MCP support means tools are exposed through the Model Context Protocol, so anything you already have as an MCP server should be reachable without custom adapters.

Provider breadth is the headline, and it is genuinely broad

The provider list in the README covers hosted APIs (Anthropic, OpenAI, Google Gemini, OpenRouter, DeepSeek, Groq, Together, Mistral, xAI, Fireworks, Nebius, DeepInfra) and local execution through Ollama. It also lists CLI backends: Claude Code, Codex, Gemini CLI, OpenCode, Copilot CLI, Factory Droid, Cursor Agent, Qwen Code and Goose. That second list matters more than the first. Delegating to a CLI means the agent's work runs inside a tool that already has its own file access, permissions and sandboxing story, and SwarmClaw inherits whatever those tools enforce. The README is explicit that these CLIs are optional and only needed "if you want delegated CLI backends", so a deployment can stay entirely on HTTP providers. The practical consequence is that provider choice is a per-agent setting, not a global one. You can run a cheap local model for routine heartbeats and route a reasoning-heavy agent to a frontier API, all inside one runtime. That is the strongest argument in the README for choosing this over a single-vendor assistant.

Getting it running: two install paths and the flags that bite

There are two documented routes. The desktop app is described as recommended for non-technical users, with installers for macOS (Apple Silicon and Intel), Windows, and Linux as AppImage and .deb. The CLI route is two commands: npm i -g @swarmclawai/swarmclaw followed by swarmclaw, or the yarn equivalent yarn global add @swarmclawai/swarmclaw. Requirements are Node.js 22.6+ and npm 10+, with the repo shipping a .nvmrc that matches CI, so nvm use gets you the right runtime. Docker Desktop is recommended for sandbox browser execution, which is a soft requirement until you enable a tool that needs a browser. The macOS section is where the friction lives. The README states that signed and notarized releases publish both .dmg and .zip, while unsigned fallback releases publish .zip only, specifically to avoid the damaged unsigned DMG path. If Safari has quarantined a downloaded app, the documented fix is xattr -dr com.apple.quarantine /Applications/SwarmClaw.app. On Windows, SmartScreen requires More info then Run anyway. On Linux the AppImage needs chmod +x first. Data location differs by install type: the desktop app writes to ~/Library/Application Support/SwarmClaw, %APPDATA%\SwarmClaw or ~/.config/SwarmClaw, and the README notes this is separate from any CLI or Docker install. That separation is worth remembering before you migrate between install methods.

Where the documentation stops short

The README is a good front door and a poor operations manual. It does not describe the storage engine behind durable agent memory, so there is no documented answer to how long history is retained, how it is compacted, or what happens when the store grows. It does not specify the isolation boundary for delegated CLI backends; the README says Docker Desktop is recommended for sandbox browser execution, which implies browser work can be sandboxed, but it does not say whether an agent invoking a shell-capable CLI is contained by anything. Schedules and heartbeats are named without a cron syntax, a timezone rule, or a statement about what happens to a scheduled run that is still executing when the next one fires. The release cadence visible in the supplied material is fast, with v1.9.38, v1.9.39 and v1.9.40 landing within about three weeks, and nothing in the README describes a migration step for stored agent data between versions. None of these are disqualifying. All of them are things you would need to read the source or the docs site at swarmclaw.ai/docs to answer, and the README does not claim otherwise.

SwarmClaw against LangChain, and when a framework is the wrong shape

The comparison the README invites is with LangChain, and the difference is architectural rather than feature-level. LangChain is a library: you import components, own the process, and the agent exists only while your program runs. SwarmClaw is a runtime: agents persist, wake on schedules, hold memory across sessions, and report through a delegation hierarchy. If your problem is "call a model, parse the output, chain two steps", a library is lighter and you keep full control of the process lifecycle. If your problem is "keep twelve agents working on different queues and let a lead agent reassign work", a library means you write the scheduler, the persistence layer and the hierarchy yourself. The honest case against SwarmClaw is a single-agent, single-provider workflow with no scheduling. In that case you are paying for a runtime, its data directory and its upgrade cadence to get something a direct API call would cover. The delegation model is also a design commitment: a flat set of independent agents does not obviously benefit from an org chart, and the README does not describe a mode that skips the hierarchy.

Licence, maintenance and the cost of tracking a fast release train

SwarmClaw is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a permissive arrangement and it removes the licensing question from most adoption decisions; it does not remove the operational question. The repository is not archived, the last push is dated 2026-06-30, and three releases shipped between 2026-06-08 and 2026-06-30. A cadence that tight is a maintenance cost even when every change is small. You are choosing how often to move: pin a version and you carry the gap to the next one, track releases and you re-verify your agents against each bump. Because the README documents no migration procedure for stored memory, the version you pin is effectively the version whose data format you have agreed to. The desktop install adds a second variable, since app data lives in an OS-specific directory separate from CLI and Docker installs, so switching install methods means moving state by hand. This is not legal advice; read the LICENSE file in the repository for the operative terms.

Editorial conclusion

Adopt SwarmClaw if you want a self-hosted TypeScript runtime where provider choice, MCP tools and agent delegation live in one process you control, and you are comfortable reading the repository to fill gaps the README leaves. Do not adopt it if you need documented guarantees about memory retention, sandbox isolation or upgrade migrations, because the supplied material does not provide them. Before committing, verify three things yourself: which provider backends your agents will actually use, whether the Docker sandbox is required for the tools you enable, and what a version bump from v1.9.x to the next minor release does to stored agent data.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. swarmclawai/swarmclaw on GitHub