Eric Provencher, who leads developer experience for Codex at OpenAI, has sounded the alarm on running too many parallel sub-agents. According to him, going beyond two concurrent agents is likely to burn tokens without improving quality. Yet in the same week, Nous Research published a case study in which it used 1,393 agents to refactor more than a million lines of Python code, calling it a way to push forward work that had been deprioritized by human engineers due to its cost—completed in 19 hours. Taken together, the two claims suggest that before counting agents, we need to separately measure elapsed time, total token usage, and the quality of the outcome.
What Matters More Than 'Two Agents': The Substance of the Coordination Tax
In September 2026, Provencher posted on X that running more than two parallel sub-agents is "almost certainly burning tokens without improving quality." The reason, he said, is that each agent cannot fully trust the others' work, so it ends up repeating checks that another agent has already completed. In a separate post, he described the difficulty of keeping many parallel lanes running without drift or excessive verification as a "coordination tax."
Token consumption doesn't only grow from the sub-agents' own responses. Each agent has to re-read the shared objective and the repository's context, then search for the files and tools it needs. The parent agent, meanwhile, receives these reports, resolves contradictions, and integrates the changes. If the boundaries between agents are unclear, the same searches and the same checks end up overlapping. Even if parallel search shortens the time to an answer, the total volume of input processed can still increase. Provencher himself concedes that parallelization is reasonable when there's both the budget and the reason to pay a premium for speed.
The workflow he describes has Astra plan the work, dispatch the divided tasks to separate threads, and then let the main agent stop processing for a while. Child threads notify the main agent only once they're done. The idea is to cut down on constant progress-checking and prevent each thread from repeatedly re-reading the same context.
That said, the "two-agent" figure isn't a ceiling derived from any published comparative test. The target tasks and models used aren't disclosed, nor is the number of trials. No quality metric or method for tallying tokens has been shown either—for now, it's a rule of thumb based on Provencher's own hands-on experience.
Were 1,393 Agents Really Wasteful?
Nous Research's case study challenges that rule of thumb at an extreme scale. The main run of Hermes Agent lasted about 19 hours and spawned 1,393 sub-agents, with as many as 218 running concurrently. It split more than a million lines of non-test Python code into 36 non-overlapping regions. Each agent worked in its own isolated workspace (a Git worktree) and received instructions specifying the scope it could touch, the external specifications it had to preserve, and the checks it needed to run.
The estimated model cost for the main run came to about $19,300, rising to roughly $25,000 once work after resumption is included—separate from the time spent on human review. Even so, Nous argues that having a small team carry out the same work would have taken two months to two years and cost between $150,000 and $1.8 million by its own rough estimate, and it emphasizes the value of pushing forward a long-neglected refactor in a short time. That human-labor cost is a wide-ranging counterfactual, not a controlled comparison of total cost.
The results are substantial. Non-test Python code shrank from 1,063,826 lines to 698,363 lines, a 34.4% reduction. Files exceeding 5,000 lines dropped from 37 to 6, and functions exceeding 300 lines fell from 192 to 2. gateway/run.py, the largest file, went from 34,847 lines to 5,512. The burden of reading through gigantic definitions did genuinely decrease.
At the same time, review turned up regressions that existing tests had missed. The refactor deleted public names that could be used by external plugins, on the grounds that no in-repo caller referenced them, and an automated rewrite of exception handling rippled out to roughly 65 locations. Fixes went through two rounds of community review before merging, but additional fixes kept coming afterward. Line-count reduction can't simply be equated with improved quality.
Nous also ran a simulation of searching for 4,000 symbols. The average number of tokens returned per definition lookup fell from 2,218 to 993, a calculated 55.2% reduction. But what this measures is the amount of context returned during code search, not the rate at which agents correctly complete engineering tasks. The median actually rose, the number of modules and dependencies increased, and loading became slower at some entry points.
No Study Proves 'Zero Quality Gain'
Provencher criticized the Hermes case, arguing that a single Astra instance could have done the job for a fraction of the cost. But no results have been published from giving a single Astra instance the same codebase, the same completion criteria, and the same checks. Hermes, for its part, has no comparison group of a solo run either. So while it's confirmed that 1,393 agents drove up the cost, it hasn't yet been measured whether a single model could achieve the same quality more cheaply.
The same limitation applies to the opposite claim. The $150,000–$1.8 million human-labor cost that Nous cites is an internal estimate, and the AI-side figure doesn't include the time spent on human review. Moreover, while the drop in line count and giant-function count shows a structural change, it doesn't prove anything about future change velocity, defect rates, or maintenance costs. The two sides are also optimizing for different goals: Provencher is asking about token efficiency, while Nous is evaluating the option of finishing long-deferred work in a short time.
OpenAI's official guidance recommends an approach close to this. First, strengthen the capability of a single agent equipped with tools, keeping the setup and evaluation simple. Only then, if there are too many conditional branches for instructions to be followed reliably, or if the agent keeps picking the wrong tool among similar options, should you consider splitting into multiple agents. Rather than deciding on a headcount up front, the idea is to identify why a single agent fails and then divide roles accordingly.
Measure Divisibility, Not Agent Count
Placing all three primary sources on the same axis, whether parallelization succeeds or fails should be judged not by the number of agents itself, but by the independence of task scopes, overlap in shared context, integration and verification load, and the value of elapsed time.
| Decision axis | Favors a single agent or a small team | Parallelization can be considered |
|---|---|---|
| Task scope | Touches the same design decisions or the same files | Scope and inputs/outputs can be separated in advance |
| Shared context | Everyone needs a large volume of history | A short instruction sheet suffices for each agent |
| Integration | Contradictions require human judgment to resolve | Can be reconciled through automated checks and explicit specs |
| Failure isolation | A single fix ripples across the whole system | Workspaces and permissions can be separated per agent |
| Value of time | Minimizing total cost takes priority | Shortening the deadline justifies the added tokens |
Unless the conditions on the right side of this table are met, adding more agents mainly inflates redundant processing. In particular, for work where shared history can't be compressed into short instructions and integration still requires human judgment, it's easier to measure cost by starting with a small team.
The key condition that made Hermes work wasn't the number 1,393—it was setting up 36 non-overlapping regions and separate workspaces in advance. Even so, the removal of an external specification and a regression in exception handling slipped through, and human review became the last line of defense. If the same scale were applied to work that can't be divided into separate scopes, each agent would read the same shared context, redo the same judgments, and require the whole system to be re-verified again at integration.
Future evaluations should record completion time and total input/output tokens together. On top of that, redundant tool calls, the number of integration and review rounds, detected regressions, and the rate of meeting completion criteria all need to be compared against a solo run on the same task. Parallelization pays off when the extra tokens spent for speed are recouped through a shortened deadline or the clearing of deferred work.