Claw Orchestrator: A TypeScript Runtime That Wraps Coding CLIs as Persistent Sessions

The Gap Between Interactive Coding CLIs and Anything You Can Script

Coding CLIs assume a human at a terminal. Claude Code, Codex and their peers are built around an interactive loop: you type, the agent responds, context accumulates in the process. The README states this directly, framing the project as turning those CLIs into headless engines. That framing identifies the actual problem. If you want to run the same task across three engines and compare answers, or keep an agent alive across HTTP requests without losing its context, or expose a coding agent through an MCP server that an editor can drive, the CLI itself gives you no handle. You would be scripting a terminal emulator and parsing output.

Claw Orchestrator is aimed at engineers building on top of coding agents rather than using them directly. The 77-tool API, the ACP agent, the MCP server and the OpenAI-compatible proxy are all consumption surfaces for the same underlying session model. The audience is narrow but specific: platform teams, tool builders, and anyone wiring agents into an existing editor or SDK workflow. A solo developer who just wants Claude Code to refactor a module is not the target and gains nothing from the abstraction.

Sessions, Worktrees and the Council Mechanism

The core primitive is the persistent session. According to the README, sessions are long-lived coding agents kept alive across requests, with control over context, tools, model and worktree. That last item is the load-bearing one. A session is bound to a git worktree, which is what makes parallel agents safe: two agents editing the same checkout would collide, so each gets its own.

The council mechanism builds on that. Parallel agents run in isolated git worktrees and vote on consensus until they agree, per the feature table. The reference file is council.md. Fan-out is a lighter sibling: one task across N engine and model agents in parallel, answers collected, with an optional synthesis pass. The README is explicit that fan-out uses no rounds and no worktrees, which distinguishes it from a council. If you want independent answers rather than negotiated agreement, fan-out is the cheaper path.

Autoloop goes further and assigns different engine and model selections to three roles: Planner, Coder and Reviewer. You chat with the Planner; it spawns the other two into a self-iterating subloop and pushes you when it hits a regression, a target, or a decision point. Ultraapp is the most opinionated instance of the same pattern: a three-agent Opus council takes a five-question interview and produces a deployed web app with Tailwind UI, BYOK, a file-queue runtime and a smoke test, served at localhost:19000/forge/<slug>/. That is a lot of machinery behind one interview, and the README does not describe what happens when the generated app fails its own smoke test.

One Interface Over Five Engines, Plus Whatever You Bring

The multi-engine layer is the part most likely to justify the dependency. The README lists Claude Code, Codex, Antigravity (agy), Grok Build, OpenCode, and arbitrary custom CLIs behind one interface. The reference is multi-engine.md. A custom CLI is the escape hatch: if your internal tool speaks a compatible protocol, it can be registered as an engine without waiting for upstream support.

The OpenAI-compatible proxy is the second integration point. POST /v1/chat/completions accepts OpenAI-shaped requests and translates them into native Anthropic, OpenAI and Google calls, streaming responses back in OpenAI shape. The practical consequence, as the README puts it, is that you can point any OpenAI-SDK client at the orchestrator without changing call sites. For teams with existing code written against the OpenAI SDK, that is a smaller migration than rewriting to a new client library.

What the material does not say is how the translation handles features that do not map cleanly between providers, such as tool-call schemas, system prompt placement, or streaming chunk boundaries. Any proxy that spans three vendors has to make choices there. The README describes the shape of the translation, not its fidelity, so treat cross-provider equivalence as something to test against your own prompts rather than assume.

Getting It Running: Package, Surfaces and Config Keys

The project ships as an npm package, @enderfga/claw-orchestrator, and the README badge links to the npm version. The primary language is TypeScript, the licence is MIT, and the default branch is main. Installation and invocation commands are not reproduced in the supplied README excerpt, so the exact CLI verb and flag set cannot be confirmed from this material. Check the repository README for the install line before planning a rollout.

What the material does give you is the configuration surface at the API level. Sessions are started with session_start, and the ultracode feature is enabled by passing { ultracode: true } to that call, which lets Claude orchestrate a dynamic JS workflow and fan out to subagents per task. That option is documented as Claude-engine only, so it is not a cross-engine feature. The dashboard is embedded, three tabs covering Autoloop, Council and Forge, with sidebar lifecycle controls, per-run live event streaming, and cookie-based auth behind a /login redirect. The proxy endpoint is POST /v1/chat/completions. The generated apps from Ultraapp land at localhost:19000/forge/<slug>/.

