Multi-Agent Teams in Claude Code and Codex: Worth It or Not?

Anthropic's hosted multi-agent system can scale to 8,000 agents on a single job, and in an internal bug-hunting test a multi-agent run found 66 of 70 planted bugs versus 14 to 27 for a single agent, while OpenAI Codex team member Eric Provencher argues that running more than two agents at once rarely improves quality and mostly adds a "coordination tax." Both companies advise starting small and letting one orchestrator agent decide when to split work into sub-agents, and the article notes cheaper sub-agent models can backfire: Haiku 5.5 scored 39% on Terminal Bench versus Sonnet 5.5's 71%, with extra fix rounds erasing the per-token savings.

Multi-Agent Teams in Claude Code and Codex: Worth It or Not? OpenAI's Codex team says multi-agent setups waste tokens. Anthropic ran 8,000 agents on one job. Here's when sub-agent teams actually help. The short answer OpenAI and Anthropic disagree on multi-agent setups, but less than it first appears. Codex’s team argues that running more than a couple of agents at once mostly burns tokens without improving output, because agents don’t trust each other’s work and end up re-checking it. Anthropic built a system that can run thousands of agents on a single job and used it to find far more planted bugs than a single agent could. Both sides agree on the same starting point though: don’t hand-build a fixed team of agents for every task. Let one agent act as an orchestrator and only split into sub-agents when the job actually needs it. TL;DR - Eric Provencher of the Codex team has said that running more than two agents at once rarely improves quality and mostly adds what he calls a coordination tax, since agents spend cycles double-checking each other instead of trusting prior work. - Anthropic’s hosted multi-agent system can scale up to 8,000 agents on one job, and in an internal test, a single agent found between 14 and 27 of 70 hidden bugs in a codebase while a larger multi-agent run found 66 out of 70. - Both companies still tell people to start small , because large agent runs spend a lot of tokens before they pay off in accuracy or coverage. - The newer recommendation is to drop fixed agent teams entirely and give the job to one orchestrator agent that decides for itself when and how to split work into roles, which is roughly how Claude Code’s newer project structure already works. - Custom sub-agents built purely around a role a “senior copywriter” agent, for example are now largely redundant, but agents that carry real knowledge the model can’t infer, like a specific checklist or a restricted toolset, are still worth keeping. - Putting cheaper models on sub-agent tasks can backfire : in one comparison, Haiku 5.5 scored 39% on Terminal Bench versus Sonnet 5.5’s 71%, and the extra fix rounds needed to correct Haiku’s mistakes ate up any savings from its lower per-token price. - Token price per model isn’t the same as cost per job , so the only reliable way to judge a setup is to run the same task both ways and compare total usage, not the sticker price. Everyone else built a construction worker. We built the contractor. One file at a time. UI, API, database, deploy. Why do OpenAI and Anthropic disagree on multi-agent setups? The disagreement is really about where each company draws the line on “how many agents is too many.” Provencher’s coordination tax argument is about trust: when multiple agents work on the same job without a clear hierarchy, they tend to re-verify each other’s output rather than build on it, which adds overhead without adding accuracy. That’s a real cost, and it shows up fastest in small or loosely coordinated teams where agents aren’t given clearly separated responsibilities. Anthropic’s large-scale run isn’t really a rebuttal to that point, it’s a different use case. Their 8,000-agent system wasn’t a flat team of equals arguing over the same task. It was built around one lead process that writes its own internal plan and spins up sub-agents only when a specific piece of work needs splitting out, similar to how a project manager might delegate a research task rather than ask ten people to each redo the whole task. In the bug-hunting test Anthropic ran, this structure let the system cover far more ground than a single agent could on its own, finding most of the 70 planted bugs instead of a fraction of them. So both companies agree that naive multi-agent setups waste tokens. They differ on how much structure and scale make the approach pay off. Codex’s team is skeptical that most everyday coding tasks need that scale at all. Anthropic is building infrastructure for the cases where they do. When does an agent team actually help? Multi-agent setups earn their cost when a task genuinely needs parallel, independent work streams, like researching across many separate sources, auditing a large codebase for different classes of bugs, or running the same analysis across many files that don’t depend on each other. In those cases, splitting the job lets different agents cover different ground at the same time instead of one agent working through everything in sequence. They stop paying off when the task is really one continuous thread of work; most day-to-day coding and writing tasks fall into this category. Asking several agents to weigh in on a single document or a single function tends to produce exactly the coordination tax Provencher describes: agents second-guessing each other’s assumptions instead of making progress. The practical dividing line isn’t “is this task complex” but “does this task split into genuinely independent pieces.” If it does, a team can help. If it doesn’t, a single well-briefed agent will usually be faster and cheaper. Should you still build custom sub-agents? Not for role-playing. Sub-agents that exist only to imitate a job title a “reviewer” agent, a “writer” agent, a “senior engineer” agent mostly duplicated what a single capable model can already do on its own once that model is good at planning its own steps. Newer top-tier models handle that internal division of labor without needing a human to pre-assign roles. Seven tools to build an app. Or just Remy. Editor, preview, AI agents, deploy — all in one tab. Nothing to install. Sub-agents still earn their keep when they carry information the main model has no way to infer. A checklist that encodes a decision your team already made, a restricted toolset so an agent can’t touch production data, or domain knowledge that isn’t written anywhere in the codebase are all legitimate reasons to keep a dedicated agent around. The test is simple: would removing this sub-agent cause the model to make a mistake it otherwise wouldn’t? If yes, keep it. If the sub-agent is just a persona wrapped around a generic prompt, it’s probably safe to delete. For the genuinely large jobs, the better move isn’t to manually assemble a fixed team, it’s to let the model build and size its own team, often through a built-in deep research mode or an orchestration workflow with an explicit size setting, so you can cap the setup before it spends more tokens than the job is worth. Is it worth using cheaper models for sub-agent work? Only if the cheaper model is actually good enough at the specific task, which isn’t a given just because it’s cheap per token. Haiku 5.5 launched at a fraction of Opus 5.5’s per-token price, which made “move your exploration sub-agents to Haiku” an immediately popular tip. The problem is accuracy: on Terminal Bench, Haiku 5.5 scored 39% against Sonnet 5.5’s 71%. A sub-agent that gets more wrong sends more work back to the main model for correction, and those fix rounds add up in both token spend and wall-clock time. The right comparison isn’t price per token, it’s total cost per completed job, including your own time reviewing or correcting the output. Running the same task on both a cheap and an expensive model and comparing total usage at the end is the only way to know which one actually costs less once mistakes are factored in. Do plugins and frameworks still improve Claude’s output? Less than they used to, for many tasks. Frameworks like Superpowers were built to give models an explicit process for planning, building, and testing work, because older models tended to skip steps without that scaffolding. As models like Opus 5.5 have gotten better at planning and following through on their own, some of that scaffolding has become redundant. One comparison of nine popular skill packs run hundreds of times against a placebo file of equivalent length found that only two of the nine produced measurably better results, and a widely used framework wasn’t one of them. That doesn’t make these tools worthless. Models are still imperfect, and some tasks benefit from explicit structure. It also doesn’t mean the frameworks were a waste of effort: that early scaffolding plausibly flagged exactly the gaps that model providers later closed. The practical approach is to run your real workflows both with and without a given plugin and compare the results directly, rather than assuming either that plugins are essential or that they’re obsolete. Frequently Asked Questions What is the “coordination tax” in multi-agent AI systems? It’s the extra token and time cost that comes from running multiple agents on a task without clear hierarchy or independent workstreams. Agents end up re-verifying each other’s work instead of trusting it, which adds overhead without necessarily improving the final output. How many agents can Anthropic’s system run on one job? Anthropic’s hosted platform can scale up to 8,000 agents on a single job, though both Anthropic and OpenAI recommend starting small since large runs consume significant tokens before producing better results. Is Haiku 5.5 a good choice for sub-agent tasks? It depends on the task. Haiku 5.5 is far cheaper per token than Opus 5.5, but it also scores lower on benchmarks like Terminal Bench 39% versus Sonnet 5.5’s 71% . If a cheaper model needs multiple correction rounds, it can end up costing more in total time and tokens than a stronger model. Do I still need custom sub-agents if I use a strong model like Opus 5.5? Role-based sub-agents built just to simulate a job title are often unnecessary now, since capable models can plan and divide work on their own. Sub-agents that carry specific knowledge or restricted tools the model can’t infer on its own are still worth keeping. Are frameworks like Superpowers still useful? For some tasks, yes, but less universally than before. As base models have improved at planning and following multi-step processes without external scaffolding, some popular frameworks have shown little measurable benefit over no framework at all in direct comparisons. Testing your own workflows with and without a given plugin is the most reliable way to decide.