MCO: a CLI layer that runs your coding agents side by side and keeps their answers raw

The problem MCO addresses: one agent, one blind spot

A single coding agent gives you a single reading of a repository. If that agent misses a race condition in a background worker, nothing in the output tells you the miss happened. The usual workaround is manual: open a second terminal, paste the same prompt into a different CLI, and hold both answers in your head. MCO turns that manual step into a command. You name the agents, it dispatches the same task to all of them, and it retains each invocation's complete raw answer alongside its operational status. The target user is an engineer who already pays for or has access to more than one coding agent CLI and wants a second and third opinion without leaving the terminal. The README also positions MCO as callable from inside another agent, listing Claude Code, Codex, Cursor, Copilot, Pi and OpenClaw as callers, so a single orchestration command can sit one level below your existing assistant.

What MCO refuses to compute, and why that shapes the tool

The README is explicit that MCO keeps answer text opaque. It does not convert natural-language output into findings, severity levels, confidence scores, consensus, or an automatic decision. That is a deliberate boundary, not an unfinished feature. Most multi-model tooling tries to compress several answers into one verdict, and the compression step is where the interesting disagreement disappears. MCO instead preserves the disagreement and leaves the judgement to you. The consequence is that you get no ranking and no summary. If three agents return three different diagnoses of the same bug, MCO will hand you three blocks of text and the status of each run. The comparison is your job. For a reviewer who wants to see where models diverge, that is the point. For someone who wants a single answer with a confidence score attached, MCO is the wrong layer.

How dispatch actually works across ten provider CLIs

MCO is a Python 3.10+ package distributed through npm as @tt-a1i/mco, and the built-in provider table maps a provider ID to a binary that must already exist on your machine: claude, codex, gemini, opencode, qwen, copilot, hermes, pi, grok, and cursor (also reachable as agent). MCO does not install or authenticate any of them. The README states that each provider CLI remains responsible for its own installation, authentication, model access, and native sandbox behaviour. So MCO is an adapter and a dispatcher, not a runtime. It translates one execution profile into each provider's native flags, launches the selected agents, and collects their answers. Two coordination modes go beyond plain parallelism. The --chain flag runs agents in sequence, and with --result-mode artifact the earlier result is written to a file that the next agent can consume. The --debate and --synthesize flags on mco review add a debate round and a synthesis pass, with --result-mode both keeping raw and synthesized output. For scope splitting, --divide files excludes ignored, local and build directories and round-robins the remaining sorted repository files without overlap, while --divide dimensions rotates review lenses in declaration order without changing target paths. The README notes both choices are visible in dry-run.

Getting it running: install, doctor, review, run

The install path is a single command: npx @tt-a1i/mco@latest install, which installs the CLI and its bundled mco-cli Skill. Before dispatching anything, mco doctor --json reports which agents are available on the machine. A read-only review looks like this: mco review --repo . --prompt "Review this repository for high-risk bugs." --providers claude,codex,pi. A task with workspace write access uses a different subcommand and an explicit mode: mco run --repo . --prompt "Implement the requested change and run the relevant tests." --providers codex,pi --execution-mode write. Team selection is deliberately non-magical. MCO never infers a provider or model team from detected binaries. If neither --providers nor --agent is given, a top-level providers config entry supplies the saved default; with no config entry, the team must be named explicitly. To pin a model for one run without touching provider CLI defaults, pass --provider-models-json, for example '{"codex":"gpt-5.4","pi":{"provider":"seal","model":"deepseek-v4-pro"}}'. Named agents let you compare two models from the same provider: mco run --agent fast=pi:model-a --agent careful=pi:model-b --prompt "...". For inspection before spending tokens, mco review --providers claude,pi --dry-run --json prints the resolved plan. Streaming is available through --stream live for terminal progress and --stream jsonl for machine-readable events, and mco agent models --providers codex,pi --json lists the models each provider exposes.

The permission model is translation, not containment

