[Bug][Desktop][Subagents] One task processed 242.3M tokens and consumed 11 percentage points of weekly quota in 2h44m

Suggested GitHub issue title

[Bug][Desktop][Subagents] One task processed 242.3M tokens and consumed 11 percentage points of weekly quota in 2h44m

Summary

During one Codex Desktop coding task on September 16, 2026, Codex processed 242,318,802 telemetry-reported tokens across 1,545 model responses in 2 hours, 43 minutes, and 45 seconds.

The account's weekly usage meter rose from approximately 50% used to 61% used during the incident. That is an observed increase of 11 percentage points, not a claim that raw telemetry tokens map one-to-one to quota accounting.

Most of the volume was repeated cached-context processing:

Using a rough effective-usage weighting of cached input at 0.1x, uncached input at 1x, and output at 5x, the incident represents approximately 30,888,943 weighted tokens. Reasoning output is already included in output and was not added again.

This was not a productive quarter-billion-token workload. It was a context-amplification and orchestration failure. A large inherited conversation was replayed across hundreds of small model turns, while a reviewer and implementation agents were reactivated in a serial loop. Codex had no task-wide budget, no useful warning, and no automatic stop even as the weekly allowance visibly fell.

This appears related to, and may share a root cause with:

• #44884 — Extreme cached-context amplification in long-running tool-heavy Codex sessions
• #39808 — Subagent fan-out can increase usage because each agent pays fixed context/tool/skill overhead
• #41875 — Align wait_agent default timeout with prompt-cache TTL to cut parent-agent polling cost

This report adds a bounded, single-task reproduction in Codex Desktop and identifies a particularly expensive multi-agent failure mode: repeated follow-up turns on long-lived agents, a reviewer that reports issues one at a time, and task accounting that does not naturally aggregate reused agents across root-turn ownership boundaries.

Impact

The failure consumed roughly one tenth of the account's weekly allowance in under three hours. The user received no warning that the task had entered a pathological usage pattern. The work was not released or deployed, and the outcome was not remotely proportional to the quota consumed.

This makes autonomous coding unsafe to leave running even when the user gives a bounded implementation request. A user cannot reasonably infer from ordinary progress messages that small tool operations and review follow-ups are repeatedly processing about 150,000 input tokens each.

Severity: High — quota exhaustion, cost visibility, and product reliability.

Environment

• Product: Codex Desktop on Windows
• Shell: PowerShell
• Account plan reported by the usage API: Pro
• Root coordinator: gpt-5.6-sol, high reasoning
• Additional OpenAI subagents used for implementation, review, OCR analysis, acceptance review, and one installer repair
• Workload: a large TypeScript application with a long existing Codex conversation, screenshots, attachments, tool schemas, prior implementation history, and multiple requested checks
• No local LLM was invoked during this incident

Incident window

• Start: 2026-09-16T17:51:35.032Z
• End: 2026-09-16T20:35:19.645Z
• Duration: 02:43:44.613

Per-agent breakdown

The labels below describe roles and intentionally omit local thread identifiers.

The independent reviewer alone generated 571 model responses and 95.4 million total tokens. The coordinator and primary implementation agent added another 771 responses and 115.4 million total tokens.

What happened

1. The task began inside a very long Codex Desktop conversation containing extensive prior history, screenshots, pasted documents, system/tool descriptions, and previous work summaries.
2. Multiple subagents were started with too much inherited context. They did not receive compact, purpose-built briefs.
3. The implementation and review work was split across long-lived agents.
4. Review became an open-ended serial loop: the reviewer returned one issue; the coordinator sent a follow-up to an implementation agent; the reviewer resumed and found another issue; the cycle repeated.
5. Hundreds of small model turns each carried a very large cached-input component. Average input was about 156,500 tokens per response.
6. Waits, status checks, tool results, and follow-up dispatches created additional response boundaries carrying the same large context.
7. Live quota readings were checked and visibly moved through approximately 50%, 51%, 52%, 53%, 57%, 58%, 59%, 60%, and 61% used. Codex continued because there was no task budget or circuit breaker.
8. A standing worker-routing rule treated 10% remaining quota as the threshold for changing execution providers. Codex effectively treated that as permission to keep spending until the account approached exhaustion. That was a bad orchestration decision, but the product provided no guardrail against it.

The user's request for independent review did not require a reviewer to stay in an unbounded issue-by-issue loop. One bounded review pass, a consolidated defect list, one repair pass, and one final verification would have satisfied it. Codex failed to choose that shape.

Why this is a product failure as well as an agent judgment failure

The model made poor orchestration decisions. That should be stated plainly. It spawned too much work, passed too much history, failed to consolidate review findings, and continued after the burn rate was obvious.

The product still needs to prevent this class of failure. Codex is sold for autonomous, tool-using development. A user cannot inspect every hidden response boundary, cached-context replay, or subagent reactivation while a task runs. The application knew the context size, response count, descendant-agent structure, and usage-meter trajectory, but it did not warn or stop.

There was no:

• task-wide token, response, or quota budget;
• live aggregate covering the coordinator and every descendant agent;
• projection such as “this task has used about 8% of your weekly allowance”;
• warning that hundreds of responses were repeatedly carrying more than 100,000 cached tokens;
• cap on reviewer/implementer follow-up cycles;
• compact-context default for new subagents;
• automatic checkpoint and stop when usage became disproportionate to progress;
• requirement for a reviewer to consolidate findings before another implementation pass.

Accounting method

The totals were produced from local Codex rollout telemetry using a read-only scan:

1. Select the incident UTC window.
2. Include the root Codex thread and all descendant/reused subagent threads involved in the task.
3. Read per-response token_usage_record values.
4. Deduplicate globally by (thread_id, response_id).
5. Sum input_tokens, cached_input_tokens, output_tokens, and total_tokens.
6. Compute uncached input as input_tokens - cached_input_tokens.
7. Do not add reasoning_output_tokens to output because it is a subset of output.

One important observability defect surfaced here: an ordinary root-turn report can omit usage from a reused subagent when later follow-ups remain attributed to that agent's original root_turn_id. A correct task-wide report required scanning across root-turn boundaries and deduplicating all participating threads. The product should do this automatically.

Raw logs are not attached because they contain private prompts, file paths, screenshots, and tool output. A redacted aggregate is available, and a sanitized analysis script/output can be provided privately to maintainers.

Reproduction pattern

This is a workload-shape reproduction rather than a minimal deterministic test:

1. Start a long-running Codex Desktop conversation with a large inherited context.
2. Ask for a substantial implementation and independent review.
3. Spawn several subagents using default/full inherited history rather than compact task briefs.
4. Keep the same agents alive through many followup_task cycles.
5. Let a reviewer return findings serially instead of in one consolidated pass.
6. Run tool-heavy work with many small shell, test, wait, and status boundaries.
7. Inspect per-response token_usage_record data after context exceeds 100,000 tokens.
8. Observe hundreds of responses with roughly 100,000–200,000 mostly cached input tokens and comparatively tiny outputs.
9. Observe the account usage meter fall without a task-level warning or stop.

Expected behavior

• A task should expose one live usage total that includes the coordinator and all descendant or reused agents.
• Subagents should default to a compact, purpose-built brief. Full conversation inheritance should be explicit and visibly priced.
• Users should be able to set a maximum task budget by weekly-quota percentage, weighted tokens, model responses, and wall time.
• Codex should pause and request confirmation at the budget boundary while preserving task state.
• The UI should warn when a task enters a pathological pattern, such as many consecutive responses with more than 100,000 cached input tokens and less than 1,000 output tokens.
• Pure wait/poll operations should avoid a fresh model inference where the architecture permits.
• Review agents should return a consolidated report by default. Repeated reviewer/implementer cycles should have a small default cap.
• Usage reporting should distinguish cached input, uncached input, output, and estimated quota impact.
• Automatic compaction or checkpoint/handoff should occur before the context becomes expensive enough to consume a material part of the weekly allowance.

Actual behavior

• One bounded task produced 1,545 model responses in under three hours.
• The task processed 242.3 million tokens, 237.2 million of them cached input.
• Average input was about 156,500 tokens per response.
• The account's weekly usage meter rose by 11 percentage points during the incident.
• No task-wide warning, limit, approval boundary, or automatic stop occurred.
• The default reporting path did not naturally show all usage from reused agents across root-turn boundaries.
• Work continued even after repeated usage checks demonstrated rapid quota loss.

Requested fixes / acceptance criteria

1. Task-wide accounting: The displayed total includes the root task, all descendants, and later follow-ups to reused agents, regardless of root_turn_id ownership.
2. User-set hard budgets: A user can cap weekly-quota percentage, effective tokens, responses, and wall time for a task.
3. Automatic circuit breaker: Codex pauses before exceeding that budget and preserves a resumable checkpoint.
4. Safe context defaults: Subagents receive a compact task brief by default; full-history inheritance requires explicit selection.
5. Pathology warning: Codex detects repeated high-context/low-output turns and warns before material quota loss.
6. Low-cost waiting: Deterministic waits and status polling do not require repeated full-context model calls.
7. Bounded review loops: Independent review is consolidated, with a visible and configurable pass limit.
8. Clear live telemetry: The UI shows cached input, uncached input, output, descendant-agent usage, current task share of weekly usage, and projected remaining cost.
9. Cross-turn correctness: Usage remains attributable to the active user task even when a long-lived subagent is reactivated from a later root turn.
10. Regression test: A multi-agent tool-heavy test with a large starting context must stop or warn before a configured task budget is exceeded.

Final note

I am not alleging that cached input was billed as uncached input or that raw local token totals map directly to subscription accounting. The account meter and local telemetry are different measurements. The concrete failure is that Codex generated an enormous volume of repeated context processing, the weekly meter moved sharply during the same bounded incident, and the product offered no practical way to see, budget, or stop it before the damage was done.

No repository files, tests, or code entry points are named. Start by locating task-wide usage accounting and subagent follow-up orchestration, then compare them with the reported reproduction and acceptance criteria. Done means the task aggregates descendant usage, supports budgets and circuit breaking, and exposes the requested warnings and reporting.