Your Coding Agents Should Come From Different Labs

Different labs, different brains

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. That is the bet this post is about: mixing 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.

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. The two shapes are my own scoring of the models I use every day, and the honest part is how little they differ. Small edges, in different places.

You can watch it play out in public: Tech Twitter argues endlessly about whether Claude or Codex is better at frontend, and nobody is citing benchmarks. They are reacting to taste, and the same divergence runs through module structure, naming, error handling, tests. Frontend is just where it is 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, because each lab has its own corpus and pipelines and choices. The post-training differs even more: months of work 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 is a name for why this helps: cognitive diversity. Teams of different thinkers beat teams of similar experts, because their blind spots don’t overlap. Ensembles in machine learning win the same way: the gain comes from the models being uncorrelated, not from them being individually great.

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.

Expensive judgment, cheap muscle

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 an ordinary task runs the way the two terminals do. I type what I want into Fable. It decides the work is bounded, writes a self-contained prompt, and hands it to a model from another lab with write access to the working tree. That model burns the tokens. Then Fable reads the diff that comes back and decides whether the patch survives.

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.

That is the shape: 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. Everything after this is the config that makes the handoff free, and all of it lives in one folder.

A rubric every session reads

So I split the work the way you’d staff a team. In my global CLAUDE.md there is a small table that every session reads, ranking the models I use on the three axes I actually care about.

A snapshot, not scripture. I have 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.

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.

The workhorse

The rubric decides where work goes. Three skills are how it gets there, and they sit in the same folder as the rubric. I wrote about that machinery in the configuration system post; this is the same machinery pointed at a new problem.

None of it is secret sauce, so all three files are here verbatim, exactly as my agent loads them. Copy each into its own folder under ~/.claude/skills/ as a SKILL.md and Claude Code picks them up automatically.

codex-implementation is 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. That asymmetry is the whole safety story. The cheap model can be wrong as often as it likes, because nothing it writes reaches main without the expensive one reading it first.

No model grades its own homework

codex-review is 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.

Most of the file is about stance rather than commands. It tells Claude to treat the reviewer’s output as evidence and not authority, to check each finding against the code before repeating it, and to separate confirmed issues from suggestions it did not verify. A review you forward unread is not a second opinion. It is your judgment, outsourced.

The third skill got its own post

codex-computer-useis the same idea with hands. When “does it work” means clicking through a flow, launching a simulator, or taking screenshots, it hands the job to a model that drives the machine and reports back with evidence, so nobody has to sit there clicking. Its SKILL.md is still in the tree on the right if you want to peek at it. But that one turned out to be the skill I recommend first and the one people ask about most, so it has its own writeup: stop being the one who clicks around.

The three files 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.

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 those 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.