orch

Run AI agents as a team. Show your client a live page, not a status thread.

orch walks a graph of tasks and hands each one to the coding agent you route it to — Claude Code, Codex, Gemini, OpenCode, Antigravity or Muse — in parallel, each in its own git worktree. It checks every change before it is pushed, pauses a provider when its budget window fills, and publishes a page your client can open to see where the work stands.

Install orch Try a spec in your browser

Already installed? orch start "a habit tracker with streaks" goes from one sentence to agents working. orch dashboard --demo shows a finished project without touching yours.

orch run

The six tasks of the nextjs-saas template, routed to three agents. A task starts only when everything it depends on is done; the client page counts what is finished.

How it works

  1. Write the work down

    Start from an idea: orch start sets the project up with the agent CLIs you have, and its planning skills take the idea through a PRD, an architecture and specs to a task graph — each phase a vertical slice that opens with a walking skeleton. Or write the specs yourself — phases, packages, tasks, the model for each and what it depends on — and orch atomize turns them into tasks.json, showing the diff before anything is written. There are also five project templates, and you can try a spec in your browser.

    $ orch start "a SaaS starter with auth and billing"
$ orch tasks
Tasks (6 shown)
ID     STATUS  BACKEND/MODEL             DEPS
F0.T1  todo    claude/claude-sonnet-4-6  —
F1.T1  todo    claude/claude-sonnet-4-6  [F0.T1]
F1.T2  todo    claude/claude-sonnet-4-6  [F1.T1]
F2.T1  todo    claude/claude-sonnet-4-6  [F0.T1]
F2.T2  todo    claude/claude-sonnet-4-6  [F1.T1 F2.T1]
F3.T1  todo    claude/claude-sonnet-4-6  [F0.T1 F2.T1]

  2. Route each task to an agent

    model_router.yaml maps every model name to the CLI that runs it — claude, codex, gemini, opencode, agy or muse — with your own logins and your own keys. orch init asks each installed CLI which models it really has. Concurrency caps and a rolling token budget per provider decide how much runs at once; when a provider runs out of quota, its tasks fail over to another. orch estimate says what the next run will cost and take before it starts, and orch router suggest tells you which route has worked for which kind of task.

    $ orch doctor
Ready to `orch run`.
$ orch explain
Tasks: 6 total, 0 done (0%)
  todo         6
  blocked      0

Ready to dispatch: 1
  F0.T1      Next.js 14 App Router scaffold + Tailwind + shadcn/ui

  3. Run it

    orch run dispatches every ready task at once, each in its own git worktree and branch. Before anything leaves your machine, the task's work runs the repository's checks and a read-only review by a different provider; what fails goes back to the same agent. Then it opens a pull request per task — or, with vcs.provider: local, merges into your branch with no remote at all — watches CI, retries what failed for a reason worth retrying, and blocks, with the reason written down, what should not be retried. Ctrl+C drains: nothing new starts, work in flight finishes.

    $ orch run
$ orch tui
$ orch events F2.T2

  4. Steer it while it runs

    Follow any agent's steps live — tool calls, text, errors. Stop a task, hold it, or redirect it with a note that reaches its next attempt. Review a finished task's diff in the dashboard and accept it or send it back. Add tasks or edit them, from the CLI or the dashboard, and the running orch run picks them up. What one task learns the hard way is written to .orch/knowledge/ and reaches the prompts of the tasks after it.

    $ orch task stop --id F2.T2 --note "use the existing auth client"
$ orch task accept --id F1.T2
$ orch task add --id F3.T2 --title "Billing webhooks" --model claude/claude-sonnet-4-6 --deps F3.T1
$ orch knowledge list

  5. Hand your client a link

    orch publish writes the client page as a static site — phases, blockers in plain language, how fresh the numbers are — to a folder or a gh-pages branch, and keeps it current with --watch. The page it writes has no login and no API: it is files. If your client should watch it live instead, the dashboard's Share button opens a Cloudflare quick tunnel or Tailscale, and gives you a client link that only works with its token.

    $ orch publish --to git --watch
$ orch dashboard --tunnel

What orch checks so you do not have to

