Claw Orchestrator: One Runtime for Claude Code, Codex, Cursor Agent and OpenCode

What problem Claw Orchestrator solves for multi-CLI teams

Coding CLIs assume a human at a terminal. Claude Code, Codex, Antigravity (agy), Grok Build and OpenCode each own their own invocation style, their own session lifetime and their own output format. If you want a long-running agent you have to keep a terminal open, and if you want two engines to look at the same task you write the glue yourself.

Claw Orchestrator turns those CLIs into headless engines behind one interface. The README describes it as a 77-tool API reachable through the CLI, the OpenClaw gateway, the Model Context Protocol, or directly from TypeScript. The audience is narrower than that sentence suggests: it is for people building agent workflows, not for someone who wants a nicer prompt. A solo developer running one CLI interactively gets nothing from a council that spawns parallel agents in isolated git worktrees. A team comparing Claude Code against Codex on the same repository, or wiring an editor to a coding agent over ACP, is the actual fit.

How the runtime, sessions and councils actually fit together

The architecture visible in the repository is a TypeScript core in src/ exposed through three binaries declared in package.json: clawo, clawo-mcp and clawo-acp. That is the whole surface. The CLI drives sessions, the MCP binary lets an MCP host such as Claude Desktop, Cursor, Cline, Continue, Zed, Windsurf or Goose call the same tools, and the ACP binary speaks Agent Client Protocol so an editor can drive the agent directly.

The multi-engine layer is an adapter set: one interface over Claude Code, Codex, Antigravity, Grok Build, OpenCode and arbitrary custom CLIs. Persistent sessions are the state layer, keeping an agent alive across requests with context, tool, model and worktree control. On top of that sit three coordination primitives with different costs. Fan-out runs one task across N engine/model agents in parallel and collects answers with an optional synthesis pass, with no rounds and no worktrees. Council puts parallel agents in isolated git worktrees and votes until they agree. Autoloop assigns separate engines and models to a Planner, a Coder and a Reviewer, then iterates.

The distinction matters when you budget. Council and Autoloop create worktrees and run multiple engines concurrently, so you pay in disk and in provider quota. Fan-out is the cheap cross-engine primitive, and the README is explicit that it has no rounds or worktrees. If you only need a second opinion from a different model, fan-out is the tool; council is for cases where you want convergence, not just diversity.

Installing Claw Orchestrator and running a first session

The package is published on npm as @enderfga/claw-orchestrator, and package.json declares Node 22 or newer. The repository also ships install.sh at the top level. The README does not spell out an install command in the excerpt available, so the npm route is the one the package metadata supports.

npm install -g @enderfga/claw-orchestrator
clawo --help

That installs three binaries: clawo, clawo-mcp and clawo-acp. Running clawo --help should list the tool surface the CLI exposes.

The README gives this example for enabling the Claude-side dynamic workflow, where Claude orchestrates a JavaScript workflow and fans out to subagents per task:

session_start({ ultracode: true })

The same call shape is the entry point for any session. The README does not document the full parameter list for session_start in the excerpt available; the sessions reference at skills/references/sessions.md is where the repository points for context, tool, model and worktree control.

To use it from an MCP host rather than the terminal, point the host at the clawo-mcp binary. The package description names Hermes Agent, Claude Desktop, Cursor, Cline, Continue, Zed, Windsurf and Goose as MCP hosts it drops into, and openclaw.plugin.json at the repository root is the OpenClaw plugin manifest for the plugin route.

Where Claw Orchestrator is the wrong tool

The strongest argument against it is operational weight. You are adding a Node 22 service, an embedded three-tab dashboard for Autoloop, Council and Forge with cookie-based auth behind a /login redirect, and a worktree-per-agent model. Each of those is a thing that can fail independently of the coding CLI you actually care about.

The second limitation is coupling to third-party CLIs. The runtime wraps Claude Code, Codex, Antigravity, Grok Build and OpenCode, and those tools change their invocation surfaces on their own schedules. The recent release history is instructive: v7.0.0 is titled "Two contributed fixes, and the five bugs they surfaced," and v7.1.0 and v7.1.1 are both weekly-sweep releases about a registry that had drifted and wrong prices that the sweep found. A project whose own release notes describe registry drift is one where you should expect to track upstream CLI changes rather than set and forget.

Third, council and Autoloop are expensive by construction. Parallel agents in isolated worktrees, voting until consensus, means N concurrent engine invocations per round. If your provider plan meters concurrency or spend, that cost is the feature, not a side effect. And if your task is a single-file edit, the whole apparatus is overhead.

Claw Orchestrator compared with OpenClaw and plain sub-agents

The relationship with OpenClaw is the comparison people search for, and the repository answers it structurally. Claw Orchestrator installs as an OpenClaw plugin through openclaw.plugin.json and exposes ./dist/src/index.js as an extension. So OpenClaw is the host and Claw Orchestrator is the thing that runs inside it, which is why one of the related searches is "Claw orchestrator vs openclaw." They are not alternatives at the same layer.

The real alternative is sub-agents inside a single engine. A sub-agent is spawned by the engine you are already running and lives inside that engine's process model and cost. Claw Orchestrator's fan-out and council primitives cross engines: you can put a Claude agent and a Codex agent on the same task and compare their answers, or have them vote. If your problem is "one model is not reliable enough," sub-agents may be sufficient. If your problem is "I want a second vendor's model in the loop without rewriting my call sites," the cross-engine layer is the point, and the OpenAI-compatible proxy at POST /v1/chat/completions is the piece that makes adoption cheap, since the README states it translates OpenAI requests into native Anthropic, OpenAI and Google calls and streams responses back in OpenAI shape. Point an existing OpenAI-SDK client at it and call sites do not change.

Maintenance, upgrades and what the MIT licence leaves to you

The repository is not archived, and the last push was on 2026-09-04, so the project is current as of this writing. The release cadence visible in the repository is fast: v7.0.0, v7.1.0 and v7.1.1 all landed on 2026-09-04, and package.json carries version 7.4.0 while the newest listed release is v7.1.1. That gap between the published package version and the release list is worth checking yourself before you pin anything.

Upgrade cost is real. Because the runtime adapts to external CLIs, a new Claude Code or Codex release can change behaviour under you, and the release notes show the maintainers running weekly sweeps to catch drift in a registry. Plan on reading CHANGELOG.md before each bump rather than upgrading blind, and pin a version in package.json if you run it in CI. The engines field requires Node 22 or newer, so your build image has to satisfy that.

The licence is MIT, which permits commercial use and modification with the copyright notice retained. That is a permissive baseline, but the CLIs Claw Orchestrator wraps carry their own terms, and the OpenAI-compatible proxy forwards your provider credentials to Anthropic, OpenAI and Google on your behalf. Those are the terms that will actually constrain a commercial deployment. This is not legal advice; read the licences of the wrapped CLIs and your provider agreements.

Editorial conclusion

Adopt Claw Orchestrator if you already pay for two or more coding CLIs and want one session model, one council primitive and one OpenAI-shaped endpoint in front of them; skip it if you only use a single CLI interactively, because the orchestration layer adds a Node 22 service, a dashboard with cookie auth and a worktree-per-agent cost you will not recover. Before committing, verify that your installed CLI versions are the ones the engine adapters expect, confirm what the OpenAI-compatible proxy does with your provider keys, and read the sessions, council and multi-engine reference files under skills/references/ rather than the README alone.

Frequently asked questions

Official sources

1. Enderfga/claw-orchestrator on GitHub
2. License: MIT
3. Project website
4. README
5. Releases