Parallel subagents cause extreme token amplification and repeated compaction #33196

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   subagentIssues involving subagents or multi-agent featuresIssues involving subagents or multi-agent features

   contextIssues related to context management (including compaction)Issues related to context management (including compaction)

   rate-limitsIssues related to rate limits, quotas, and token usage reportingIssues related to rate limits, quotas, and token usage reporting

   on Jul 15, 2026
2. github-actions commented on Jul 15, 2026

   

   github-actionsbot

   on Jul 15, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex eats up my limit by getting stuck in compaction loops #32809

   Powered by Codex Action
3. lunaynx commented on Jul 19, 2026

   

   lunaynx

   on Jul 19, 2026

   More actions

   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.
4. cansitki commented on Jul 21, 2026

   

   cansitki

   on Jul 21, 2026

   More actions

   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.
5. 92645417d9e5c763259dbebc306e3e commented on Aug 18, 2026

   

   92645417d9e5c763259dbebc306e3e

   on Aug 18, 2026

   More actions

   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.
6. kosza123 commented on Aug 25, 2026

   

   kosza123

   on Aug 25, 2026 – with ChatGPT Codex Connector

   More actions

   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