A second opinion before the push.
The local verify runs your tests and linters in the task's worktree and asks another provider to review the diff. Only work that passes is pushed.
Tests first, if you want them.
With dispatch.tdd the agent writes one failing test per acceptance criterion before the code. verify.e2e brings the task's app up on its own port and runs Playwright against it, keeping the screenshot and video of what failed.
No secrets in a pull request.
The pre-PR guard scans each diff: an API key, a private key or a .env file blocks the task; a stray console.log or debugger gets a warning.
Parallel tasks that do not collide.
The conflict radar compares a task's files with the ones already running before it dispatches, and each new PR with the open ones. Warn, or wait your turn.
An agent that stalls is noticed.
A log that goes silent or an agent repeating the same call is flagged while the run goes on, with the command to stop it.
Committed work is never thrown away.
A retry keeps the earlier attempt's commits on their own branch, and a PR that conflicts with its base gets a conflict retry instead of a block.
Agents stay in their folder.
On Linux, dispatch.sandbox confines each agent to its worktree with Landlock. It is opt-in and does not limit the network.
Ready before you run.
orch doctor ends with a verdict — ready, or the first blocker and how to fix it — and --smoke sends a real throwaway task through every installed CLI.

A real run, in 29 seconds

orch init, the plan, orch run dispatching two claude tasks that each open a pull request with green CI, then the client page moving from 0% to 50% to 100% on its own.
A real run, sped up: orch init --template python-api, orch run with claude, two PRs with green CI, and the client page updating itself. What was set up off camera.

What your client sees

The page is built from one snapshot of the project, written for someone who does not care what a worktree is.

  • Progress by phase, in the names you gave them, and what was delivered this week.
  • Blockers translated out of stack traces into sentences.
  • An estimated delivery date, and how fresh the numbers are.
  • Spend only if you choose to show it. It is off by default.
  • Your agency's name, logo and colour instead of orch's, if you set them.
The client view of a sample project: 16 of 30 deliverables done, progress by phase, the estimated delivery date, two items on hold explained in plain words and what was delivered this week.

What you see

Your own screen answers three questions: which agents are working right now, what is waiting for you, and how much of each provider's budget window is left. Work shows the graph as a list, a board, phases and pace; Usage splits tokens by model, task and attempt; System lists the tools you are missing and how to install each.

Ctrl K opens a palette that jumps to a task, filters the board or copies the CLI command for what you are looking at. When a run ends it leaves a receipt — tasks, wall time, agent time and spend per provider, and a summary in plain words — that you can copy as Markdown or an image. In a terminal, orch tui shows the same run; to your own agent, orch mcp exposes it as tools.

The Now screen of a running project: three agents on claude, codex and opencode with their elapsed times, two blocked tasks needing attention, progress per phase, the budget window per provider and the last run's receipt.

Where orch stops

It runs on your machine.
No daemon and no hosted service. You start orch run; it stops when the queue is empty or you stop it.
The agents are yours to install.
orch drives the CLIs you already use and are signed in to. It never holds a model key.
It is one operator's tool.
Several projects at once, yes. Several people editing the same plan, no — that is a project tracker's job.
It needs git, not GitHub.
Pull requests go through gh or glab. Without a remote, vcs.provider: local merges finished tasks into your branch here.

Install

One command. orch is a single binary for Linux and macOS, on amd64 and arm64.

curl -fsSL https://raw.githubusercontent.com/Guria-Studio/orch/main/scripts/install.sh | sh

It downloads the latest release, checks it against checksums.txt, and puts orch in ~/.local/bin — set INSTALL_DIR for somewhere else.

Build from source instead 
git clone https://github.com/Guria-Studio/orch
cd orch
make build
./bin/orch --version

Needs Go 1.25+ and pnpm.

Then, in a git repository: orch start "what you want to build" sets the project up, plans it and runs it, asking before it spends. To go step by step instead: orch init, orch install-skills --all to give your agent the planning skills, and orch doctor to check that every CLI your tasks route to is installed and signed in. orch dashboard --demo opens a finished project of its own, so you can look at the dashboard before you run anything. The manual walks through the rest.

Follow the build