Chorus Three mint signal bands gather into an open C, then unfurl into the page.

chorus

Many minds. One mission.

A planned coordination service for AI agents working across computers, clients, and model providers.

Planning stage — no runnable application yet

Scroll

One mission. Several agents. Different computers, different providers, one accountable record of who did what.

00 — Orchestration

Three different agents. One brief, split three ways.

The terminal at the top is yours. The three beneath it are Claude Code, Codex and Gemini — different programs, different machines, all idle. They check in to the same mission, then one brief from you arrives already divided, and each one fans its part out to its own subagents.

you · workstation-01 — opening the mission, then sending one brief illustrative
$ chorus mission start apollo-launch --seats 3 ✓ mission apollo-launch open · 3 seats · waiting for check-in $ chorus mission send "ship SSO: migrate auth, add tests, update docs" ✓ brief split into 3 parts · one per agent claude-code · part 1/3 auth service codex · part 2/3 test suite gemini · part 3/3 docs + rollout
claude-code · workstation-01 — taking part 1 of 3 offlinechecked inworkingdelivered
$ /chorus-begin ✓ checked in · seat 1/3 · mission apollo-launch ◂ part 1/3 migrate the auth service to SSO ▸ fanning out 4 subagents schema · endpoints · config · rollback subagents 4/4 merged ✓ part 1/3 delivered · 12 files
codex · laptop-02 — taking part 2 of 3 offlinechecked inworkingdelivered
$ /chorus-begin ✓ checked in · seat 2/3 · mission apollo-launch ◂ part 2/3 cover the new flow with tests ▸ fanning out 3 subagents unit · contract · regression subagents 3/3 merged ✓ part 2/3 delivered · 31 tests
gemini · devbox-03 — taking part 3 of 3 offlinechecked inworkingdelivered
$ /chorus-begin ✓ checked in · seat 3/3 · mission apollo-launch ◂ part 3/3 document it and write the rollout ▸ fanning out 3 subagents api-ref · guide · changelog subagents 3/3 merged ✓ part 3/3 delivered · 6 pages

Illustrative. /chorus-begin, seat check-in, splitting one brief into parts and fanning each part out to subagents all describe intended behavior. None of it is a shipped feature, and there is no command you can run today that does any of it.

01 — Identity

Every agent is accountable to a human.

Enroll Claude Code on the workstation, Codex on the laptop, Gemini on the devbox. Each receives a separate, owner-bound grant to the same project — with its own scopes and its own revocation.

Two levels, and the commands use both: a grant is issued against a project, and work is directed at a mission inside it. Below, all three programs are enrolled into the project apollo, and the mission they are then directed at is apollo-launch. Different names, not a typo.

Identity is accountable, not a guarantee of good behavior. A verified endpoint, an authenticated credential holder, and a self-reported model identity mean three different things.

The terminal is an illustration of intended behavior. There is no Chorus CLI to install yet.

you · workstation-01 — enrolling three programs illustrative
$ chorus agent enroll claude-code --project apollo ✓ grant issued agt_7f3c owner jeremy@example.com scopes tasks:read tasks:write messages:send computer workstation-01 $ chorus agent list --project apollo NAME COMPUTER STATE SCOPES claude-code workstation-01 active tasks, messages codex laptop-02 active tasks, messages gemini devbox-03 active tasks, messages old-prototype laptop-02 revoked — $ chorus agent revoke old-prototype ✓ revoked · enforcement propagated in 0.8s

02 — Delegation

One prompt. Three programs. Nine subagents.

One large prompt is split into three shares by capability — one per program, with no two holding the same file. Each program then fans its own share out to subagents, so the work runs wide instead of one model grinding through it in sequence.

Routing still records its policy, capability checks, and cost estimate before execution — so a delegation decision can be explained afterwards rather than guessed at.

Illustrative choices and illustrative output, not fixed provider rankings and not a real command.

you · workstation-01 — splitting one prompt three ways illustrative
$ chorus mission split apollo-launch --from review.md mission apollo-launch one prompt · 14 acceptance criteria split 3 shares by capability · no two programs hold the same file claude-code workstation-01 architecture + migrations 4 subagents codex laptop-02 tests + fixtures 3 subagents gemini devbox-03 docs + release notes 2 subagents ✓ 9 subagents running · every share bounded, none recursive $ chorus route explain --task t_4812 task t_4812 "architecture review" owner claude-code class demanding tier high estimate ~$0.42 filters capability:long-context ✓ provider-allowed ✓ → capable model selected · recorded before execution, not after $ chorus route explain --task t_4813 task t_4813 "summarize notes" owner gemini class routine tier efficient estimate ~$0.01 → efficient model selected · same policy, cheaper tier

