Codex CLI: gpt‑5.6‑sol Ultra Fast background loop drained weekly limit #33276

Activity

1. klementv-cpu

   added

   bugSomething isn't workingSomething isn't working

   on Jul 15, 2026
2. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

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

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

   on Jul 15, 2026
3. 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.

   • Parallel subagents cause extreme token amplification and repeated compaction #33196
   • MultiAgentV2: send_message at a sampling boundary can leave a live subagent running but unscheduled #32756

   Powered by Codex Action
4. cansitki commented on Jul 21, 2026

   

   cansitki

   on Jul 21, 2026

   More actions

   Confirming a closely matching Linux/CLI reproduction, with Fast disabled.

   Environment:

   • Codex CLI 0.144.5
   • ChatGPT Pro via ChatGPT authentication
   • Linux 6.8.0-136-generic x86_64, tmux 3.4
   • model gpt-5.6-sol, reasoning ultra, summaries auto
   • service_tier = "default"; Fast mode not enabled
   • multi-agent enabled

   Sanitized local telemetry from one long-lived main thread:

   • The thread started July 19 and the local rollout is approximately 268.9 MB.
   • At 2026-07-21 04:43:10 UTC, weekly usage was 28% used and cumulative thread telemetry reported 349,056,550 total tokens.
   • At 2026-07-21 11:15:34 UTC, weekly usage was 65% used and cumulative total was 502,554,467 tokens.
   • At 11:25:46 UTC, cumulative total was 508,615,973 tokens: 506,834,387 input tokens, of which 489,251,840 were cached input. These are local token_count telemetry values, not a claim that all tokens were billed identically.
   • The parent trace contains 137 wait_agent calls and 73 list_agents calls since thread start. On July 21 UTC alone: 47 wait_agent and 27 list_agents.
   • Recent small coordination/status turns repeatedly carried roughly 140k to 145k input tokens each.

   Observed behavior:
   The parent continues making model turns to poll or coordinate subagents. In a long context, even a status-only turn appears to reprocess a very large cached context and the weekly quota drops quickly. The persisted service tier is default, so this reproduction is not explained by the Fast multiplier present in the original report.

   This looks consistent with #34468 and potentially the Sol tool-turn amplification in #32503. #14593 is the maintainer-designated generic tracker.

   Expected behavior:

   • subagent completion and status should be event-driven or use bounded polling without a full parent model turn each time;
   • waiting with no completed agent should not repeatedly reprocess the full parent context;
   • the UI and CLI should expose per-parent and per-subagent usage so this can be diagnosed.

   I am intentionally not attaching the local transcript or account/session identifiers publicly because the thread contains private project context. I can submit reviewed logs through /feedback if maintainers need a private diagnostic ID.
5. shahlo02 commented on Sep 7, 2026

   

   shahlo02

   on Sep 7, 2026

   More actions

   I had a similar incident using Light mode but not ultra fast on Version 26.901.51231

   Note - I am now gated by the 5 hour limit, so it hit that gate, and it wasn't done so who knows how far this would have gone if the limit didn't hit. It did still drain down over 10% of my weekly usage.

   Summary

   A single Codex agent turn entered a runaway execution pattern, consumed approximately 9.78 million tokens, exhausted my usage limit, and terminated without delivering a final response.

   The incident appears to involve a combination of:

   • Extremely long-lived root-agent execution
   • Failure to stop at an explicit user-approval gate
   • Continued use of a high-tier model for routine implementation
   • Repeated tool execution with a very large accumulated context
   • Repeated wait_agent calls while the root conversation was approximately 190k tokens
   • No effective circuit breaker before account quota exhaustion

   Codex Feedback ID: 01a07c78-af74-7b72-85b9-1db502146f0b

   I can provide the affected thread ID and complete post-mortem privately if needed.

   What happened

   The session began with a multi-part remediation task.

   Initially, the root agent spawned three lightweight/read-only scout agents to inspect different aspects of the workspace. Those agents returned successfully.

   After that initial research phase, however, the root driver remained on gpt-5.6-sol and performed dozens of implementation, file-editing, scripting, verification, and incident-logging operations inside the same conversational turn.

   During the run, the agent created a remediation proposal that explicitly stated it was:

   AWAITING USER APPROVAL

   The proposal also contained multiple judgment calls requiring user input.

   Instead of presenting that proposal and yielding, the agent continued execution. It spawned an additional high-reasoning audit agent and subsequently entered a repeated wait_agent pattern.

   The root conversation had grown to approximately 190k tokens at this point.

   Four wait_agent calls were made with approximately 180-second timeouts. According to the post-mortem generated from the session trace, more than 1.2M tokens were consumed during this final waiting phase alone.

   The session eventually terminated with a usage-limit error.

   No final response was delivered to the user.

   Observed impact

   Approximate usage recorded by the post-mortem:

   • Input tokens: 9,746,259
   • Output tokens: 32,751
   • Total: 9,779,010
   • Tool iterations: 60+
   • User-visible completion: None
   • Termination: Usage limit exceeded

   The full account usage allowance was exhausted during this single turn.

   Expected behavior

   At least one of the following should have prevented this outcome:

   1. The agent should have stopped when it reached the explicit user-approval gate.
   2. The agent should have yielded after a reasonable number of tool operations.
   3. The system should have warned or stopped execution as token consumption accelerated.
   4. Long-running wait_agent operations should not cause uncontrolled repeated processing of an extremely large root context.
   5. A root agent should not be able to exhaust an account's usable quota in one runaway turn without returning any result.

   Actual behavior

   The agent continued beyond its approval boundary and continued issuing tools after the session had become very large.

   After spawning a final audit agent, it repeatedly waited for that agent while retaining the accumulated root context.

   Execution continued until the account usage limit was reached, at which point both the useful work and the final response were lost.

   Possible amplification mechanism

   The session trace suggests that repeated tool/wait operations late in the turn were executed while the root context was approximately 190k tokens.

   If the entire accumulated root context is processed again for every wait_agent / tool continuation, this can create an enormous token multiplier during long-running agentic sessions.

   I do not know whether this accounting/execution behavior is expected, but in this case the user-facing result was approximately 9.78M tokens consumed by one turn with no final answer.

   Additional contributing behaviors

   The post-mortem also identified:

   • Repeated rereading/editing of a large incident-log file during active execution
   • Repeated recovery from minor shell/script errors
   • Continued high-tier-model use after the difficult reasoning portion had ended
   • File newline normalization/reverification loops
   • Failure to yield despite an explicit approval requirement
   • No hard tool-call/session-fatigue boundary being enforced by the harness

   These contributed to context growth, but I believe the central product issue is that the harness allowed the runaway process to continue until quota exhaustion.

   Suggested safeguards

   Some possible protections:

   • Hard or adaptive per-turn tool-call circuit breaker
   • Token-spend warning / circuit breaker for agentic turns
   • Mandatory yield when an explicit approval gate is reached
   • Context compaction before repeated long-running waits
   • Avoid reprocessing the full root context solely to poll a subagent
   • User-visible warning when a single turn begins consuming an unusually large percentage of the account allowance
   • Graceful termination that still returns a partial result/state summary before quota exhaustion

   Diagnostics

   Driver model: gpt-5.6-sol

   Feedback ID: 01a07c78-af74-7b72-85b9-1db502146f0b

   Incident date: September 7, 2026

   I have a detailed 138-line adversarial review/post-mortem reconstructing the session, including the tool sequence, token figures, approval-gate failure, and final wait_agent loop. I can provide the complete report and thread identifiers privately to OpenAI maintainers.