Marshal [WIP]

// what it does

One driver agent plans the work. Marshal spawns a fleet of headless coding agents to execute it: Cursor CLI, OpenCode, Codex, Command Code, and Claude Code, each running autonomously in its own isolated git worktree, in parallel. Marshal monitors them, collects their diffs, tracks what every provider charged, and hands the results back for review and integration.

The point is routing. Keep your best reasoning model focused on planning and reviewing diffs, send execution to cheaper or specialized workers, and measure what each routing strategy actually cost instead of guessing.

// how it works

• Adapters: five coding CLIs behind a single base class (plus an experimental Google Antigravity adapter). Adding a new agent is one subclass.
• Worktree isolation: every task runs in its own git worktree. Main is untouched until you read the diff and decide to integrate. "Succeeded" is not the same as "correct".
• MCP server: a lean 17-tool surface the driver calls: spawn, run_many, benchmark, collect_run, integrate, usage, and friends. One server can target several repos at once.
• Skills: orchestration playbooks that teach the driver how to run a fleet: decompose the goal, spawn workers, review each diff, integrate the good ones. Also review gates and plan consensus across independent agents.
• Usage tracking: per-provider tokens and cost on every run, so "which model should do this" becomes a benchmark result, not a vibe.

// why I built this

I kept giving one agent a list of independent tasks and watching it do them one at a time. The tasks didn't depend on each other. The bottleneck was the loop, not the model. Marshal turns that loop into a fleet: plan once, fan out, review what comes back. And since every provider claims their coding agent is the best, it also lets you run the same task across all of them on your own repo and see the receipts.

// stack

Python, MCP server, git worktrees, one adapter base class over five coding CLIs, per-provider usage accounting, declarative workflow recipes.

// what's next

• PyPI release
• More adapters behind the base class
• Richer benchmark reports for routing decisions