Repository navigation
Pro account: 5-hour usage bucket disappeared from Codex App and account/rateLimits/read #32707
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.8168.0
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
The 5-hour usage row disappeared from the Codex App Usage dialog. The dialog now shows only the weekly usage limit and a Full reset credit.
The local app-server data changed at the same time: the 300-minute bucket is no longer returned. The weekly 10,080-minute bucket is returned as primary, while secondary is null.
Sanitized snapshots from the same running Codex task:
Before, at 2026-07-12 22:11:55 UTC:
{
"primary": {
"usedPercent": 74,
"windowDurationMins": 300
},
"secondary": {
"usedPercent": 16,
"windowDurationMins": 10080
}
}After, at 2026-07-12 22:15:43 UTC:
{
"primary": {
"usedPercent": 16,
"windowDurationMins": 10080
},
"secondary": null
}A current read still has the weekly bucket only:
{
"planType": "pro",
"rateLimitReachedType": null,
"primary": {
"usedPercent": 22,
"windowDurationMins": 10080
},
"secondary": null
}The change occurred approximately four hours before the local Codex App package was updated, so it does not appear to have been introduced by that local package update.
I cannot determine from this evidence whether enforcement of the 5-hour window also changed. This report is specifically about the missing 300-minute bucket and the resulting loss of visibility.
The current official Codex pricing documentation still describes a shared 5-hour usage window plus additional weekly limits:
https://developers.openai.com/codex/pricing
What steps can reproduce the bug?
- Sign in to Codex App with a ChatGPT Pro account.
- Open the Usage dialog.
- Observe that only the weekly limit is displayed; the 5-hour row is absent.
- Start
codex app-server, initialize the JSON-RPC session, and callaccount/rateLimits/read. - Observe that the only Codex usage bucket has
windowDurationMins: 10080andsecondaryisnull; no 300-minute bucket is present. - Restart Codex App and repeat the check. The 5-hour row remains absent.
No usage reset was consumed to test this, and no account or configuration changes were made.
What is the expected behavior?
If the documented 5-hour window still applies, both usage buckets should be returned and displayed:
- 300-minute / 5-hour usage
- 10,080-minute / weekly usage
If this was an intentional product change, the Usage dialog, app-server contract, and official pricing documentation should consistently explain the replacement behavior.
Additional information
I searched open and closed issues before filing.
Related, but not exact duplicates:
- The 5-hour allowance and the total weekly quota have inexplicably disappeared!------[reply] #32493 reports quota percentages dropping without activity; its buckets remain visible.
- Codex Desktop shows “You're out of Codex messages” despite 99% usage remaining #24445 reports both buckets being
nullon a Business plan and an incorrect out-of-messages banner. - Expose rate-limit reset times, balance, plan as status_line tokens #24080 confirms the prior
account/rateLimits/readshape with 300-minute primary and 10,080-minute secondary buckets.
Question: was the 300-minute bucket intentionally removed for Pro accounts, or is this a backend/app-server regression?
Activity
github-actions commentedon Jul 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Lady-Lin commentedon Jul 13, 2026
OpenAI has removed the 5-hour limit; this is not a bug. Closing this now.
daddy32 commentedon Jul 13, 2026
The issue is stil open; also thia statement is still contradictory with the official documentation.
topemalheiro commentedon Jul 17, 2026
What are they thinking???
Killka84 commentedon Jul 17, 2026
It appears that when the five-hour limit was removed, the quota size itself was not recalculated.
The same amount of usage that was previously available every five hours now appears to be allocated for an entire week.
In other words, it looks as if only the reset period was changed from 5 hours to 7 days, while the actual quota amount remained approximately the same.
If this is intentional, then this is not a removal of the limit. It is a major reduction in available usage, because the same quota that previously renewed several times per day now renews only once per week.
Please investigate whether the weekly quota was mistakenly configured using the former five-hour quota value.
fordicus commentedon Jul 20, 2026
I am observing a very similar pattern.
Since the 5-hour window disappeared and only the 7-day limit is shown, my weekly quota appears to be depleting at an extremely fast rate compared with previous usage patterns. This makes @Killka84's hypothesis highly worth investigating: it does look possible that the reset window changed from 5 hours to 7 days while the actual quota size was not recalculated accordingly.
If that is the case, this would effectively be a major reduction in usable Codex capacity rather than a simple removal or hiding of the 5-hour limit.
Could the Codex team please confirm whether the weekly quota was recalculated after the 5-hour bucket disappeared, and respond directly to this point?
Lady-Lin commentedon Jul 20, 2026
BCZ The cost of calling large models will soon become cheaper than water.
yukinaga-yoshida commentedon Jul 31, 2026
Please expose the 5-hour and weekly rate-limit reset times in the built-in Codex CLI statusline.
Requested display:
5h 82% left · 22:14
wk 97% left · 0803 09:00
On Codex CLI 0.146.0, account/rateLimits/read currently returns only the weekly 10080-minute window for my account, so the 5-hour window cannot be displayed
even though the pricing documentation describes it.
Please either:
The current behavior makes it impossible to tell when the 5-hour limit resets.
Record the 2026-08-02 re-verification of all three providers
ericknyoto commentedon Aug 10, 2026
I’m seeing the same behavior on a ChatGPT Plus account.
In Settings → Usage, only the Weekly usage limit is shown. There is no 5-hour meter or 5-hour reset information.
I also checked directly from Codex CLI v0.147.0 using /status, and it shows only:
Weekly limit: 5% left (resets 12:07 on 16 Aug)
There is no 5-hour remaining allowance or reset shown there either.
I contacted OpenAI Support and they confirmed that the public Codex documentation still describes a shared rolling 5-hour window for local messages + cloud chats, with additional weekly limits potentially applying. However, they could not confirm whether the 5-hour window is actually enforced on my specific account when neither /status nor the Usage dashboard exposes it.
So in my case, both documented user-facing rate-limit surfaces currently expose weekly usage only.
This makes it difficult to tell whether:
the 5-hour window is still active but hidden,
the account has been provisioned with weekly-only limits,
or this is a UI/entitlement/rate-limit configuration bug.
Happy to provide additional account-independent diagnostics if useful.
Since /status itself directs users to the Usage dashboard for up-to-date rate-limit information, having neither surface expose the 5-hour window makes the documented limit effectively unverifiable from the user side.
stanicio commentedon Aug 22, 2026
I can confirm the missing main 5-hour bucket on another ChatGPT Pro Lite account using Codex CLI 0.147.0 on Windows.
Two consecutive
/statusobservations (Europe/Prague, CEST):2026-08-21 22:22
gpt-5.6-terra2026-08-22 01:28
gpt-5.6-terraduring the interval and had not selected or used SparkThe observations were approximately 3 hours 5 minutes apart. The unused Spark 5-hour reset timestamp also moved forward by approximately 3 hours 5 minutes while remaining at 100% and without any Spark use. This makes the displayed Spark timestamp appear to be a continuously recalculated prospective value (
current time + 5 hours) rather than the end of an active fixed window.At the same time, actual Terra usage reduced the main weekly allowance from 100% to 99%, but the main 300-minute/5-hour bucket remained absent from
/status.This appears consistent with the missing main 300-minute bucket reported here, and it additionally raises a display-semantics question for unused model-specific buckets:
resets_atevent?Timestamped screenshots are available and I can provide sanitized crops if useful.
artspace-design commentedon Sep 7, 2026
Pro 20x / macOS / Codex CLI 0.153.4 / GPT-6 Astra, September 6–7, 2026, Europe/Riga (UTC+3).
Reset history correction: I used one reset while still on Plus with Astra on September 6. No post-upgrade reset has been reported, and none was used for this investigation; two remain available.
After upgrading around 22:00, I repeatedly saw the general five-hour usage meter in the desktop app until approximately 00:40, including after several app restarts for connection reasons. Initially I saw 100% remaining in both windows. The last evening five-hour display showed approximately 60–70% remaining and roughly three hours until reset. About seven hours later, the general five-hour meter was absent and weekly remaining was approximately 24–30% (24% in the preserved investigation snapshot).
Saved metadata presents an unresolved discrepancy: the first captured Pro record at 22:11:53 already has primary=10080 minutes, 0% used, secondary=null. The first captured 76% weekly-used record is at 08:04:14, approximately 9h52m later. This is a different interval from the overnight seven hours, not a correction of it. Percentages from different buckets must not be subtracted to infer overnight weekly consumption.
The current web/account snapshot and my earlier CLI /status observation show general/Astra weekly-only while Spark independently has five-hour and weekly windows at 100%. The desktop five-hour display persisted across restarts before disappearing, so please investigate the client/server bucket selection, display/countdown, entitlement and enforcement transition. I cannot establish from local records whether a hidden five-hour limit is enforced or deductions are incorrect.
I expect Astra, Ultra, Fast, long context and parallel tasks to consume substantially more usage. My concern is the loss of the short-term budgeting indicator together with weekly depletion and accurate attribution. I have submitted an account-side investigation request through OpenAI Support. No benchmark was started.
The returned missing-bucket structure matches this issue.
mark-iap commentedon Sep 7, 2026
Your before/after snapshots are the right diagnostic: when the 5h row vanishes from the Usage dialog,
account/rateLimits/readusually stops returning awindowDurationMins: 300bucket. What used to beprimary=300+secondary=10080collapses to a single weekly window (primary.windowDurationMins: 10080,secondary: null). So/statusand the desktop Usage UI are not "hiding" a second meter they still have locally — they are rendering whatever the App Server snapshot currently contains.Practical check: call
account/rateLimits/readagain after auth/app restart and note (1) whether any limit object still has300, (2) which window isprimary, and (3)resetsAton the weekly bucket. Separately, if you want task-level visibility while the 5h meter is missing, compare consecutive rate-limit percentages against local session JSONL token/turn history — that shows burn rate even when the backend omits the short window.Until both windows are stably exposed again in
/status(reset times especially), a small local watcher that polls App ServerrateLimits/readand charts weekly vs any 5h bucket helps — I've been using CodexFuse for that split (App Server = live limits, JSONL = history). Happy to share a minimal JSON-RPC snippet if useful.Fix quota display for ChatGPT Pro plans