MultiAgentV2 runaway delegation: 74 subagents, 3-level nesting, 5.39B recorded tokens, and repeated review/test loops in one task

Summary

I observed a long-running Codex task where MultiAgentV2 delegation expanded into 74 unique subagents, including recursively spawned subagents up to depth 3.

By the time the implementation task completed, the root thread plus all subagents had accumulated:

• 75 total execution threads: 1 root + 74 subagents
• 82 spawn_agent attempts
• 74 successful spawns
• Maximum nesting depth: 3
• 5,389,446,245 total recorded tokens
• 4,977,729,875 tokens from subagents alone
• 53 / 74 subagents were review/audit/preflight-style tasks
• At least 18 full pytest -q executions
• The exact same controller test command was executed 13 times
• The exact same memory/v1 test command was executed 5 times

One review subtree (task4_design_review) alone expanded to 39 agents and accumulated approximately 3.263B tokens.

After I explicitly instructed the root agent:

Continue, but do not create any more subagents. Execute all remaining tasks directly in the current session.

there were no further spawn_agent attempts. The remaining integration and verification work completed in approximately 3h15m, with approximately 96.85M additional root-thread tokens.

I am not claiming a controlled 15× performance comparison, because the work before and after that boundary was not identical. However, the local rollout/state data strongly suggests substantial delegation churn, context amplification, and duplicated review/verification work.

This report is primarily about MultiAgentV2 delegation behavior and workload amplification, not billing/quota accounting.

---

Related issues / distinction

This appears related to:

• #35463 — recursive MultiAgentV2 spawning, missing effective depth limit, and usage amplification
• #34061 — subagent/full-history session amplification and excessive local persistence

However, this report focuses on a somewhat different failure mode:

A normal long-running coding/research workflow can evolve into a large recursive agent tree with repeated review → fix → re-review cycles, even when much of that work is highly state-dependent and appears poorly suited for recursive delegation.

The concern is not only duplicated token bookkeeping or session storage. The system actually performed a large amount of additional agent work: repeated reviews, repeated tests, follow-up fixes, and further sub-delegation.

The behavior described here was observed on codex-cli 0.146.0, so the excessive recursive delegation / agent-churn behavior is still present in this version.

---

Environment

• Codex CLI: codex-cli 0.146.0
• Model family: gpt-5.6-sol
• Multi-agent implementation: MultiAgentV2
• Date observed: 2026-08-15 → 2026-08-17
• Root reasoning effort varied during the session:
• ultra: 30 turn contexts
• xhigh: 11
• medium: 8
• Most subagents ran with gpt-5.6-sol / ultra

---

Observed agent tree

I reconstructed the tree recursively from thread_spawn_edges, deduplicating by agent_thread_id / agent_path.

Root
├── Depth 1: 25 agents
│   ├── task2_controller
│   │   └── Depth 2: 1
│   ├── task3_design_review
│   │   └── Depth 2: 8
│   ├── task3_full_diff_review
│   │   └── Depth 2: 1
│   ├── remaining_plan_audit
│   │   └── Depth 2: 1
│   └── task4_design_review
│       └── Depth 2: 34
│           ├── task4_final9_memory_import_fix
│           │   └── Depth 3: 3
│           └── task4_final10_checkpoint_fix
│               └── Depth 3: 1
├── Depth 2 total: 45
└── Depth 3 total: 4

Totals:

Depth 1: 25
Depth 2: 45
Depth 3:  4
----------------
Subagents: 74
Threads including root: 75

This confirms that subagents were themselves spawning additional subagents.

The largest subtree was task4_design_review, with:

• 1 depth-1 agent
• 34 direct children
• 4 depth-3 descendants
• 39 agents total
• approximately 3,263,213,025 accumulated tokens

---

Spawn behavior

Across all recursive rollout files I found:

| fork_turns | Spawn attempts | Successful |
|---|---:|---:|
| all | 19 | 16 |
| 3 | 14 | 13 |
| 5 | 1 | 1 |
| none | 48 | 44 |
| Total | 82 | 74 |

Failures included:

• 7 × agent thread limit reached
• 1 × agent path already existed

The root itself made:

• 27 spawn attempts
• 25 successful direct-child spawns

The remaining agents were created recursively by subagents.

---

Token usage

Token accounting was reconstructed from the final event_msg.payload.type == "token_count" in each rollout and cross-checked against state_5.sqlite -> threads.tokens_used.

All 74 subagent values matched.

At implementation completion:

| Scope | Input | Cached input | Output | Reasoning output | Total |
|---|---:|---:|---:|---:|---:|
| Root | 411,005,924 | 404,820,480 | 710,446 | 212,571 | 411,716,370 |
| 74 subagents | 4,962,159,373 | 4,842,526,208 | 15,570,502 | 4,741,191 | 4,977,729,875 |
| Total | 5,373,165,297 | 5,247,346,688 | 16,280,948 | 4,953,762 | 5,389,446,245 |

cached_input is a subset of input and reasoning_output is a subset of output, so they are not added again to the total.

I am also not claiming that this number equals billed subscription/API usage. This is the usage recorded by Codex in the local/backend session telemetry.

---

Strong correlation with history forking

Successful agents grouped by fork_turns:

| Fork mode | Agents | Accumulated tokens |
|---|---:|---:|
| all | 16 | 2,777,454,809 |
| 3 | 13 | 1,943,231,508 |
| 5 | 1 | 103,876,630 |
| none | 44 | 153,166,928 |

So only 30 agents using all / 3 / 5 accounted for approximately 4.824B tokens, while 44 none agents accounted for approximately 153M.

This is strong evidence that history-carrying forks can have enormous context cost in a long-running session.

However, these groups performed different tasks, so I am not claiming that the difference in their average usage is caused solely by fork_turns.

---

Most subagents used high reasoning effort

Actual combinations across the 74 subagents:

| Model / effort | Agents |
|---|---:|
| gpt-5.6-sol / ultra | 57 |
| gpt-5.6-sol / high | 7 |
| gpt-5.6-sol / medium | 4 |
| gpt-5.6-terra / high | 5 |
| gpt-5.6-terra / medium | 1 |

This means the delegation tree was not primarily made of lightweight worker agents.

Most child work was performed by gpt-5.6-sol at ultra.

---

Repeated review / fix / verification loops

Of the 74 subagents, 53 had task names containing one of:

review
rereview
audit
preflight

Inside task4_design_review alone:

• 34 direct child agents
• 24 were review/audit tasks
• 7 were fix tasks
• review/fix cycles progressed repeatedly from final2 through final10

The 29 review-round-style agents in this subtree accumulated 1,539,367,164 tokens.

Examples of the sequence include:

task4_contract_review
task4_runtime_review

task4_final_contract_review
task4_final_runtime_review

fix_w4_memory
fix_condition_launch

task4_postfix_contract_review
task4_postfix_security_review

fix_recovery_identity
fix_metric_w4

task4_final2_contract_review
task4_final2_security_review

...

task4_final9_contract_review
task4_final9_integrity_review
task4_final9_release_review

task4_final9_claims_fix
task4_final9_memory_import_fix

task4_final10_paper_whole
task4_final10_memory_whole
task4_final10_paper_fixes
task4_final10_checkpoint_fix

This looks less like useful parallel decomposition and more like an increasingly large review → fix → re-review feedback tree.

---

Repeated test execution

The rollout logs contain at least 18 explicit full-suite runs of:

.venv/bin/python -m pytest -q

Additionally:

• One identical set of 5 controller tests was run 13 times
• One identical memory/v1 test set was run 5 times
• task1_event_core reported complete suites at multiple successive stages:
• 109 passed
• 121 passed
• 129 passed
• 136 passed
• 163 passed

There were also repeated process-polling commands.

I cannot reliably quantify duplicated repository searches because many searches were embedded inside different compound shell commands, so I am deliberately not making a claim about that.

---

Manual delegation kill switch

At 2026-08-17T07:21:45.369Z I explicitly instructed the root:

Continue, but do not create any more subagents. Execute all remaining tasks directly in the current session.

I repeated the instruction at 2026-08-17T07:31:31.997Z.

After the first instruction:

• 0 new spawn_agent attempts occurred
• all previously created subagents had already completed
• remaining work was executed directly by the root

The implementation completed at 2026-08-17T10:37:33.886Z, so the remaining phase took 3h15m48.517s.

The verifiable root-token increase over that phase was approximately 96,851,149 tokens.

This value is an upper-bound based on the nearest prior token snapshot rather than a token counter sampled at the exact instruction timestamp.

---

Wall-clock observation

The multi-agent-heavy phase spanned approximately 48h57m33s, while the phase after disabling new subagents took approximately 3h15m48s.

Again, these are not identical workloads, so this must not be interpreted as a controlled benchmark or as proof that single-agent execution is exactly 15× faster.

My conclusion is narrower:

The logs demonstrate that the multi-agent phase created a very large amount of delegation, context processing, review work, and repeated verification that disappeared once further delegation was disabled.

A controlled benchmark would be needed to assign an exact wall-clock cost to each factor.

---

Why I think this is a problem

Multi-agent delegation is useful when tasks are independent, expensive, parallelizable, and require little shared mutable state.

This workload was instead highly iterative:

implement
→ test
→ review
→ fix
→ re-review
→ regression test
→ fix
→ final review

Many tasks depended directly on the previous modification of the same repository.

Under this workload, MultiAgentV2 appears able to transform a relatively sequential dependency chain into a large recursive agent tree.

The cost then includes:

task decomposition
+ child startup
+ context forking
+ child reasoning
+ repeated repository inspection
+ parent/child synchronization
+ review synthesis
+ repeated tests
+ follow-up fixes
+ recursive delegation

In other words:

More agents produced substantially more work, but not necessarily more useful parallelism.

---

Steps to reproduce

This is an observed reproduction rather than a minimal deterministic test.

1. Start a long-running Codex coding session using gpt-5.6-sol.
2. Use high/ultra reasoning effort and allow MultiAgentV2 delegation.
3. Give Codex a multi-stage implementation task requiring implementation, tests, design review, correctness/security review, fixes, regression testing, and final review.
4. Allow the root agent to delegate work to subagents.
5. Do not explicitly request several levels of recursive subagent delegation.
6. Let review agents identify additional issues and perform or delegate follow-up work.
7. Monitor thread_spawn_edges, subagent depth, total unique agent count, spawn_agent calls, fork_turns, accumulated token usage, and repeated shell/test commands.
8. Observe whether review/fix cycles create increasing numbers of descendant agents.
9. Midway through the workflow, explicitly instruct the root not to create any more subagents and continue locally.
10. Compare subsequent spawn count, token growth, duplicated test executions, and wall-clock progress.

---

Expected behavior

I would expect MultiAgentV2 to avoid delegating when the estimated coordination cost exceeds the parallelism benefit.

In particular:

1. Recursive subagent spawning should be bounded. A child should not be able to create an effectively unrestricted descendant tree.
2. A global per-root delegation budget should exist. For example, limits on total descendants, spawn attempts, cumulative subagent tokens, and nesting depth.
3. Review loops should converge instead of recursively expanding. Repeated review → fix → re-review → fix → re-review should eventually return control to the root instead of continually creating new agents.
4. Sequential/shared-state work should normally stay local. If a child task depends strongly on modifications made moments earlier in the same repository, local execution may be preferable to delegation.
5. History forking should have explicit cost awareness. Spawning a child with a very large inherited context should require a stronger justification than spawning a context-free worker.
6. The user should be able to control recursive delegation. For example, agents.max_depth = 1 or an equivalent MultiAgentV2 setting should reliably mean root → child allowed, child → grandchild denied.

---

Suggested safeguards

Possible safeguards:

• Enforce a depth limit in MultiAgentV2.
• Add a total descendant / spawn-attempt budget per root.
• Add a global subagent token budget.
• Make delegation cost-aware before spawning.
• Avoid expensive history forks unless required.
• Detect repeated review churn (final2, final3, ... final10) and force convergence back to the root.
• Deduplicate expensive verification when the same test command is run repeatedly against effectively the same revision.
• Expose delegation diagnostics: total descendants, active descendants, max depth, subagent tokens, fork mode, parent, model/effort, and spawn reason.
• Add a first-class runtime Disable further delegation control so users can stop agent-tree growth while allowing the root task to continue.

---

Local evidence available

I reconstructed these results from:

~/.codex/sessions/.../rollout-*.jsonl
~/.codex/state_5.sqlite
~/.codex/session_index.jsonl
~/.codex/app-server-control/app-server.log

The audit includes:

• all 74 thread IDs
• parent-child relationships
• nesting depths
• creation/update timestamps
• task/agent paths
• fork_turns
• model/reasoning effort
• per-thread token usage
• spawn failures
• repeated test commands

I can provide a sanitized agent-tree dump and selected rollout excerpts if that would help debugging.

I would prefer not to upload complete rollout JSONL files publicly because they contain conversation/project information.

---

Bottom line

The evidence supports:

• Excessive delegation / agent churn: yes
• Recursive child → grandchild spawning: yes
• Large context cost associated with history-carrying forks: strongly supported
• Repeated review / regression work: yes
• Exact causal wall-clock slowdown attributable to each mechanism: not established without a controlled baseline

The main request is therefore:

Please consider adding bounded recursive delegation, global agent/token budgets, and cost-aware delegation/convergence behavior to MultiAgentV2 so that a normal iterative coding workflow cannot silently expand into dozens of expensive agents.