2026-07-10 · Positioning · 9 min read

ATO vs Claude Code + Codex MCP: peers, not a second brain under one host

Short answer: Claude Code + Codex MCP is a strong pattern when Claude is the permanent host and you want a second brain on demand. ATO is a different architecture. It treats Claude, Codex, Gemini, and others as peers under a local cockpit, shells out to their CLIs (or provider APIs), and uses MCP so coding agents can drive ATO — not so ATO can call Codex as Claude's tool. Use both if you want; they stack.

The pattern people already have

Roughly:


You → Claude Code (host, owns the session)

         └─ tool call → Codex MCP

                └─ Codex answers Claude

That is real multi-model work. OpenAI even ships a Codex plugin for Claude Code for review and handoff. For "Claude, ask Codex about this diff," it is often enough.

What it structurally is:

Claude is the boss. Codex is usually a tool Claude chooses to call. Claude frames the question, filters context, and often writes the final synthesis.
One host session. History, permissions, and "done" live in Claude Code.
Weak cross-runtime ledger. Cost, tool calls, who said ship vs blocking, files each model touched: scattered across transcripts, not one queryable SQLite row per peer.
Host lock-in. The glue is Claude-Code-shaped. Other primary harnesses need rewiring.

What ATO does instead


You or any agent → ATO (session + receipts + CLI/MCP API)

                      ├─ Claude CLI   (peer)

                      ├─ Codex CLI    (peer)

                      ├─ Gemini CLI / API (peer)

                      └─ Hermes / OpenClaw / API providers …

How ATO actually triggers models (CLI vs MCP)

This is the part that confuses people, including us the first time we explained it.

Path	What ATO does	When
Runtime CLI (primary for Claude / Codex / Gemini CLI)	Spawns the vendor binary as a subprocess: e.g. `claude --print`, Codex CLI exec, `gemini -p`. Auth is your CLI subscription or the CLI's own login.	Default for installed coding CLIs
Provider HTTP API	Calls Anthropic / OpenAI / Google / etc. with keys you stored in ATO. ATO can run its own tool loop (`read_file`, `grep`, `git_log`) when grounding is on.	CLI missing, or you chose API / BYOK mode
ATO MCP server	Exposes ATO to Claude Code, Cursor, Codex, etc. so those agents can drive ATO (list dispatches, run agents, check runtimes).	Harness integration

Important inversion:

Claude Code + Codex MCP: MCP is how the host agent reaches Codex.
ATO: MCP is how any agent reaches ATO. ATO reaches Claude/Codex mostly by CLI subprocess, not by speaking Codex-MCP as a client of Claude.

So ATO is not "another MCP wrapper around Codex inside Claude." It is a multi-runtime dispatcher + ledger that can also be an MCP server.

Auth and billing (why CLI path matters)

CLI path: uses the same subscriptions you already pay for (Claude Max, ChatGPT/Codex CLI, Gemini CLI). Receipts often store cost as null or API-equivalent estimates when the vendor does not bill per token on that channel.
API path: metered keys, clearer dollar receipts, ATO-owned tool loop for providers that would otherwise be one-shot text.
You can set per-runtime preference (subscription vs api) so the cockpit does not silently steal the wrong bill.

Side-by-side

Need	Claude Code + Codex MCP	ATO
"Claude, ask Codex once"	Wins (simpler)	Overkill
Independent multi-reviewer pass (peers, not only Claude's framing)	Weak / prompt-dependent	Strong (`ato review --consensus`, war rooms)
Later reviewer sees earlier findings as product behavior	Manual	Built-in
One local ledger: cost, tokens, tools, files per model	Fragmented	`~/.ato/local.db`
Replay same prompt on another model later	DIY	First-class
Regression after model/prompt swap	DIY	Config ledger story
Same workflow if the host is not Claude Code	Rewire	CLI / GUI / MCP driver-agnostic
Human + coding agent share the same audit trail	Claude-centric	Shared cockpit
Gemini / Hermes / OpenClaw in the same room	More glue	Native multi-runtime

Concrete receipt (why peer review matters)

On a real auth-middleware PR we ran three reviewers in one ATO session:

Claude: LGTM, ship it
Codex: BLOCKING — session invalidation became fire-and-forget
Gemini: endorsed Codex and found the same pattern on password-reset

Cheapest model caught the expensive bug. Without a peer session + ledger, you often only keep Claude's summary of what Codex said. Write-up: Same prompt, three AIs, real receipts.

When to use which

You…	Prefer
Live in Claude Code; want Codex sometimes	Claude Code + Codex MCP
Want multi-model review with receipts, replay, or non-CC agents in the loop	ATO (often still authoring in Claude Code)
Serious multi-runtime team / agent-driven ops	ATO as layer; keep CC/Codex as runtimes ATO shells out to

They compose:


Author in Claude Code

    → hard review / war room / methodology in ATO

        → ATO spawns claude CLI + codex CLI (+ …) as peers

        → receipts in ~/.ato/local.db

    → optional: Claude Code talks to ATO via ATO's MCP for ops

One-liner

Claude Code + Codex MCP = one agent with a second brain.

ATO = a cockpit where several brains are peers, triggered mainly as CLIs (or APIs), with a local audit trail — and MCP is how agents drive the cockpit, not how the cockpit pretends to be Claude's tool router.