mix2: Two Coding Agents, One Answer

I've gotten into the habit of asking two coding agents the same question.

Not because burning twice the tokens makes an answer twice as good. Because Claude and Codex will often look at the same codebase, understand the same constraints, and come back with meaningfully different opinions.

That's useful.

What's less useful is having two terminals open, copying context back and forth, asking one what it thinks about the other's answer, and then acting as the human merge conflict resolver.

So I built mix2.

Two coding agents. Independent takes. One answer.

Before mix2, I'd do this manually — ask Claude Code to run codex exec, or have Codex shell out to claude -p, and then bring the second opinion back into the conversation. It works. It's just clunky, and it's easy to accidentally anchor the second agent with the first one's framing.

mix2 still uses those CLI calls underneath. It just puts a structured collaboration protocol around them: independent briefs, scoped consultations, depth budgets, reconciliation, and a disagreement ledger.

mix2 is a terminal app that turns two coding agents into one small engineering team. You ask one question; both investigate in parallel, independently; they compare notes, argue when they should, and hand you a single answer — signed by the team, not by either of them.

Try it

curl -fsSL https://raw.githubusercontent.com/elleryfamilia/mix2/main/install.sh | sh

Then:

mix2

The team is a pair — you pick the two agents at startup. /team changes the team. /model changes the models. You can pin both in config if you want. I usually run Claude Code + Codex, but the lineup is up to you.

What I actually use it for

mix2 isn't really about getting two agents to type code twice as fast.

I don't use it for code reviews. I use it for questions — the kind where you want a second opinion from someone who thinks differently than you do:

architecture and design
tradeoffs
brainstorming
debugging discussions
"is this idea actually any good?"
"what am I missing?"

That's where having two independent opinions gets interesting.

Run it outside a code project and the team notices, drops the code lens, and brainstorms whatever you bring — a product idea, business viability, strategy, a document.

If you ask mix2 to implement something, it deliberately doesn't modify your code. The consulted agent is read-only — it's there to investigate and argue, not start "helpfully" changing the repo.

Instead, both agents investigate, work through the approach, and produce a complete implementation plan:

.mix2/<topic>-plan.md

Then mix2 gives you the exact claude or codex command to execute that plan interactively.

So the workflow becomes:

two agents investigate
        ↓
they reconcile the approach
        ↓
you execute the plan interactively

You leave with a plan two independent agents signed off on, which is more than most human meetings produce.

The important part is independence

There are already plenty of ways to spawn multiple agents.

That wasn't really the problem I wanted to solve.

The thing I care about is getting a genuinely independent second opinion.

If one agent investigates something, forms a conclusion, and then asks a second agent:

Here's what I think. Can you take a look?

...that's not independent anymore.

The second agent has already been anchored.

mix2 instead gives the consulted agent a clean, unanchored brief. It investigates the problem and forms its own view before the two answers are reconciled.

Consultations are stateless between turns too — the second agent isn't quietly accumulating the coordinator's framing over time.

That distinction matters.

When both agents independently land on the same conclusion, I have more confidence in it.

When they don't, that's often even more useful.

And mix2 doesn't turn:

Claude thinks A. Codex thinks B.

into:

We recommend A.

just because a tidy answer looks nicer.

The disagreement stays in the answer.

One harness agreeing with itself isn't a second opinion.

It's one conversation, not two chat windows

I also didn't want this to feel like:

┌ Claude ────────┐  ┌ Codex ─────────┐
│ blah blah blah │  │ blah blah blah │
└────────────────┘  └────────────────┘

with me sitting in the middle figuring out what to believe.

There's one conversation. One team. One answer.

While they're working, mix2 narrates what's happening:

Codex is reading the implementation.
Claude is checking how the session lifecycle works.

Those messages come from the harness, not from one model pretending it knows what the other model is doing.

You can hit Ctrl+T if you want to inspect the actual activity and consultation.

Otherwise you can mostly ignore it.

I had to put some actual rules around the collaboration

Telling an agent:

Please don't consult your teammate more than twice.

is not a control mechanism.

So the collaboration rules live in the runtime.

By default, there's a maximum of two consultations per turn, enforced atomically by the Rust core. Recursive consultation is rejected in code.

Consultations also get an explicit depth budget. The default is basically:

Quick take — 2 minutes, a handful of file reads.

That made a surprisingly large difference. On the same test question, consultation time dropped from 349 seconds to 101 seconds.

Every extra agent is your money.

Claude + Codex is just what I run

Two agents is the team — that's the limit, not a default you can expand.

mix2 currently supports:

Claude Code
Codex
Cursor
OpenCode
GitHub Copilot CLI

So you can run Claude + Codex, Claude + Cursor, Codex + Copilot, or even Claude + Claude / Codex + Codex if what you want is two independent sessions of the same harness. Different labs are the interesting default, not a hard requirement.

The collaboration protocol stays the same. So does the disagreement ledger.

And there is deliberately no solo mode. If you want one agent, run its CLI. That's already a solved problem.

Under the hood

Ink UI (TypeScript + React)
          ↕ JSONL
        Rust core
          ↓
      agent CLIs

Ink renders the UI. Rust owns process management, sessions, consultation limits, cancellation, and provider adapters — the things I didn't want enforced by prompt instructions.

The result is that Claude Code, Codex, Cursor, OpenCode, and Copilot can all sit behind the same collaboration model without the UI needing to care much about what weird thing each CLI does internally.