Lessons From Scaling Teams Of Frontier Coding Agents

Scaling agent teams: reach the frontier at 30% of the cost Skip to content Introducing North 2: AI without compromises Learn more about the updates

Products

Solutions

Resources

Blog

Research

Company

Sign in

Request a demo

Platform North

Enterprise-ready AI for business

Compass

Intelligent search and discovery

Models Command

Generative language models

Transcribe New

Speech recognition model

North Small Translate NEW

Machine translation model

Parse New

Document parsing model

Embed

Semantic representation model

Rerank

Retrieval optimization model

Models Overview

Product Products Overview

Total Cost of AI Ownership

Pricing

Featured North 2: Cohere's latest platform update — with 15+ new features

Deploy Model Vault

Dedicated model inference platform

Private Deployments

On-prem or isolated VPCs

Security

Protect your data at every stage

See deployment options

By Industry Financial Services

Public Sector

Technology

Telecommunications

Energy and Utilities

Healthcare

Manufacturing

Featured Model Vault provides fully-isolated, performant inference with Saas simplicity

Insights Customer Stories

For Developers Developers

Models Overview

Docs

Discord

LLM University

Connect Partners

Events

Webinars

Merch Store

Featured How CoreWeave used Cohere North to transform its customer support in 90 days

Blog

The latest news, launches, and insights

Read more

North 2: Enterprise AI without compromises

Introducing Embed 5—A new family of frontier embedding models

Cohere and Aleph Alpha sign agreement to become the first transatlantic sovereign AI solution

Research Cohere Labs

Cohere’s ML research lab

Explorations Future(s) of Work

How will AI change the way we work?

Aya Models

Multilingual AI at scale

All Papers

Initiatives Research Scholars

Finding the new generation of ML talent

Open Science Community

Championing global, open science

Catalyst Grants

Supporting impactful ML endeavors

Resources Blog

Hugging Face

Events

Featured The future of work debate has an evidence problem

About

Careers

Newsroom

Oct 14, 2026

17 minute read

Lessons from scaling teams of coding agents: reach the frontier at 30% of the cost Teams of coding agents are already building large-scale software, but how should they be organized to work most effectively and efficiently?

Key takeaways Teams of agents unlock a new axis of inference-time scaling. On challenging coding tasks, well-organized teams outperform single agents, with gains of up to ~10 percentage points on ProgramBench. But these gains come at 3–7× higher cost. The question is not whether more agents help, but how to make that additional compute count. Where you allocate agents matters more than how many you add. On ProgramBench, delegating only exploration and planning matches the performance of delegating planning, implementation, and verification together at half the cost. Collaboration pays off most when agents target the task's actual bottleneck. A strong lead with cheap workers delivers near-frontier performance at 70% lower cost. A Sol lead coordinating 16 inexpensive Luna planning workers reaches 61.8% reward, compared with 63.2% for an all-Sol team delegating every stage, while reducing cost from $510 to $155.

Agent teams are building software 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. 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. A controlled testbed A minimal harness 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 Each delegate_agent call either starts a new worker with a fresh context window or resumes a worker the lead has used before. A resumed worker keeps its prior context, so the lead can follow up with an agent that already knows part of the program. For example, the lead can ask a worker to fix the bugs in the code it wrote, instead of briefing a new worker from scratch. From there, we vary five things: Where the lead uses workers. We instruct the lead agent with two main prompts, which differ in how much guidance they give....