Reference documentation is split per capability: sessions.md, multi-engine.md, council.md, autoloop.md, ultraapp.md, dashboard.md and tools.md, all under skills/references/. That layout suggests the README is an index rather than a manual, and the real operational detail lives in those files.

Where the Design Gets Expensive

The worktree requirement is the first constraint. Councils run agents in isolated git worktrees, and Ultraapp generates and deploys an app. Both assume a working git environment and enough disk for parallel checkouts. In a container without git, or on a repository where worktrees are impractical, the council path is unavailable and you are left with fan-out or single sessions.

The second cost is the surface area. A 77-tool API is a large contract to learn, and the README does not indicate which tools are stable. The release history is the clearest signal here. Three releases landed on the same day: v7.0.0, v7.1.0 and v7.1.1. The v7.0.0 notes describe two contributed fixes and the five bugs they surfaced. v7.1.0 is titled as a weekly sweep where the registry had drifted and so had its guard. v7.1.1 continues the sweep and reports finding two more wrong prices. A major version bump followed within hours by two patches, with the notes explicitly describing newly discovered defects, tells you the project is moving fast and that its own maintainers are still finding errors in shipped data. If you need a frozen API, pin a version and expect to do the upgrade work yourself.

The third limitation is scope confusion. Autoloop and Ultraapp are demonstrations of what the runtime can do, not the runtime itself. Teams that adopt Claw Orchestrator for the council primitive may find the autonomous loops more opinionated than their workflow allows. Nothing in the material suggests the two are separable at the configuration level, and the dashboard treats them as first-class tabs.

How This Differs From a Single-Vendor Agent SDK

The obvious alternative is to build against one vendor directly, for example the Anthropic SDK if you are standardising on Claude Code. That path gives you a supported client library, a stable API surface, and no translation layer between your request and the model. The difference in approach is fundamental: a vendor SDK assumes one provider and optimises for it, while Claw Orchestrator assumes several and pays for that with an abstraction layer and a proxy that must reconcile three request shapes.

A second alternative is a general agent framework with pluggable model backends. Those typically treat the model as a function you call, leaving the coding CLI out of the picture entirely. Claw Orchestrator's distinguishing choice is that it wraps the CLI, not the model API. That means you inherit whatever the CLI does well (file editing, tool use, repository context) and whatever it does badly (startup latency, opaque internal state). It also means the orchestrator's capabilities are bounded by what each CLI exposes.

The trade-off is concrete. If you only ever use one engine, the multi-engine layer is dead weight and a vendor SDK is simpler. If you need cross-engine comparison, or an OpenAI-shaped endpoint in front of Anthropic and Google backends, the abstraction is the product. The README's own framing, that it stacks an agent platform on top of headless engines, is the honest description of which side of that line it sits on.

Licence, Maintenance and What to Check Before Committing

The licence is MIT, per the repository badge and metadata. That permits commercial use, modification and redistribution with the licence and copyright notice retained. It does not by itself settle the licence terms of the underlying CLIs you wrap, the models you call through the proxy, or the generated app's dependencies. Those are separate questions and this material does not answer them. If you are shipping a product on top of Claw Orchestrator, review the terms of each engine you register and each provider you route through /v1/chat/completions.

Maintenance cost is the practical concern. The project is not archived and was pushed to recently, and the release notes show an active weekly cadence with regression fixes. That cuts both ways: bugs get found and fixed quickly, and interfaces change. Budget for reading release notes on every minor bump, and pin the npm version in your lockfile rather than tracking latest.

The concrete next step is to read skills/references/multi-engine.md and confirm your target CLI is supported, then start one session with session_start and verify that context survives a second request. If you plan to use the proxy, send a request with a tool call to /v1/chat/completions and compare the response shape against what your OpenAI-SDK client expects. Those two checks answer most of the adoption question before you write any integration code.

Editorial conclusion

Adopt Claw Orchestrator if you already run at least two coding CLIs and want a single programmable surface over them, or if you need an OpenAI-compatible endpoint that fans out to Anthropic, OpenAI and Google backends. Do not adopt it if you want a single self-contained agent, if you cannot run git worktrees, or if you need a stable API before you commit: the release cadence shows breaking changes shipping weekly. Verify first that your target CLI is on the supported engine list, that your Node and TypeScript toolchain matches the package, and that the 77-tool surface does not exceed what your use case actually needs.

Official sources

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