DEV Community: Ellery Familia

mix2: Two Coding Agents, One Answer

Ellery Familia — Wed, 26 Aug 2026 19:12:21 +0000

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.

That's basically mix2

I wanted the convenience of asking one coding agent a question, while having another capable agent independently try to prove it wrong.

Without running two conversations myself.

Without a fake "AI swarm."

Without hiding disagreements because consensus looks better in a demo.

Just:

two coding agents, independent takes, one answer.

If that sounds useful, try it:

github.com/elleryfamilia/mix2

If it earns a place in your terminal, star it.

Stop Copying Your CLAUDE.md Between Projects

Ellery Familia — Wed, 26 Aug 2026 14:35:41 +0000

I kept running into the same dumb problem with AI coding agents.

Every project needs context. How I like code structured. Which tools I prefer. How I want the agent to communicate. What commands it should run. How I want it to plan before touching anything.

So you put that stuff in CLAUDE.md. Or AGENTS.md. Or Cursor rules. Or Copilot instructions.

Then you open another repo and do it again.

Then you SSH into a server and none of it is there.

Then you switch from Claude to Codex and apparently you have a second configuration system to maintain now.

I didn't want a better CLAUDE.md.

I wanted the context to follow me.

So I built Loadout.

The basic idea

Loadout is an adaptive context engine for AI coding agents.

You create reusable loadouts for the situations you work in:

Rust
Next.js
Python
Go
Node
machine/server work
whatever else you want

Then instead of launching:

claude

you launch:

load claude

Loadout detects what you're working on, picks the right loadout, renders the context, wires it into the agent, and gets out of the way.

So in a Rust repo, maybe the agent gets:

Use cargo for builds and tests.
Run clippy before considering work complete.
Prefer Result/? over unwrap().
Keep responses terse.

In a Next.js repo, it gets something completely different.

On a bare Linux server, it can get your sysadmin conventions instead.

The selection is deterministic and inspectable. There's no LLM sitting in the middle deciding which prompt you probably meant.

load explain

might give you something like:

Detected targets: [rust]

Loadout selection → rust

Active fragments
  • rust-conventions
  • terse-comms

That's basically the whole premise:

different work needs different context. Stop handing your agent the same one every time.

Project context and your context aren't the same thing

This distinction ended up being pretty important.

Your project's AGENTS.md should describe the project.

Architecture. Build commands. Weird repository conventions. Things everyone working on that codebase needs to know.

Loadout is for what you bring to the project.

Your preferred workflow. Your coding conventions. Your tooling. How you want an agent to communicate. Things you've learned after using coding agents for six months and don't want to explain for the 400th time.

And Loadout deliberately doesn't rewrite the project's shared files.

It writes local, gitignored overlays using whatever mechanism each agent supports.

Your team's CLAUDE.md, AGENTS.md, or Copilot instructions stay alone.

Fragments are the reusable part

I didn't want loadouts to turn into giant prompt blobs either.

So they're composed from fragments.

A fragment is just a reusable unit of context:

[[fragments]]
id = "rust-conventions"
guidance = "Build with cargo, lint with clippy; prefer ?/Result over unwrap()."

[[fragments]]
id = "terse-comms"
guidance = "Be terse. Lead with the result. Skip the preamble."

Then a loadout combines them:

[[loadouts]]
name = "rust"
targets = ["rust"]
fragments = ["rust-conventions", "terse-comms"]

Fragments can also be dynamic and pull context from shell commands, so not everything has to be static text.

The nice part is that terse-comms isn't a Rust thing.

I can use the same fragment in my Rust, Next.js, Python, and server loadouts without copying it four times.

I also wanted my workflow to follow me

Context was only half the problem.

I switch between coding agents, but I don't necessarily want to switch engineering processes every time I do.

So Loadout has six common workflow stages:

/loadout:explore
/loadout:brainstorm
/loadout:plan
/loadout:implement
/loadout:verify
/loadout:ship

A workflow defines what those stages actually mean.

Loadout ships with workflows based on:

Superpowers
spec-driven development
Every's compound engineering

Or you can build your own.

That means I can use Claude today and Codex tomorrow without teaching both of them my preferred explore → plan → implement → verify loop separately.

The agent changes.

The process doesn't.

Plans shouldn't disappear into chat

This one grew out of another annoyance.

Agents are getting pretty good at writing implementation plans.

But reviewing a 100-line plan inside a terminal transcript sucks.

So Loadout can turn an agent-written plan into a self-contained HTML page:

load plan render

You get the plan broken into phases, tasks, risks, and open questions.

More importantly, you can comment directly on individual elements.

So instead of telling an agent:

"The third thing you mentioned under the authentication section — not the first bullet, the other one — change that..."

you leave the comment on the actual task.

Loadout then assembles the feedback so you can hand it back to the agent.

It's still the agent doing the planning. Loadout just gives you a better review surface.

It isn't tied to Claude

This was another requirement from the beginning.

Right now Loadout works with:

Claude
Codex
Cursor
opencode
GitHub Copilot

Both CLI agents and VS Code-based workflows are supported.

Each agent expects context in a different place, so Loadout handles the ugly part of delivering the same generated overlay the way that particular agent expects it.

I don't want my personal AI workflow coupled to whichever coding agent happens to be best this month.

There's a UI if you don't want to live in TOML

I like config files.

I also don't particularly want to manually edit them every time I remember some tiny preference.

Run:

load studio

and Loadout opens a localhost web UI where you can create fragments, compose loadouts, assign targets, choose workflows, preview the generated context, and review the diff before writing anything.

There are starter packs too, so you don't have to build everything from an empty config on day one.

If you already have a giant CLAUDE.md or AGENTS.md, there's a migration skill for that:

load skill install

Then tell your agent:

"Import my CLAUDE.md into Loadout."

It turns the existing instructions into reusable fragments instead of making you manually pull the thing apart.

And it syncs

Your loadouts are global rather than living inside individual projects, so Loadout can sync the configuration through git:

load sync init git@github.com:you/loadout-config.git

Then on another machine:

load sync clone https://github.com/you/loadout-config.git

Now the same context can follow you from your laptop to another workstation or server.

Machine-specific/private values stay local.

Try it

Install the binary directly — no Rust toolchain, no Node required:

curl -LsSf https://github.com/elleryfamilia/loadout/releases/latest/download/loadout-installer.sh | sh

Then:

load studio
load claude

That's it.

Loadout is open source and MIT licensed:

github.com/elleryfamilia/loadout

If you're currently maintaining some combination of CLAUDE.md, AGENTS.md, Cursor rules, random prompt snippets, and things you keep telling agents to "remember from now on," this is pretty much the problem I built it to solve.

Give it a try. And if it earns a permanent spot in front of your coding agent, give the repo a star.