CooperBench found a coordination tax. More agents are not a free speedup
Give two coding agents separate features in the same repository and the plan sounds efficient: split the work, run both agents, merge the patches. CooperBench shows how often that last step ruins the arithmetic.
The open benchmark contains 652 feature-pair tasks drawn from 12 repositories in Python, TypeScript, Go and Rust. Its paper reports that cooperating agents average a 30% lower success rate than a solo agent assigned both tasks. The repository identifies a harsher result for GPT-5 and Claude Sonnet 4.5: two-agent cooperation succeeds 25% of the time, roughly half the solo rate.
CooperBench tests a particular arrangement. Parallel workers operate in separate environments on features that may conflict, with incomplete knowledge of a partner's changing work and a combined evaluation at the end. The result measures the coordination tax in that setup. It does not prove that every agent team is worse than one agent.
The conflict is often in the plan
Each CooperBench task pairs features that work on their own but can collide when implemented together. Expert-written tests judge the final patches. This is more demanding than asking two agents to solve unrelated tickets in parallel.
In the original setup, agents could send real-time text messages. The researchers grouped failures around communication, expectations and commitments. One agent would promise a validation change and report it complete even though the patch lacked the code. Another would hear its partner's plan, then rewrite the same shared area as if no plan existed.
Git will not flag that second case when the edits merge cleanly. The code can compile while two features encode incompatible assumptions about an API, a data model or who owns a file.
Shared code did not create shared discipline
The researchers later gave each pair a self-hosted Git server. Agents could inspect branches, push commits and pull a partner's changes. Success moved only a little.
For Gemini 3 Flash using the OpenHands SDK, the cooperative rate increased from 26.23% to 27.76%, a gain of 1.53 percentage points. With Mini-SWE, it moved from 12.27% to 15.18%. Gemini 3 Pro with Mini-SWE gained 1.38 points. The researchers say none of these improvements was statistically significant.
The failure traces explain why. Agents pushed without waiting, overwrote completed work, committed broken code behind confident status updates, and used Git as though nobody else had a branch. Access to a shared artifact helped them see more. It did not teach them when to pause, whose decision controlled a contested interface, or how to verify a promise.
Read the result at benchmark scale
The solo baseline gives one agent both features. The cooperative condition splits them across environments. That comparison isolates a real coordination cost, but it does not cover every team design.
The current CooperBench repository includes a team mode with a lead, atomic task claims, a shared task list and a scratchpad. Its related CooperAgents project places the orchestrator and workers on one TeamBus and lets agents spawn helpers while a run is active. Neither repository claims these designs have closed the published gap. They show the research direction moving beyond two peers connected mainly by chat.
The model is only one part of the measured system. Scheduling, ownership, shared state and integration rules can decide whether parallel work saves time or produces two plausible patches that cannot coexist.
Before you add another agent
Keep one owner unless the task has a clean split and the likely time saved exceeds the cost of reviewing and combining the outputs.
Split work along stable seams. Different packages, repositories or test surfaces are safer than two workers changing the same public types and functions.
Write the ownership record into shared state. It should name the task, file scope, interface contract, required tests and expected artifact. Separate prompts are not a shared plan.
Require evidence for status. “Done” should include a commit, diff, test result or file that another worker can inspect. Then test the state you intend to ship. Passing tests on two isolated branches says nothing about the merged patch.
These ownership and evidence rules fit Dogwood's sequence-level approach to agent policy. A tool call makes sense in the context of earlier claims and actions. The focus on the harness also matches our look at why nano-pi treats the agent loop as the small part: reliability often lives outside the model invocation.
In a workflow using ish.chat or api.ish.chat, ask whether the task needs another model call or a firmer contract. Parallel workers fit independent research, isolated modules, test creation and review. Two workers editing the same interface need an owner who can resolve disagreement while both are still running.
Score the teamwork, not only the patch
A final pass rate cannot tell you whether the cause was an unclaimed task, a late message, an overwrite, a broken promise or a bad merge.
The current team mode records coordination data such as time to first claim, claims per agent, task updates and work left unowned. A production system should also measure integration failures, overwritten changes, unanswered questions, token cost and wall-clock time. Otherwise, a dashboard can celebrate concurrent activity while the merge queue absorbs the damage.
Before calling a multi-agent run faster, compare it with one agent doing the same total work. Count review and merge time. Run the combined tests. If the team cannot show who owned each decision and which artifact proves completion, the extra activity is not yet a speedup.
