cezar: a cockpit for running many coding agents in parallel on git worktrees

A control center over the agent CLIs you already use

cezar is described as an open source orchestrator and agent development environment for running Claude Code, Codex, OpenCode, Pi and other AI coding agents in parallel, locally or around the clock on your own server. The framing in the header is more aggressive, orchestrating hundreds of agents 24/7, and the site is at cezar.run.

What it actually sits on top of is worth being precise about, because it is the design decision that defines the product. cezar does not talk to a model API. It drives the command line tools: your claude, codex, copilot, cursor, junie, opencode or pi login, with no API key needed. That single constraint explains a lot of the rest of the design. The agent is whatever you already use and pay for, and cezar is the layer that schedules, isolates, observes and reviews them.

The primary language is TypeScript, the package is published to npm as @open-mercato/cezar, and the repository is a monorepo with the contract, api-client, cezar and web workspaces, plus separate alias packages for the older command names. The licence is MIT, the project is free and open source, and it needs Node 20 or later.

Git worktrees are the isolation mechanism, not an implementation detail

Every task gets its own git worktree, so several agents can work at the same time, and extra tasks wait in a queue rather than piling onto the same checkout. That single decision is what makes parallel agent execution safe enough to be a product feature rather than a script someone runs carefully once.

The problem it solves is obvious once you have tried it. Two agents editing the same working tree produce conflicting edits, and the usual workarounds are either one agent at a time, which defeats the purpose, or a manually prepared set of branches, which does not survive contact with a long queue. A worktree per task gives each agent a clean directory with its own branch, and the queue handles the overflow.

The feature list extends that idea into delegation. Agents can delegate independent work to child tasks, each in its own worktree, and receive their reports back in the parent session, so a parent task can fan out and collect. There is also a variant mode that runs the same task two or three times, compares the diffs and lets you keep the best one, which is a reasonable answer to the fact that agent output is variable.

The project also runs the agent straight on a GitHub issue, and states plainly that nothing merges on its own, which is the guardrail that makes an autonomous mode acceptable at all.

Autonomous mode, live telemetry and a plain file store

Three parts of the feature list define the day to day experience.

Autonomous mode is the one that changes the shape of the work. Turn it on and a run never stops to ask, it just finishes, which is what makes the VPS deployment meaningful, since the point of a server is that the work continues while your laptop is closed. The interface is fully responsive, so you can start and review tasks from your phone.

The live run view shows agent text, tool calls, tokens and cost as they happen, and the usage and cost section tracks reported cost and token usage by project, with a breakdown across projects. The workspace dashboard is the summary view: what needs you, what is running, and what finished, across all your projects in one cockpit.

And the storage model is plain. There is no database, everything is saved as files under .ai/cezar/. That is a deliberate tradeoff in favour of inspectability and portability, and it means the state of your agent runs is something you can read, diff and commit rather than something trapped in a service. The repository root shows the same convention with a .ai/ directory, a .mcp.json file and a .env.example.

Skills as Markdown, workflows as YAML, and a graph builder on top

The configuration surface is deliberately small and human readable. Skills are Markdown files and workflows are short YAML files, and you can mix agents per step, so one stage of a pipeline can run on one CLI and the next on another.

The workflow builder is where that becomes visual. The screenshot description calls it a node graph with agents, checks, loops, gates, PRs and CI, saved as YAML, which is a better description than a flow chart because it names the node types: an agent step, a check that can fail, a loop, a gate that blocks until something is approved, a pull request step and a CI step. The YAML is the source of truth and the graph is the editor, so the workflow is reviewable as a diff.

The integrations around that are more conventional. You can connect Jira or Linear to browse issues and launch tasks from your project tracker, and automations let you schedule recurring work or launch tasks from GitHub and supported tracker events, with a weekly calendar view of what is planned. The tracker connections matter because they are the point where the orchestrator meets the rest of the company workflow, and the automations are the point where it stops being a thing you start by hand.

There is also a note in the README that reads like a compatibility warning rather than documentation. GitHub list rows may omit body in the next minor release, and consumers should hydrate the full text from the comments endpoint now, which is the kind of detail you only write down if you have already been bitten.

Running it: two commands, a local port and a headless mode

The quick start asks for Node 20 or later and at least one agent CLI you are logged into, with git and gh as optional extras. Then you run it from the repository you want to work on.

cd your-repo
npx cezar-run

That opens the cockpit at http://localhost:4321, where you type a task, pick a workflow and hit Start. The older command name still works, since npx cezar-cli is the same package under its previous name, and the repository carries alias packages for both.

There is a headless variant for scripting.

npx cezar-run run "add a --json flag to the export command"   # headless, no browser

The same package also installs as a command, with install-as-command and install-as-command:global scripts in the manifest, and a set of server-install, server-deploy and server-uninstall scripts for the VPS case. The dev launcher in scripts/dev.mjs is used by npm run dev, and the environment file explains that it probes for a free port and sets CEZ_API_PORT automatically, with 4321 as the default.

The .env.example file is unusually informative about the deployment mode, and that is the part to read before putting this on a server. The default local mode exposes host-only conveniences such as opening a file in your editor, in Finder or in a terminal, plus a worktree path handoff and a launch bookmarklet. Setting the deployment flag to 1 for a VPS or hosted mode hides those, because the cockpit is being viewed over the network. The same file notes that the Add project browser is always confined to a browse root, defaulting to the home directory, and suggests setting that root narrowly for a hosted cockpit so a remote viewer cannot enumerate the whole home directory.

Active development, an unusual release scheme, and a desktop build

The release history mixes two versioning schemes, and understanding it tells you what to install.

The listed releases are desktop-v0.1.8 from 2026-10-19, v0.15.2 from 2026-10-14 and v0.15.1 from 2026-10-13. So there is a rapidly moving CLI and library line in the v0.15 series, and a separate desktop application line at v0.1.8 that is younger still and shipped the day before the last push. The last push was on 2026-10-20 and the repository is not archived, so the code is very much in motion.

The desktop build being a separate line makes sense given the feature list, since reviewing a diff from a phone is a different product from the cockpit, and a native shell around the same web UI is a reasonable way to ship that.

The repository also carries the artefacts of a serious development setup. There is a monorepo with four workspaces, a contract package that presumably defines the API between server and web, an api-client package, and a separate web package. Testing is split into unit, package and e2e tiers with vitest as the runner and a shell script for the end to end suite, and type checking is done per workspace through a chain of scripts. There are the documents you would expect from a project that wants outside contributors to succeed, including AGENTS.md, AGENT_PROTOCOL.md, CODE_REVIEW.md, SDLC.md, SECURITY.md, CHANGELOG.md and BACKWARD_COMPATIBILITY.md, and the README is translated into Simplified and Traditional Chinese alongside the English original. Pull requests are explicitly welcomed.

Editorial conclusion

Adopt cezar if you already run coding agents from the command line and want several of them working at once on separate branches, since the worktree isolation, the live run view and the headless mode turn a single interactive session into a queue you can leave running. Do not adopt it if you need per task API keys or a hosted control plane, because the design deliberately reuses your existing CLI login and keeps all state in plain files. Before you point it at a repository, read the deployment mode variables in .env.example, since the local mode exposes host conveniences such as opening files in your editor that you want switched off on a VPS, and note that the repository has no tagged releases.

Frequently asked questions

Official sources

1. License: MIT
2. open-mercato/cezar on GitHub
3. Project website
4. README
5. Releases