Lessons from scaling teams of coding agents: reach the frontier at 30% of the cost

In the past year, teams of coding agents have moved from interesting demos to building large-scale software projects. Sixteen Claude agents wrote a 100,000-line C compiler that can build the Linux kernel, in a project that took about 2,000 agent sessions and $20,000 in API costs [ 1 ]. Cursor ran hundreds of agents that together wrote a web browser from scratch, more than a million lines of code, in about a week [ 2 ]. Bun was ported from Zig to Rust in 11 days, with 64 Claude agents running in parallel at its peak [ 3 ].

Each of these teams produced working software, but they differ from one another in many ways at once, from the models and roles to the scope of the projects themselves. The C compiler's agents worked as peers with no orchestrator and claimed tasks through lock files. Cursor used a hierarchical structure, with planners recursively decomposing work into subtasks delegated to hundreds of worker agents. Bun assigned fixed roles, giving each piece of work to one implementer, two adversarial reviewers, and one fixer.

Comparing them, however, says little about which design choices mattered or what they cost compared to a single agent. Factory's study of their own multi-agent system, which cycles an orchestrator, an implementer, and a validator in a fixed loop, shows how large that cost can be [ 4 ]. On one task, rebuilding the geospatial library GDAL, their three-role team more than doubled the reward achieved by a single agent, nearly reaching behavioral parity with the reference program, but cost 14 times as much and took 13 times as long.

Each task needs all three stages of the workflow, figuring out what the program does, writing it, and checking it against the original. That makes ProgramBench a good testbed for seeing which stages benefit from extra agents.

So agent teams can do more than a single agent, but they cost more to run and usually take longer. This raises an important question: if a team of agents is a new way to spend inference compute, how should it be organized to be both effective and efficient? To answer it, we built a controlled testbed and ran teams of coding agents on it.

Figure 1. An illustrative run of a coding-agent team. A lead hands out work to its workers, who explore the original program, write code, and check it in a shared workspace.

We built a deliberately minimal harness, inspired by mini-SWE-agent [ 5 ], so that we could change one design choice at a time. Every agent works through a simple bash tool, in one workspace shared by the whole team. One agent, the lead, receives the task and hands out work with a delegate_agent tool. A worker sees only the subtask it is given and reports back when it is done. Given the task, the lead dynamically decides how many workers to spawn, what each one does, and how to consolidate what they return. 1