Conducting Three Coding Agents at Once: Claude driving codex, kimi, and aider (Coding Agents, Part 2)

Last time I raced four coding-agent CLIs head to head: same tasks, hidden tests, who scores best per dollar. Racing is the obvious first question. This is the obvious second one: stop racing them and conduct them. Put one model in charge and have it drive the others at the same time.

The reason I cared traces back to the Fable Destroyer post, which ended on a finding I keep chewing on: on the same weights and the same tasks, the harness moved scores more than the model did, and multi-model "mixes" mostly earned their keep rescuing weak models, not raising the ceiling. The scaffold mattered more than the brain. So if wiring several models over one workspace is a thing, what about wiring several whole agents, each with its own tools and opinions?

I needed a concrete excuse, so I gave myself one: lemon-squeezer needed a new "orchestration" tab, and I decided not to build it myself. I'd make one Claude be the conductor and have it drive three other coding agents in parallel to build it.

The bet: tight contracts beat smart agents

The claim I wanted to test: one model can decompose a feature, hand disjoint pieces to heterogeneous agents running concurrently, and integrate the results into something that compiles, and the thing that decides whether it works is the contract, not which agent is smartest.

The one design decision the whole thing rests on: every agent gets exactly one file and an exact interface, and they never touch each other's files. No shared state, no "agents collaborating," no chat between them. The conductor owns the page and the integration; the workers own a single artifact each, specified down to the TypeScript prop types.

That is the same shape as a mix from Part 1, one level up. A mix has a planner, an implementer, a judge. This has a conductor and three implementers who happen to be entire CLIs.

Who did what

The work split into four parcels, three of them shipped out to parallel agents:

• codex (OpenAI's CLI, high reasoning, on the ChatGPT sub) got the hard, graphical piece: an animated SVG flow-diagram React component that draws each orchestration pattern as nodes and flowing edges. I handed it the exact Pattern prop type and told it to create one file and touch nothing else. It returned 278 lines.
• kimi (moonshotai/kimi-k2.7-code on OpenRouter, driven by lemon-squeezer's own 250-line squeezer agent) got the easy, structured piece: generate the orchestration-patterns data as JSON. It produced valid JSON, four patterns, on the first try. Cost: $0.011 (23k tokens in, 2.7k out).
• aider (driven against deepseek-v4-flash on OpenRouter) got a self-contained component: the "conductor panel" that shows who built what. Cost: $0.00021.
• Claude (the conductor) wrote the page itself, computed the real mix results from runs.jsonl, wired the three pieces together, and fixed what didn't fit.

I launched all three workers as background jobs and went to write the page while they ran.

Aside: I wanted the fourth agent to be the cursor CLI, but the headless cursor-agent binary was not installed on this box, only the editor launcher. So the "cursor" leg became aider. A plan meeting reality, on schedule.

The results, with the costs attached

The whole feature cost about 1.1 cents of API spend. Kimi's JSON at $0.011 and aider's component at $0.0002 were the only metered calls; codex ran on the ChatGPT subscription. Three agents, one deployed tab, the price of not quite a gumball.

The integration compiled on the first try. This is the part I did not expect to be able to write. next build passed with no type errors the first time I assembled the page, because codex's exported Pattern type matched the type my page imported, because I had written that interface into codex's prompt verbatim. The contract did the work. When the seam is specified, the parts meet at the seam.

Wall-clock was the slowest agent, not the sum. kimi and aider both finished while codex was still reasoning about its SVG layout. Running them in series would have been roughly additive; running them in parallel made the wall-clock the cost of the single slowest worker. That is the entire reason to conduct instead of doing it yourself one agent at a time.

The only rework was a contrast bug. aider put light, muted text on bright accent-colored cards, which is unreadable. The fix was two lines: dark text on the bright fills. That was the whole integration tax. I expected to be untangling incompatible component APIs for an hour; instead I changed a color.

The tab is live: the orchestration page renders codex's flow diagrams, the real "do mixes beat the best single model?" verdict from the benchmark data (mostly no), and aider's conductor panel naming exactly which agent built which part of the page it sits on.

What this is, and what it isn't

This is not agents collaborating. Nothing on the worker side knew the other workers existed. There was no negotiation, no shared scratchpad, no emergent teamwork. It is one model doing the genuinely hard parts of engineering management: cutting the work along clean lines, writing interfaces precise enough that independent implementations meet, and owning the integration. The workers are interchangeable; the decomposition is not.

It also is not a benchmark. I ran it once, to build one real thing. The dollar figures are real and the build-passed-first-try is real, but n is 1. Treat it as an existence proof, not a measurement.

The wrong prior

I expected the frontier agent to carry the project and the cheap ones to need babysitting. I had codex mentally penciled in as the one that mattered and kimi and aider as risks.

That is not what happened. The cheap legs did their scoped jobs cleanly: kimi's JSON was valid first try, aider's component worked after a color fix. What actually determined whether a piece slotted in was whether I had written a tight enough contract for it, not how strong the model behind it was. The one wobble (aider's contrast) was a spec gap, my fault, not a capability gap.

Which is Part 1's finding wearing a bigger coat. There, the harness mattered more than the model. Here, the conductor's contracts mattered more than the agent. The intelligence that counts is increasingly in the wiring, not the node.

Take what's useful

The reusable pattern, if you want to try it: decompose into single-file parcels, write the interface between them before you start (literally paste the type signatures into each agent's prompt), give each agent exactly one file and forbid the rest, run them in parallel, and keep the integration for yourself. Heterogeneous agents are fine. Cheap agents are fine. Unspecified seams are not.

The benchmark, the orchestration tab, and the runner that drives any of these models are all in lemon-squeezer. Part 3 is probably the same idea aimed at something that does not compile on the first try. 🍋