Repository navigation
GPT-5.6 Sol Max can exhaust the entire 5-hour Plus quota after one ~15k+ character prompt #41518
Description
What version of Codex CLI is running?
0.150.1
What subscription do you have?
ChatGPT Plus
Which model were you using?
GPT-5.6 Sol, reasoning max
What issue are you seeing?
A single long, structured Codex prompt of roughly 15k+ characters can consume the entire 5-hour Plus usage window in one turn.
This has happened during normal repository work where the prompt is detailed because it contains safety constraints, branch/worktree checks, implementation scope, regression requirements, and verification steps. The prompt itself is long, but it is still one bounded engineering task.
Observed pattern:
- 5-hour quota resets and is available.
- Start a fresh Codex turn using GPT-5.6 Sol with Max reasoning.
- Submit one structured prompt above roughly 15k characters.
- Codex performs the task or begins working on it.
- The 5-hour usage allowance is exhausted after that single turn, even while substantial weekly allowance remains.
- Further work must wait for the 5-hour reset, forcing the same task to be reconstructed/resumed later.
The practical effect is that one detailed prompt can make Codex unavailable for the remainder of the rolling window. This is especially disruptive for complex but controlled engineering workflows where long prompts are used to reduce ambiguity and prevent unsafe repository actions.
I have observed this more than once. The issue appears strongly correlated with long prompt/context size on GPT-5.6 Sol Max rather than simply wall-clock duration.
I am intentionally not posting private repository names, session IDs, or conversation contents publicly. I can provide private diagnostic/session information to OpenAI if requested.
What steps can reproduce the bug?
- Use Codex CLI
0.150.1on a ChatGPT Plus account. - Select GPT-5.6 Sol with Max reasoning.
- Start with a fresh 5-hour allowance.
- Submit a single detailed engineering prompt of around 15k+ characters containing repository checks, scope constraints, implementation requirements, tests, and final reporting instructions.
- Let the turn run normally.
- Check Codex usage afterward.
- Observe the 5-hour allowance depleted or effectively exhausted after the single turn while weekly usage still has substantial remaining capacity.
What is the expected behavior?
A single detailed prompt should not consume the entire 5-hour subscription window unless the underlying compute genuinely warrants that amount, and the product should make that consumption understandable before or immediately after the task.
If long prompt/context size materially changes quota consumption, Codex should ideally provide:
- per-turn usage attribution;
- input/cached-input/output/reasoning token visibility;
- the percentage of the 5-hour allowance consumed by that turn;
- a warning when a submitted task is likely to consume most or all of the current 5-hour allowance;
- clearer documentation of how long input context and Max reasoning are weighted against the rolling quota.
Additional information
This appears related to other recent reports of GPT-5.6 Sol rapidly consuming 5-hour quota, but this report is specifically about a repeatable single-prompt trigger: one structured prompt above roughly 15k characters exhausting the 5-hour window.
The workflow does not require a public repository, production deployment, or unusually large generated artifact to reproduce.
Activity
github-actions commentedon Aug 29, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
kamo-k commentedon Aug 29, 2026
Additional reproducible evidence from Codex CLI
0.151.0on ChatGPT Plus, GPT-5.6 Sol, reasoningmax.This occurred in a resumed independent review session doing bounded local repository/browser verification. No Production access or real database work was involved.
Observed status near the end of the session:
The session had already consumed roughly 73% of the entire 5-hour allowance while the weekly bucket still had substantial capacity left. The work was review/testing rather than a large implementation or artifact-generation task.
This reinforces the original report: large retained context + repeated tool/model continuations on GPT-5.6 Sol Max can make a single bounded engineering/review session consume most of the 5-hour Plus window.
The user-visible impact is severe because the short-window bucket becomes the gating constraint even when weekly usage remains available. In practice this forces engineering work into quota-reset-sized fragments and makes independent verification/review disproportionately expensive.
Please investigate whether the dominant driver is repeated cached-context replay / retained-context processing across tool turns, model weighting, or short-window accounting. Per-turn attribution would be especially valuable here: input tokens, cached input, output/reasoning, number of model continuations/tool turns, and exact 5-hour percentage charged.
I am omitting private repository details and the session identifier from this public comment, but can provide private diagnostic/session data to OpenAI if requested.
kamo-k commentedon Aug 30, 2026
Additional reproduction on 2026-08-30: the 5-hour Codex window was exhausted again during a bounded verification session, not a large feature implementation.
Context:
Observed depletion:
This is now materially affecting the ability to do meaningful engineering work. A single serious verification/review cycle can consume most or all of the rolling 5-hour window, even when the task is primarily testing and inspection rather than implementation. At this rate, building and independently verifying a non-trivial application becomes impractical on Plus because a normal engineering loop (implement -> test -> browser QA -> review -> fix -> reverify) cannot reliably fit inside the available window.
This reproduction also suggests the issue is not simply one oversized prompt. The workload involved many relatively small commands/actions and retained context across the session. Please investigate whether retained-context replay, cached-input accounting, tool/browser interactions, reasoning-level weighting, or per-turn context reprocessing is causing disproportionate 5-hour quota consumption.
It would be extremely useful to expose per-turn/token-equivalent quota attribution in /status so users can see exactly which turns or tool phases consumed the window. At minimum, there should be a way to distinguish new input/output from cached/replayed context and tool execution costs.
This is the third concrete reproduction I have now observed on the same project workflow, and it is blocking substantive development rather than merely reducing convenience.
kamo-k commentedon Aug 31, 2026
Additional reproducible quota evidence from 31 Aug 2026:
A single bounded implementation prompt for a shared auth/session security primitive consumed approximately 80% of the Plus 5-hour Codex limit.
Work completed in that one prompt was substantial but still a normal bounded engineering phase, not an entire feature/project:
Result: roughly 80% of the rolling 5-hour allowance was consumed by one prompt. Across the recent runs in this issue, the practical throughput is now around 1–1.5 substantive prompts per 5-hour window, which is not sustainable for real software engineering where a normal loop requires implementation, review, browser QA, fixes, and independent verification.
This reinforces the earlier suspicion that retained-context replay / cached-input processing / tool-call accounting / reasoning-weighting may be consuming quota far faster than users can reasonably predict from prompt size alone.
Please investigate and, ideally, expose per-turn quota attribution showing at least: input tokens, cached/replayed input, reasoning tokens, output tokens, tool-call costs, and the exact percentage charged to the 5-hour limit for each turn. Without this, it is extremely difficult to plan or control Codex usage on Plus.
MokuaDB commentedon Sep 4, 2026
GPT-5.6 Sol / Codex CLI 0.153.0 rapidly depletes Plus 5-hour and weekly limits during normal repository work
Codex CLI version
0.153.0
Subscription
ChatGPT Plus
Model
GPT-5.6 Sol, reasoning max
Environment
Fedora Linux
Problem
I am seeing reproducible, unusually rapid depletion of both the rolling
5-hour Codex allowance and the weekly allowance during normal repository
engineering work.
After a natural 5-hour reset, local Codex telemetry recorded:
UTC 5h used Weekly Cumulative Input Cached Output Reasoning
used total input
06:19:02 0% 32% 2,464,688 2,421,341 2,207,744 43,347 12,864
06:21:59 22% 35% 4,916,175 4,865,251 4,627,456 50,924 15,985
06:29:08 39% 38% 6,970,323 6,913,237 6,534,016 57,086 18,041
So the 5-hour allowance moved from 0% used to 22% used in under three
minutes, and to 39% used in about ten minutes. The weekly allowance
moved from 32% to 38% used in the same interval.
The local JSONL telemetry records the same server-reported
primary.used_percent and secondary.used_percent progression shown by
/status.
This reproduces with reasoning=max, so xhigh is not required to
trigger the behavior.
At the final sample, cached input was about 94.5% of input, so this does
not appear to be a simple cache-collapse case. The visible cumulative
reasoning-output counter was also small relative to input.
Historical comparison
On the same account, historical GPT-5.6 Sol / max repository sessions
on 2026-08-29 showed substantially more logged token throughput per
percentage point of the 5-hour allowance:
CLI 0.150.1: about 3.55M logged session tokens while the 5-hour
meter increased by 17 percentage points (~209K logged tokens /
point).
CLI 0.151.0: about 5.34M logged session tokens while the 5-hour
meter increased by roughly 24 percentage points (~222K logged
tokens / point).
I understand that Codex subscription limits are not documented as a
simple token-to-percentage conversion, so these figures are only
observational comparisons from the same account.
Steps to reproduce
Use ChatGPT Plus with Codex CLI 0.153.0.
Select GPT-5.6 Sol with reasoning max.
Start after a natural 5-hour allowance reset.
Perform normal repository engineering work.
Check /status and local JSONL rate-limit telemetry during the
turn.
Observe rapid increases in both the 5-hour and weekly used_percent
values.
Expected behavior
Normal repository work should not unexpectedly consume a large fraction
of the 5-hour and weekly allowances within minutes without clear
attribution. If this is intended weighting, the client should expose
enough per-turn usage information to explain it.
Additional information
This appears related to #41518:
#41518
I am intentionally not posting account email, private repository names,
prompts, source code, or session IDs publicly. I can provide private
diagnostic/session information to OpenAI if requested.