Repository navigation
Single Terra Medium task reprocessed 10.1M input tokens (98% cached) across 76 exec turns and consumed 33% of 5-hour quota #41369
Description
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_countupdates 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:
- Codex 5-hour usage limit is being consumed significantly faster since reintroduction #40880 - unusually rapid 5-hour depletion, including a Terra Medium example
- [Bug] Code Mode nested exec output truncation causes repeated context growth and extreme cached-token quota consumption #40897 - repeated cached-context replay associated with nested exec/output truncation
- [Meta] Abnormal Codex usage/quota depletion and usage-accounting inconsistencies — cross-report tracker #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.
Activity
github-actions commentedon Aug 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
larryllr commentedon Aug 29, 2026
I reviewed the duplicate warning and closed the companion issue #41450 as a
duplicate. Your Terra Medium report and our Code Mode/Sol report share the same
large-context × repeated-outer-continuation amplification family.
The unique controlled mitigation evidence is now retained in the canonical
Code Mode tracker #35050:
with the official unmodified
0.150.0-alpha.12.2client and the same 180Kcontext/50-check fixture, the serial plan used 60 cycles and
11,100,973logical input, while the supported scheduling instruction used 15 cycles and
2,041,915input (81.606%lower), with 86 nested calls, 50/50 coverage, andzero errors in both repeated treatment runs.
That evidence isolates a zero-retry, zero-fallback Code Mode scheduling
amplifier; it does not claim that cached input is a wire or billing bug. The
reference description-only change is available at
larryllr/codex@23dfc40.
AcTePuKc commentedon Aug 29, 2026
@larryllr Thanks, this is very useful. Your controlled A/B results make the cycle-count amplification explanation much stronger than I could establish from my observational reproduction alone.
The interesting part to me is that my clean Terra Medium case reached essentially the same scale without Code Mode, Guardian, compaction, multi-agent, or a retry storm, so the common mechanism may be broader than Code Mode scheduling itself.
I'll keep an eye on whether I can reproduce it again from a completely fresh local install/session.
fi11235813 commentedon Aug 29, 2026
I’m seeing what appears to be the same symptom family on ChatGPT Plus / Windows, with GPT-5.6 Sol xHigh.
One normal continuation of an existing development task ran for ~51 minutes and consumed about 84% of the 5-hour allowance.
Local rollout analysis for that interval:
172 token-usage events
23,103,657 input tokens
22,622,464 cached input tokens
~97.9% of input was cached
64,622 output tokens
18,842 reasoning output tokens
Entire session totals at the time of inspection:
30,398,418 input
29,616,384 cached input
101,632 output
28,864 reasoning output
30,500,050 total tokens
There were only 2 context compactions in the entire multi-hour session, ~214.7 minutes apart, so this does not appear to be a compaction loop.
Individual model continuations repeatedly carried roughly 200k+ input tokens, almost entirely cached.
Important timeline detail: the abnormal quota depletion first occurred before I manually updated Codex CLI to 0.151.0. It then reproduced again after the update, while the new ChatGPT Windows UI was closed.
Historically, with the same general workflow, I could run Codex for several hours, including High, xHigh, and Max reasoning, without getting close to the 5-hour limit.
The concern is not the absolute quota size. The current quota had already been in place before this issue appeared. The abnormal depletion started abruptly today: comparable development work that previously ran for hours began consuming most of the 5-hour allowance in under an hour.
This suggests a recent regression or server-side change rather than the existing quota simply being too small.
This looks consistent with the large-context × repeated-continuation amplification described here, but I can’t tell from the client side whether the root cause is increased model re-entry, changed cached-input weighting against quota, or another server-side regression.
Blooshoo commentedon Aug 29, 2026
Independent reproduction on Linux / GPT-5.6 Sol (written by sol because honestly too busy and tired today to be lucid)
I found this issue after seeing the same general behavior with Sol. I audited the local rollout JSONL rather than estimating from the UI.
Subscription: ChatGPT Plus
Platform: Linux
Model: GPT-5.6 Sol (medium)
Single rollout / single user task
Multi-agent: no
Compactions: 0
Requests over 272K input: 0
A quota reset occurred during the rollout. Local token_count telemetry went from 12% used to 0% used at 14:26:26, giving me a clean fresh-window measurement.
From that reset until Codex stopped for the rate limit:
Wall time: 28m 42s
5-hour quota: 0% → 100%
Weekly quota: 0% → 16%
Model requests: ~132
exec calls: 126
Input tokens: 14,020,698
Cached input: 13,625,472
Cached share: 97.18%
Uncached input: 395,226
Output tokens: 34,505
Reasoning output: 10,018
Max request input: 226,351
Compactions: 0
The 5-hour meter rose progressively throughout the tool/model loop rather than in one unexplained jump: approximately 21% used at 4.19M cumulative raw tokens, 49% at 8.42M, 75% at 10.67M, 90% at 12.42M, and 100% at 14.06M.
The task itself was ordinary repo maintenance, not an autonomous long-running workload. The execution pattern was highly iterative: 126 exec calls across ~132 model requests, while a large mostly-cached context was repeatedly processed.
This looks very similar to the Terra reproduction in this issue, despite being a different model and OS. I have retained the original rollout locally and can provide sanitized analysis/output if useful.
tbook commentedon Sep 1, 2026
Independent reproduction on macOS / ChatGPT Plus / Codex CLI 0.149.1 / GPT-5.6 Sol (reasoning low).
I hit the 5-hour limit after only ~30 minutes of ordinary development work this morning, despite having used Codex heavily the previous day without this problem. I inspected the local rollout JSONL to understand where the quota went.
The clearest single-session interval was an Android development task (normal visible agent work; no hidden/background worker):
Near the end of the interval, individual continuations were repeatedly carrying ~200K+ tokens of input while producing very small outputs. The final recorded request was:
The execution pattern was a long sequence of normal incremental coding operations (patch → inspect/test → patch → inspect/test), but each small continuation reprocessed almost the entire large context. The quota meter climbed progressively with those continuations rather than jumping inexplicably.
I was intentionally running a second small Codex task concurrently for part of this period, but the main session alone accounts for the large majority of the abnormal depletion above. The second task showed the same amplification pattern as its context grew: 43 token-count events, 37 exec calls, ~3.07M input tokens, ~2.89M cached input, and later continuations around ~99K input for only a few hundred output tokens.
The important practical comparison is that this is a sudden change in usability for me: yesterday I worked with Codex for much of the day and got substantial work done while consuming only the remainder of the same general allowance. Today a few modest tasks over roughly half an hour exhausted the 5-hour window. I have a banked reset available but am reluctant to use it while this behavior persists, since the current large-context repeated-continuation pattern can consume the entire window very quickly.
This looks very consistent with the large-context × repeated-continuation amplification described in this issue, and not with the separate background-memory-worker runaway reports.
NixZ-lab commentedon Sep 3, 2026
I can independently reproduce a very similar pattern on ChatGPT Plus / Windows with gpt-5.6-terra, reasoning_effort=medium.
I analyzed my local Codex rollout JSONL and segmented the data strictly by continuous Terra Medium runs to avoid mixing model or reasoning-effort changes.
Across multiple independent sessions:
Aug 28: ~16.56M locally recorded total_token_usage across Terra Medium segments, corresponding to ~68 percentage points of cumulative 5-hour quota movement (~0.244M tokens per percentage point).
Sep 2: ~27.38M tokens / ~103 cumulative percentage points (~0.266M per point).
Sep 3: ~32.75M tokens / ~109 cumulative percentage points (~0.300M per point).
Individual Sep 2/3 examples:
2.012M tokens, 93.4% cached → +8 pp 5-hour quota
3.575M tokens, 97.4% cached → +12 pp
7.381M tokens, 95.6% cached → +30 pp
8.032M tokens, 95.9% cached → +25 pp
This corresponds to roughly 3.3–4.1 percentage points of 5-hour quota per 1M locally recorded total_token_usage across a fairly large sample, with cache ratios commonly above 90–97%.
I am not claiming that local token counts should map linearly to subscription quota, and after correcting my analysis for model switches I do not have a sufficiently clean pre-change baseline to claim a specific regression multiplier.
However, the current Terra Medium behavior appears very consistent with the high cached-context replay / quota consumption reported here and also with the affected session in #41957.
If useful, I can provide sanitized session IDs, reset timestamps, runtime versions, and the PowerShell extraction script for server-side correlation. I would also be interested to know whether this level of 5-hour quota consumption for heavily cached Terra Medium sessions is considered expected.
axisrow commentedon Sep 14, 2026
+1 — I independently reproduced the same amplification family (Plus / macOS / 0.154.0), and I can add a measurement none of the reports above have: per-model quota density, computed from a month of my local rollout JSONLs (Sep 1-14, ~170 sessions, 3,759
token_count/rate_limitssnapshots; density = Δtotal_token_usage/ Δused_percentover consecutive snapshots where the integer percent actually moved).Median tokens per percentage point of the 5h window, by model:
Two observations relevant to this issue:
Meter lag creates "invisible burn". For luna, the mean density (18K/pt) is ~3.5x lower than the median (63K/pt) — the integer
used_percentstalls while tokens accumulate, then catches up in jumps. In my worst session (Sep 14) the rollout recorded 21% -> 47% (+26 pts on 2.74M input, ~90% cached, 28 sequential continuations, one turn, 8.5 min) while the live UI simultaneously cascadedless than 50% -> 25% -> 10% -> 5%of remaining allowance. Two accounting traces from the same turn, diverging by tens of points.Quota weight does not track model pricing. My Sep 14 worker burned quota at ~105K tokens/pt on luna — my densest day of the month, versus my month-wide luna median of 63K/pt. Whatever weighting maps cached-input re-processing into the 5h bucket, it's not the same scale as the model price list, which strengthens the case that this needs server-side weighting investigation (your "What this evidence does not establish" point).
This matches the mechanism in the issue body: large retained context x many model/tool continuations, ~90-98% cached input, compaction not involved.
NixZ-lab commentedon Sep 14, 2026
@axisrow I reran my local data using the moved-snapshot method you described, and I think I found an important quantization/lag effect that may explain much of the apparent difference between our Terra numbers.
Across 641 Terra Medium moved-percent observations on my account:
median: 137.3K tokens / percentage point
mean: 134.4K/pt
Q25–Q75: 87.2K–182.3K/pt
But splitting by the size of the used_percent movement changes the picture substantially:
DeltaPct = 1: n=629, median 139.7K/pt, mean 136.2K/pt
DeltaPct = 2 or 3: n=12, median 37.0K/pt, mean 38.8K/pt
The latter is almost exactly your reported 35–38K/pt Terra figure.
For example, one of my snapshots recorded ~74.5K additional tokens while used_percent moved 29 → 31. The moved-snapshot calculation therefore produces 74.5K / 2 = 37.3K/pt.
This makes me think the moved-snapshot density is strongly affected by integer quantization and meter lag. If used_percent stalls across several token-count snapshots and then catches up by 2–3 points, the earlier token growth is discarded while the final request delta is divided by the multi-point jump.
That also explains why this metric differs substantially from my continuous-segment measurement (~0.24–0.30M tokens/pt), which includes all token growth between the beginning and end of a stable Terra Medium segment.
So I don't think we can yet interpret the apparent ~7x difference as different server-side weighting between accounts.
Could you check the DeltaPct distribution behind your Terra n=23 sample, and also calculate total Δtotal_token_usage / Δused_percent across longer continuous Terra runs within the same 5h reset window? That should tell us whether the difference survives quantization/meter-lag effects.
axisrow commentedon Sep 14, 2026
@NixZ-lab but I used Luna, not Terra
NixZ-lab commentedon Sep 14, 2026
@axisrow Yes, I know your Sep 14 worker example was Luna. I was referring specifically to the gpt-5.6-terra row in your table, where you reported 35–38K tokens/pt (n=23) and compared it with my ~0.24–0.27M/pt Terra measurements.
My question is about those 23 Terra observations: what does their DeltaPct distribution look like? In my data, the ~37K/pt values appear almost exclusively when used_percent jumps by 2–3 points at once, which suggests quantization/meter-lag bias in the moved-snapshot metric.
axisrow commentedon Sep 14, 2026
@NixZ-lab here's the DeltaPct distribution behind that row:
So the low density figure came almost entirely from DeltaPct=1 observations, not from the "stall then jump 2-3" pattern in your split — opposite of what your quantization mechanism would predict. Your critique still convinced me on the second check though: segment method (first->last snapshot per run) on the same sample gives 30-156K/pt, with the two longest segments (0.31M tokens / 2 pts -> 156K/pt, 0.61M / 4 pts -> 153K/pt) drifting toward your ~0.24-0.30M/pt calibration. One segment was excluded because used_percent dropped 8 points mid-file — a window reset inside the session. Sample too small and too noisy; I retract the "~7x different weighting" reading.
Two caveats that stand regardless: (1) my sessions share one account-level 5h window and I run parallel workers, so ΔPct in one rollout includes quota burned by other concurrent sessions/surfaces — not controllable from local rollouts alone; (2) the Sep 14 luna worker case still stands: rollout telemetry recorded 21% -> 47% (+26 pts, ~105K/pt) while the live UI cascaded past <25%/<10%/<5% of remaining allowance within the same 8.5-minute turn.