Parallel subagents cause extreme token amplification and repeated compaction

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #32809

Powered by Codex Action

Are you using ultra mode? There's currently a bug (or "feature") with Codex where it will spawn every single subagent with ultra as well.

One measurement caveat may matter here: a child rollout JSONL contains a large replayed prefix of the parent/shared history at spawn. Counting every token_count or compacted event in each child file, then summing child files, therefore double-counts the same cumulative telemetry.

I audited 59 direct child rollouts from one long-lived multi-agent thread. Separating the replayed prefix from child-specific events gave:

• replayed prefix: 80,217 token_count events and 1,236 compacted markers
• child-specific portion: 3,592 token_count events and 44 compacted markers

Two representative rollouts contained 4,078 / 64 replayed events before 12 / 0 child-specific events, and 244 / 4 before 15 / 0, respectively (token_count / compacted).

This means the reported 1.4B aggregate should not be interpreted as independent new token usage, or as billing-equivalent usage, without deduplicating the shared history. This does not remove the underlying amplification problem: subagents inherit the parent model/reasoning setting (related: #32587), can start with very large contexts, and long-lived children genuinely produce many additional turns and compactions. But the thousands-of-events-in-two-minutes portion appears to be mostly rollout-history replay, not thousands of fresh model calls.

I can provide a sanitized classification script if it would help.

Additional evidence for #33196

• I am adding sanitized Codex CLI evidence to the existing report about parallel subagents, token amplification, and repeated compaction.

Environment

• Baseline: rust-v0.148.0-alpha.1.
• Model and mode: gpt-5.6-sol, Ultra reasoning, Multi-Agent V2 enabled.
• Subscription: ChatGPT Pro 20x.

Observed impact

• After remote context compaction, a new context can begin with approximately 100K tokens already occupied.
• In a sanitized long-lived CLI session, post-compaction last_token_usage.total_tokens was 108,247 while the reported model context window was 828,400.
• With an effective context window of 272,000, that baseline consumes about 40% immediately and leaves only about 164K tokens for new work. Repeated compactions make the thread practically unusable.

Decisive evidence

• The installed replacement history contained 68 AgentMessage items with 177,928 bytes of encrypted payload.
• A local item estimator attributed approximately 51,641 tokens to those AgentMessage items alone.
• Multi-Agent V2 constructs these encrypted items from inter-agent communication (source).
• Remote Compaction V2 retains non-final AgentMessage items up to 10K tokens each and scans a global 64K newest-first retained-history budget (source).
• The policy has no bound such as retaining AgentMessage items only from the latest N context windows.

Reproduction

• Start a long-lived CLI thread with Multi-Agent V2.
• Let the model repeatedly spawn agents and exchange encrypted messages through send_message or followup_task.
• Continue until several remote compactions occur.
• Inspect aggregate token_count data and replacement-history type/size counts; raw prompts, identifiers, and encrypted payloads are not required.
• The first post-compaction context is already near 100K tokens even though the configured working window is 272K.

Expected behavior

• A completed compaction should install a bounded replacement history small enough to leave most of a 272K context available.
• Encrypted AgentMessage history should be bounded by recent context windows or an explicit encrypted-message budget, rather than accumulating across the entire retained-history budget.
• Ciphertext should not be sliced bytewise. The safe operation is to drop complete old AgentMessage items or use a protocol-defined chunking mechanism.

Additional context

• The current compaction summary is sent into the next compaction request, but the previous summary is removed when the next replacement history is installed. The observed baseline is therefore dominated by retained encrypted AgentMessage history, not an unbounded chain of summaries.
• This report was prepared with assistance from Codex CLI.

Hi @ctykwz — I’m doing independent research on whether a vendor-neutral “no progress” watchdog could detect multi-agent replay/compaction loops before they amplify token use. Your parent + two nearly identical subagent sessions are a particularly valuable case.

Would you be willing to share a metadata-only export from those three sessions: timestamps, parent/child session role, event type, tool name, hashes of canonicalized arguments, context_compacted markers, cumulative token counters, patch-event counts, and stop/end time?

Please do not post raw transcripts, prompts, paths, file contents, patches, tool outputs, or secrets. If you’re open to it, just reply here; I can provide a minimal schema and redaction steps first. This is independent research, not OpenAI support or a product request.

Thanks — Filip