Chorus: Multi-LLM Peer Review Using the AI Subscriptions You Already Pay For
Multi-LLM peer review for code decisions. Bring your own CLI; Chorus convenes 2-4 other LLMs to review the work before you ship.
At a glance
- What is it?
- Chorus is a local-first TypeScript tool that fans a diff or task out to 2 to 4 different vendor CLIs and only green-lights when they agree. The interesting part is the billing model, not the review logic.
- Who is it for?
- Adopt Chorus if you already hold a Claude Pro, ChatGPT Plus or Gemini Advanced subscription, work on a laptop or workstation where the code may leave the machine, and want a second vendor's eyes on AI-written diffs without opening a metered API account.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 34 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Blind Spot Problem Chorus Is Aimed At
The README makes a narrow claim: AI coding tools are wrong roughly 5 percent of the time in ways that are hard to spot before production, and a model reviewing its own output shares the training and the biases that produced the error. That second point is the whole product thesis. Asking GPT to check GPT is, in the project's phrasing, theatre. Chorus exists to put a different vendor between the author and the merge button.
The target user is fairly specific. You write code with an AI assistant, you already pay for one or more of Claude Pro, ChatGPT Plus or Gemini Advanced, and you are not willing to open a metered API account just to get a second opinion on a diff. The README frames the economics bluntly: every diff times three reviewers times pay-per-token adds up, so nobody does it routinely. Chorus routes the same prompts through the CLIs those subscriptions already authorize, which the project describes as costing zero out of pocket and consuming quota you have already bought. Whether that framing holds depends on your provider's terms, which are not discussed in the material.
How the Fan-Out Actually Works
Chorus is a local Node process with a browser UI on port 5050 by default. You install it globally, run an init step that detects installed AI CLIs and registers Chorus as an MCP server with them, then start the server. A review begins as a chat: the MCP tool create_chat takes a template name and a work payload, and returns a chatId, a URL and a status. The example in the README passes template code-review and a work string describing the staged diff versus main, with instructions to flag race conditions and missing tests.
The fan-out is where the design decision lives. Two to three different AI tools review the same change in parallel, and the run only green-lights when they agree. Disagreement is surfaced as a red flag rather than averaged away. The README also describes a red-green template for test-driven work: one AI writes tests while blind to the code, another writes code to pass them. That is a genuinely different use of the same plumbing, and it is the most interesting template mentioned, because the isolation is structural rather than prompted.
Control flow is exposed as MCP tools rather than a library API. wait_for_chat blocks until a terminal state, get_chat_status polls without blocking, cancel_chat and resume_chat stop and restart, and list_blocked shows chats waiting on human input. There are nine tools in total, and every supported CLI exposes them under the same name, chorus. The server is also reachable directly through the browser UI, so the same run can be watched live at localhost:5050/runs/<chatId>.
Install, Init, and the Sudo Trap
The quick start is three commands. npm i -g chorus-codes installs the package. chorus init finds the AI tools you already have and wires up MCP. chorus start --ui opens the browser interface at http://localhost:5050. Upgrades go through chorus update, which the README says locates the running binary and writes to that exact install location so the new version lands where PATH expects it regardless of how the original install was done.
The README spends real space on one failure mode: do not run sudo npm install -g if you use nvm, fnm, asdf or any per-user Node manager. Sudo writes to root's npm prefix under /usr/local, while the chorus command resolves through your user prefix, so the install succeeds in a directory PATH never sees and you stay on a stale version. The suggested fix for an EACCES error is npm config set prefix ~/.npm-global followed by adding ~/.npm-global/bin to PATH. That is a common npm footgun, but it is worth noting that the project documents it rather than papering over it.
Requirements are Node 20 or later and at least one of Claude Code, Codex CLI, Gemini CLI, OpenCode or Kimi CLI, or alternatively an OpenRouter API key. The README notes OpenRouter gives one key across 200-plus models on a pay-per-use basis, which is the escape hatch if you hold no subscriptions at all.
The Codex Headless Limitation and Other Rough Edges
The most concrete limitation in the material concerns Codex. According to the README, codex exec blocks all MCP tool calls under any approval_policy setting. To use Chorus from codex exec for scripted or CI work, you must pass --dangerously-bypass-approvals-and-sandbox. Interactive codex in TUI mode prompts normally and works without the flag. The README links issue #16 as the tracking item, which tells you the maintainers consider this unresolved rather than intended.
That flag name is doing a lot of work. Passing it in a CI job means the agent runs with approvals and sandboxing disabled, which is a materially different risk posture than the interactive path. If your pipeline depends on Codex as one of the reviewers, you are choosing between a bypass flag and dropping Codex from the fan-out. Neither is free, and the README does not offer a third option.
There is a second, quieter constraint. The pitch is that your code never reaches a new vendor, which is true in the sense that Chorus does not introduce a broker. But the entire mechanism is sending your diff to two to four external vendors. If your code cannot leave your network at all, Chorus does not help, and no configuration in the material changes that. The local-first framing describes where the orchestration runs, not where the code goes.
Finally, the material contains no release history. The repository shows a last push in August 2026 and no retrieved releases, so there is no version timeline to reason about upgrade risk from. Treat chorus update as a moving target until you can see a changelog.
Where Chorus Sits Against a Single-Reviewer Setup
The obvious alternative is not another multi-model orchestrator. It is running one CLI directly: ask Claude Code to review the staged diff, read the output, move on. That approach is simpler, has no MCP registration step, no port 5050 server, and no fan-out latency. It also has exactly the blind spot Chorus was built to address, because the reviewer shares a vendor with the author more often than not.
The real difference is in what you do with disagreement. A single reviewer produces one verdict, and you either accept it or you do not. Chorus produces several verdicts and treats divergence as the signal. That is a different epistemic posture: it does not try to produce a better single answer, it tries to make conflict visible. The cost is that you now have to adjudicate between reviewers, and the README's own framing of the payoff is that your job becomes the 5 percent they could not catch. That is a real workflow change, not a drop-in replacement for a linter.
If you want a deterministic, scriptable gate with a stable prompt contract and no subscription dependency, a single CLI plus your own prompt file is easier to reason about and easier to pin. Chorus trades that determinism for vendor diversity.
Maintenance, Licensing, and What to Verify First
Chorus is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. It does not impose copyleft obligations on your own code. This is not legal advice, and the practical question the licence does not answer is whether your AI provider's terms permit driving a subscription CLI programmatically for this kind of automated review. The README asserts zero out-of-pocket cost against existing quota but does not address terms of service, rate limits, or what happens when a subscription quota is exhausted mid-run.
Maintenance surface is small but not zero. You carry a global npm package, an MCP registration in each detected CLI and IDE, and a local server on port 5050. The init step touches Claude Code, Codex, Gemini CLI, Cursor, Windsurf, Kimi and OpenCode, so a machine with several of those installed accumulates several registrations to keep straight. Upgrades go through chorus update, which is a self-updating binary path, meaning you should know where it writes before you run it.
Verification before adoption: run chorus init on a throwaway repository and read back which tools it detected. Confirm the reviewers it wires up come from different vendors, since same-vendor review defeats the purpose. Then run one real diff through create_chat with the code-review template and check whether the run reaches a terminal state through wait_for_chat, because that is the path any CI integration would depend on.
Editorial conclusion
Adopt Chorus if you already hold a Claude Pro, ChatGPT Plus or Gemini Advanced subscription, work on a laptop or workstation where the code may leave the machine, and want a second vendor's eyes on AI-written diffs without opening a metered API account. Do not adopt it if your code cannot be sent to a third-party vendor at all, if you need a headless CI gate today (the codex exec MCP limitation is unresolved), or if you want a single deterministic reviewer with a stable prompt contract. Before trusting it, run chorus init on a scratch repository, confirm which CLIs it detected, and check that the reviewers it wires up are actually from different vendors, because same-vendor review is the exact failure mode the project exists to avoid.
Community notes