Your Coding Agents Should Come From Different Labs
My daily driver is Fable 5. It is the smartest model I have ever used, and the most expensive. And yet, on a normal working day, most of the tokens I burn don’t go through it. They go through OpenAI models running in a separate CLI, doing the heavy lifting while Fable supervises.
That started as a cost optimization. Then I noticed the work was coming out better. A different model catches things my daily driver walks right past, and it makes different mistakes, which are far easier to spot than the same mistakes twice.
This post is about the bet behind my whole setup: mixing models from different labs beats going all-in on one, even if that one is the best. First the reasoning, then the actual config, because the philosophy is worthless if switching models costs you any friction.
Here’s the whole setup in one picture:
The idea that model diversity itself is the point came from Atin Woodard, who I trade agent-setup notes with. Atin also builds c11, a terminal multiplexer made for running a room full of agents in parallel. I use it every day and it gets its own writeup soon. The shape of my setup, one orchestrator delegating through thin wrappers, borrows from how Theo Browne runs his. What follows is my version of their ideas.
Different brains
Model capability isn’t a single number. A model that crushes competitive programming can fumble a CSS layout. Researchers call this the jagged frontier: the boundary of what a model can do is not a smooth circle but a coastline, full of peaks and inlets that don’t follow intuition.“Jagged frontier” comes from Dell’Acqua et al. (2023), the Harvard/BCG study of consultants using GPT-4. Tasks just inside the frontier saw huge gains; tasks just outside it saw workers do worse than without AI.
You can watch the jaggedness play out in public. Tech Twitter argues endlessly about whether Claude or Codex is better at frontend, with competent builders on both sides staring at real output. They’re not arguing about benchmarks; they’re reacting to taste. And frontend isn’t special. The same divergence sits in every layer of your codebase, in module structure, naming, error handling, tests. Frontend is just where it’s visible enough to fight about.
The important part: every model’s frontier is jagged in a different place, and not by accident. The training data differs: each lab has its own corpus, pipelines, and choices. The post-training differs even more: months of RLHF where thousands of small human judgments about “good behavior” get beaten into the weights. Anthropic’s judgments are not OpenAI’s judgments. The models don’t just know different things. They have different instincts.
That’s why cross-lab is the strongest version of the idea. Same-lab models are siblings. Different-lab models share almost nothing. What you want is model diversity; lab boundaries are just where the diversity is deepest.
What team science already knew
There’s a name for why this helps: cognitive diversity. Teams of different thinkers beat teams of similar experts, because their blind spots don’t overlap.Hong & Page (PNAS, 2004) is the classic formal result: groups of diverse problem solvers can outperform groups of high-ability problem solvers. Scott Page’s The Difference (2007) is the book-length treatment. Ensembles in machine learning win the same way: the gain comes from the models being uncorrelated, not from them being individually great.Dietterich (2000) for the survey; Krogh & Vedelsby (1995) for the error decomposition showing ensemble gain scales with member disagreement. This is now being tested on LLMs directly: Mixture-of-Agents (2024) and LLM-Blender (2023) both got gains specifically from mixing model families.
Two Claude instances reviewing each other share instincts and blind spots. A GPT model reviewing Claude’s work brings an actually independent perspective. When they agree, the consensus means something. When they disagree, I’ve learned where to look.
That’s the theory. For my own workflows it’s still a hypothesis: no controlled eval, just many hours of driving it, a pile of bugs one model missed and the other caught, and enough conviction to build my whole setup around it.
The economics make it free to find out
Here’s what makes this an easy bet: the setup pays for itself even if the diversity thesis turns out to be worth nothing.
Fable is spectacular and priced accordingly. Running it on bulk implementation work, the kind where the spec is clear and the model mostly needs to grind through files, is like hiring a principal engineer to rename variables. The work gets done. It’s just a waste of the thing you’re paying for, which is judgment.
So I split the work the way you’d staff a team. In my global CLAUDE.md there’s a small table that every session sees, ranking the models I use on the three axes I actually care about:“codex” here means OpenAI models driven through the Codex CLI. The exact model comes from a config file, so when OpenAI ships something new I update one line, not every skill that mentions codex.
A snapshot, not scripture. I’ve already updated my real table since I first wrote it, because the labs keep shipping, and by the time you read this it will be stale again. That’s fine. The numbers rot; the structure doesn’t. There is always a spread between what models cost and what they’re good at, and the spread is the opportunity.Don’t copy my axes, either. Cost, intelligence, and taste are the dimensions I have strong opinions about. Maybe yours are speed, context length, or instruction-following. The rubric only works if the scores come from your own experience, because the orchestrator will route work based on them.
The rules underneath the table matter more than the numbers. Bulk and mechanical work goes to the cheapest capable model. Anything user-facing needs a taste score of 7 or higher. Reviews always go to a different model than the one that wrote the code. And the defaults are not limits: the orchestrator has standing permission to escalate to a smarter model when the cheap output doesn’t meet the bar, without asking me. Judge the output, not the price tag.
That last rule does a lot of work. It means I never have to choose between saving money and shipping quality. The cheap model gets the first attempt. If it’s good, I saved tokens on my expensive model’s budget. If it’s not, Fable redoes it and I’ve lost almost nothing, because the first attempt was nearly free.
If you run on consumer plans rather than API credits, codex is very attractive right now: the plans are cheaper than Anthropic’s, and OpenAI has been generous with usage resets on top. For my personal projects I run three Claude Max subscriptions and max them all out, every cycle. My single, cheaper Codex plan I almost never exhaust, thanks to those resets. That will surely change. But today, the heavy-lifting tier of my setup is close to free.
The result is a shape I’d describe as: expensive judgment, cheap muscle. Fable scopes the task, delegates, inspects what comes back, and takes the final review. The other models burn the tokens in the middle. That is the loop from the top of the post.
The setup: three skills and a rubric
None of this works if delegation has friction. If handing a task to another model means opening a second terminal, writing a fresh prompt, and copy-pasting results back, you’ll stop doing it within a week. The entire trick is making the handoff cost nothing. In my setup, delegation is something Fable does mid-conversation without me thinking about it.
I wrote about the mechanics of Claude Code customization in the configuration system post; this is that machinery pointed at a new problem. The multi-lab setup is three global skills plus the rubric above.
codex-implementation. The workhorse. When a task is bounded and the spec is clear, Claude writes a self-contained prompt, pins the repo state with git status, and runs the Codex CLI with write access to the working tree. Codex implements, writes a report, and exits. Then the important part: Claude diffs the result against the pinned baseline, inspects every change, and runs verification itself. Codex is not allowed to commit, push, or touch config. It produces a patch; my daily driver decides whether the patch survives.
codex-review. The independent second opinion. Claude finishes a piece of work, then hands the diff to a model from a different lab with fresh eyes and no memory of writing it. This is where the diversity thesis earns its keep most visibly: the review comes from a model that does not share the author’s instincts. Author bias is real for models just like it is for people. You don’t grade your own homework, and in my setup, no model grades its own homework either.
codex-computer-use. Verification with hands. When “does it work” means clicking through a flow, launching a simulator, or taking screenshots, this skill hands the job to a model that drives the machine and reports back with evidence. My orchestrator stays focused on the code while another brain confirms the behavior. And I’ll say this one plainly: right now, Codex is simply better at computer use than Anthropic’s models. Not marginally, not arguably. It navigates apps, recovers from weird UI states, and verifies flows with a reliability Claude doesn’t match today. If you’re a Claude user and you steal exactly one thing from this post, steal this skill.
The skills encode the workflow so I don’t have to. Each one tells Claude how to scope the prompt, which sandbox level to use, where the report lands, and what to verify when the run comes back. From my side, the entire experience is typing what I want. The routing happens underneath.
And because none of this is secret sauce, here are all three, verbatim. Copy each into its own folder under ~/.claude/skills/ as a SKILL.md and Claude Code picks them up automatically.They assume the Codex CLI is installed and logged in, with models pinned in ~/.codex/config.toml. Mine right now: model = "gpt-5.6-terra", review_model = "gpt-5.6-sol". When OpenAI ships something new, ask your agent to update the config. That is the whole migration.
One practical note. The model picker in these tools only accepts models from its own lab, for obvious reasons. So inside larger workflows, cross-lab delegation runs through a thin wrapper: a minimal Claude agent whose only job is to write the Codex prompt, run the CLI, and return the report. I label these agents with a codex: prefix so the workflow view tells me which brain actually did the work. Small thing, but when six agents are running in parallel you want the org chart to be honest.
Is this provably better than a monoculture? I said it upfront: it’s a bet. But again and again the cross-lab review catches something the author model was structurally unable to see, because seeing it would have required not being the model that wrote it.
Different brains, cheap handoffs, no model grading its own homework. That’s the setup. The configuration system makes it nearly free to try, and my honest expectation is that once you’ve watched a rival model catch your favorite model’s bug, you won’t go back to a monoculture either.
Dell’Acqua et al., Navigating the Jagged Technological Frontier (2023). The jagged frontier framing.
Hong & Page, Groups of diverse problem solvers can outperform groups of high-ability problem solvers (PNAS, 2004). The cognitive diversity result.
Wang et al., Mixture-of-Agents Enhances Large Language Model Capabilities (2024), and Jiang et al., LLM-Blender (2023). Model diversity tested directly on LLMs.
My earlier post on the Claude Code configuration system, which covers the skills and CLAUDE.md machinery this setup is built on.
If you found this helpful, share it: