Single Terra Medium task reprocessed 10.1M input tokens (98% cached) across 76 exec turns and consumed 33% of 5-hour quota

What issue are you seeing?

I am seeing extreme 5-hour quota depletion during ordinary single-agent Codex work, accompanied by repeated re-processing of a very large, mostly cached conversation context across sequential model/tool continuations.

I audited the local rollout JSONL for a clean reproduction and can quantify the behavior precisely.

Primary reproduction

Environment:

• Subscription: ChatGPT Plus
• Platform: Windows
• Model: gpt-5.6-terra
• Reasoning effort: medium
• Multi-agent: not used
• Security review workflow: not used
• Context compactions: 0
• Rollout/thread: 01a043a6-51d7-7fb3-b01a-0b339e4bbbed
• Active window: 2026-08-28 09:47:34Z -> 10:05:23Z

The 5-hour usage window was fresh at the start of the task and local token_count telemetry reported primary.used_percent = 0.0 before activity.

After one normal maintainer follow-up task:

Metric	Observed
User tasks	1
Wall time	17m 49s
5-hour quota	0% -> 33%
Cumulative input delta	10,118,557 tokens
Cached input delta	9,950,208 tokens
Cached share	~98.3%
Token/usage updates	77
exec tool calls	76
Total captured exec output	~348,056 characters
Compactions	0
Exact repeated commands	2

The user prompt itself was only about 3.2k characters. It was a scoped six-item maintainer follow-up involving tests, coverage, API/chart consistency, i18n/plural handling, and a man-page correction. It was not a repository-wide rewrite or unusually large prompt.

The rollout shows a long sequence of model/tool continuations over an increasingly large retained context. Early tool calls read several source/test/template/locale/man-page files, some producing ~20k-45k characters each. Subsequent turns applied patches, inspected diffs, ran tests/coverage checks, and continued from the same accumulated history.

The important observation is not that any one tool output was enormous. Rather, the retained history was repeatedly reprocessed across many sequential continuations, producing more than 10M cumulative input tokens in under 18 minutes even though the amount of newly returned tool material was much smaller.

Why this seems worth investigating

The pattern is approximately:

model turn
  -> exec/tool result
model turn with retained history
  -> exec/tool result
model turn with larger retained history
  -> ...

Across dozens of continuations, the same large prefix is repeatedly processed and is overwhelmingly reported as cached input.

This makes ordinary tool-heavy work behave like a multiplier:

large retained context x many model/tool continuations

The resulting 5-hour quota impact is disproportionate to the visible task duration and useful work performed.

Secondary reproduction

Immediately afterward, a second independent rollout showed the same broader behavior:

• rollout/thread: 019ffa05-002a-7661-b60f-7a5a51ef9046
• model: gpt-5.6-terra
• reasoning: medium
• ~70 minutes
• 8 user tasks
• +20,319,848 input tokens
• +19,715,584 cached input tokens
• 5-hour quota continued from ~33% to 96%
• 4 compaction records corresponding to 2 logical compactions
• model input contexts repeatedly around ~80k-238k tokens

The compactions in this second rollout appear to work mechanically: context dropped from roughly ~237k to ~82k after the first compaction, and from roughly ~220k to ~83k after the second. For that reason I am not claiming that compaction itself is broken.

This secondary case also included a security-review workflow, so I am not using it as the primary reproduction. The first reproduction is cleaner because it reaches 33% quota consumption without security review, multi-agent, or compaction.

What I ruled out in the primary reproduction

The primary reproduction does not require:

• multi-agent fan-out;
• Guardian/review-agent activity;
• a security scan workflow;
• context compaction;
• an obvious infinite retry loop;
• a huge user prompt;
• repeated execution of the exact same shell command.

Only two exact shell commands were repeated across 76 exec calls.

What this evidence does not establish

I do not want to overstate the diagnosis. This evidence does not establish:

• that cached tokens are being billed or weighted incorrectly;
• that 77 token_count updates are exactly 77 HTTP/API requests;
• that the quota meter itself is arithmetically wrong;
• that context compaction is broken;
• that Guardian or multi-agent is involved.

What the local rollout does establish is that an ordinary single-agent Terra Medium task repeatedly processed a very large, mostly cached context across many sequential tool/model continuations, accumulating 10.1M input tokens and consuming 33% of the 5-hour allowance in under 18 minutes.

Whether the unusually large quota impact is caused by client-side context/tool-loop behavior, server-side cached-input/rate-limit weighting, or a combination of both requires server-side investigation.

Expected behavior

A normal single-agent task should not consume one third of the entire 5-hour Plus allowance in under 18 minutes unless there is correspondingly extreme useful model work.

Codex should avoid repeatedly reprocessing large historical tool outputs and patches when they no longer need to remain verbatim in model-visible context. Possible client-side mitigation areas include:

• bounded cumulative budget for older tool outputs, not only per-output truncation;
• summarizing or projecting older large tool outputs while preserving full rollout/audit history;
• earlier context pruning when growth is dominated by retained tool results;
• reducing unnecessary model re-entry between sequential tool operations;
• surfacing per-task usage attribution so users can see model turns, input/cached input, compactions, retries, and quota charged.

Server-side investigation should also confirm how cached input is currently weighted against the 5-hour subscription bucket and whether that weighting changed recently.

Related reports

This appears related to, but is not identical to:

• #40880 - unusually rapid 5-hour depletion, including a Terra Medium example
• #40897 - repeated cached-context replay associated with nested exec/output truncation
• #41220 - meta tracker, especially class D: workflow amplification / cached-context replay

The main difference in this report is that the clean reproduction above does not require multi-agent, Guardian, a security review, context compaction, or an obvious repeated-command loop.

I can provide sanitized rollout excerpts and the analysis scripts used to derive the per-task/tool-call totals if useful.

Start with the local rollout JSONL for thread 01a043a6-51d7-7fb3-b01a-0b339e4bbbed and the token_count telemetry described in the report; compare the 77 updates with the 76 exec calls and retained context sizes. No source files or tests are named, so first locate the context/tool-loop and quota-attribution entry points. Done means identifying whether client-side replay, server-side weighting, or both cause the disproportionate usage, with a reproducible test or trace.