MCO defines three execution profiles. read_only is the default for mco review and is meant for inspection without workspace mutation. write is the default for mco run and permits creating and editing workspace files. yolo maps to the provider's broadest bypass profile and requires explicit opt-in. The README is unusually direct about the limits of these labels. --allow-paths validates the scope MCO requests; it is not an operating-system sandbox. How strong the sandbox actually is depends on the underlying CLI, which means the effective isolation of a yolo run is the isolation of whichever provider you pointed at. Hermes is called out specifically: its oneshot mode bypasses approvals, so MCO requires explicit --execution-mode yolo to use it. ACP terminal access is described as a trusted-agent capability, with isolation recommended for untrusted agents or prompts. The sharpest constraint is about parallel writers. MCO does not create or manage worktrees. If you select several agents in write mode, you must partition ownership with non-overlapping --target-paths yourself, and the README says to warn about edit conflicts. Two agents editing the same file in the same checkout will collide, and MCO provides no merge step.

Where the raw-answer design becomes a cost

The same opacity that makes MCO useful for comparison makes it unusable as a gate. There is no exit code derived from answer content, no severity threshold, no consensus count, so you cannot wire mco review into a CI pipeline and fail the build on a high-risk finding without writing your own parser over the raw text. The README lists CI checks among the intended workflows, which is fair for surfacing multiple perspectives in a log, but the decision logic stays outside the tool. A second limitation is operational surface area. MCO depends on ten external CLIs, each with its own authentication, rate limits, model catalogue and failure modes. A run against three providers can partially fail, and the material indicates that per-invocation operational status is retained, so you can see which one failed, but you still own the retry policy. Third, the debate and synthesis modes add cost on top of the parallel runs, since synthesis is an additional model pass. Fourth, --provider-models-json pins model names that the provider CLIs must still recognise; MCO validates its own plan, not the upstream model list. If you want one hosted surface with persistent agent identity and a shared task graph, the README points elsewhere rather than pretending MCO covers it.

How MCO differs from a general-purpose agent runner

The closest comparison is to a shell script or a task runner such as GNU parallel or a Makefile target that fans out prompts to several CLIs. Those tools can launch processes in parallel, but they treat each CLI as an opaque command and leave you to normalise the output yourself. MCO's difference is the provider layer: it knows the ten CLIs by name, knows which flags correspond to read_only, write and yolo for each, and exposes a single --providers list plus per-provider model pinning through --provider-models-json. That mapping is the actual work. It is also the maintenance burden. A generic runner does not break when Codex changes a flag; MCO's translation table does, which is why the release cadence matters. A second comparison is to the provider CLIs' own multi-model features, where available. Those keep you inside one vendor's ecosystem and one billing relationship. MCO's value proposition is cross-vendor: Claude, Codex, Gemini, Pi and the rest in one invocation, with the team chosen by you rather than inferred from what happens to be installed.

Maintenance, versioning and the MIT licence

MCO is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement with no copyleft obligation, but it says nothing about the licences or terms of the ten provider CLIs MCO drives; those are separate agreements you already accepted when you installed each one, and MCO does not intermediate them. The repository is not archived and the most recent release listed is v0.11.0 from 2026-07-29, following v0.10.8 and v0.10.3, with a last push of 2026-08-14. The 0.x version line and the frequency of patch releases are the practical signal here: the provider translation layer is the part most likely to need updating when an upstream CLI changes its flags, so pinning a known-good MCO version in a CI image is more defensible than tracking latest on every build. The README also states that MCO is actively maintained and directs readers to a separate project for a browser workbench, which suggests the CLI is the intended centre of gravity rather than a stepping stone to a hosted product.

Editorial conclusion

Adopt MCO if you already have several provider CLIs installed and authenticated and you want their raw answers side by side on one prompt, with the team chosen explicitly rather than inferred. Do not adopt it if you want a single merged verdict, a hosted workbench, or an OS-level sandbox: MCO keeps answers opaque by design, does not create worktrees, and its --allow-paths check is a scope validator rather than isolation. Before you trust it on a real repository, run mco doctor --json to confirm which provider binaries it can see, then run mco review with --dry-run --json to read the resolved provider/model team and the translated permission profile, and only after that decide whether the write mode is appropriate for the agents you selected.

Official sources

1. Issues
2. License: MIT
3. mco-org/mco on GitHub
4. README
5. Releases