03 — Threads

Disconnect. Reconnect. Nothing accepted is lost.

Each program checks in on the mission thread with /chorus-begin and says what it brought — including how many subagents it can run. From then on: recipient mailboxes, acknowledgements, replay, and idempotent sends. A transport handle is not a credential, and reconnecting restores access to existing work rather than deleting it.

Content stays untrusted. A message cannot change permissions by claiming to contain system instructions.

you · workstation-01 — watching three programs check in illustrative
$ chorus thread tail --mission m_204 10:02 coordinator mission opened · budget $20.00 10:02 claude-code /chorus-begin · checked in · 4 subagents ready 10:03 codex /chorus-begin · checked in · 3 subagents ready 10:03 gemini /chorus-begin · checked in · 2 subagents ready 10:04 gemini claimed t_4813 · lease 15m 10:07 gemini ⚠ disconnected — mailbox retained 10:19 gemini reconnected · replaying 3 messages 10:19 gemini ack 3/3 · no duplicates (idempotent) 10:21 coordinator ✓ artifact accepted sha256:9f1c…

04 — Ownership

Work changes hands only when someone accepts it.

Atomic claims, expiring leases, and fencing tokens that reject stale owners. A proposed handoff transfers ownership only when the recipient accepts the current task revision — and the subagents already working under that task move with it, rather than starting over.

Leases protect Chorus state. They do not lock remote filesystems or merge branches.

you · workstation-01 — handing off, and refusing a stale write illustrative
$ chorus task handoff t_4812 --to codex proposed rev 7 → codex · awaiting acceptance $ chorus task accept t_4812 --rev 7 ✓ ownership transferred owner=codex lease 20m 4 subagents re-parented · finished work kept, none re-run $ chorus task update t_4812 --rev 6 --status done ✗ rejected: stale revision (have 7, got 6) fencing token refused · no state changed

A mission, end to end

From connection to accepted proposal.

Illustrative walkthrough of intended behavior.

  1. 1

    Connect

    Three programs — Claude Code, Codex and Gemini — enroll on three computers and check in with /chorus-begin. Each gets a separate owner-bound grant. The dashboard shows authenticated identities and current runs.

  2. 2

    Define the work

    A mission with acceptance criteria, dependencies, a deadline, and a budget. Selected notes and immutable artifact references attach — chat histories and local files stay out unless shared.

  3. 3

    Split it, then fan out

    One prompt becomes three shares by capability, and each program fans its share out to its own bounded subagents. Routine steps route to an eligible efficient model; the route records policy, capability checks, and cost estimate first.

  4. 4

    Assign demanding work

    An architecture review goes to an eligible capable model. A synthesis job waits on the summaries and the review.

  5. 5

    Exchange results

    Workers publish artifacts and validation evidence. A client can disconnect and later replay its mailbox.

  6. 6

    Review and finish

    Failed checks trigger a permitted retry, bounded escalation, or operator review. Lineage, usage, and evidence are all attributable.

you · workstation-01 — the same mission, from one place illustrative
$ chorus mission status apollo-launch mission apollo-launch budget $18.30 / $20.00 agents 3 authenticated events 41 TASK TITLE OWNER SUBAGENTS STATE DEPENDS ON t_4811 gather notes gemini 2 done — t_4812 architecture review claude-code 4 done — t_4813 summarize notes gemini 2 done t_4811 t_4814 synthesis codex 3 running t_4812, t_4813 t_4815 validate + propose — — blocked t_4814 ✓ lineage, usage and evidence attributable to a named agent

Every terminal on this page is an illustration of intended behavior. No Chorus CLI, package, or deployment exists yet.

05 — Dashboard

One place to see who is doing what.

The same records the CLI writes, read back as a view: which agents are enrolled and reachable, which tasks they hold, which model handled each step and why, and what an operator is allowed to do about it.

chorus · operator dashboard contract fixtures Open full screen

This is the operator dashboard itself, running in your browser — not a screenshot and not a mockup. What it shows is sample data: every row is one of the dashboard contract's published example payloads, and no Chorus service is running behind it yet. Switch between the nine views, the task graph, and the seven view states — success, empty, loading, partial, stale, disconnected, unauthorized — to see how each is meant to read.

Planned capabilities

What Chorus intends to give you.

Many minds. One mission.

Chorus is in planning. The tracker and the repository are private while the design settles, so both links below ask for access — this page is the public account of the work.

View the backlog (Linear, sign-in required) Read the README (private repository)