Repository navigation
Show banked reset count, expiration, eligibility, and reset events in Codex usage surfaces #28805
Description
What variant of Codex are you using?
Codex App, Codex Web, Codex CLI, and Codex IDE extension.
What feature would you like to see?
Please add a first-class, user-visible banked reset state anywhere Codex shows account usage.
At minimum, Codex should show:
- Current banked reset count
- Expiration date/time for available resets, or at least the next expiring reset
- Whether the current account/workspace is eligible for reset banking
- A clear unavailable / ineligible / error state when reset data cannot be shown
- Whether a reset was recently applied or expired
- Whether a reset was applied manually or automatically, if automatic use is possible
A minimal user-safe version would be enough:
Banked resets: 1 available
Expires: Jul 11, 2026
Last reset event: Applied Jun 16, 2026
or:
Banked resets: none available
Status: not eligible / unavailable / failed to load
Additional information
Reset banking is only useful if users can understand and plan around it.
OpenAI documents reset banking and says an available banked reset can be used from the profile-menu usage summary:
https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan
OpenAI also documents Codex usage stats / token activity in the Codex app Profile settings area:
https://developers.openai.com/codex/app/settings#profile
The Codex changelog says reset banking was added in Codex app 26.609:
https://developers.openai.com/codex/changelog
Codex should make the state of banked resets explicit in usage/profile surfaces.
Without an explicit reset-state surface, users may be unable to distinguish:
- No reset was granted
- A reset was granted but expired
- A reset was granted but already consumed
- A reset was automatically consumed
- The account or workspace is ineligible
- Usage/reset state failed to load
- The relevant UI surface is missing or gated
Acceptance criteria:
- Users can see whether they currently have any banked resets.
- Users can see when available banked resets expire.
- Users can distinguish
0 resets availablefromnot eligiblefromfailed to load. - Users can see whether a reset was recently consumed or expired.
- If resets can be consumed automatically, the UI states that clearly.
- The state is available from at least one documented Codex account/profile/usage surface.
- Read-only reset state is consistent across Desktop, Web, CLI, and IDE where feasible.
Related issues:
- Reset expiration visibility: Show expiration dates for each available usage reset #28161
- Reset scope/history transparency: Clarify Codex rate-limit reset behavior and make reset scope visible in Usage UI #20395
- Cross-surface access to banked resets: Linux Codex users cannot access or redeem banked usage resets #27915
- Automatic reset consumption: Codex automatically consumed my token reset opportunity during long-running task #28525
Activity
github-actions commentedon Jun 17, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
coygeek commentedon Jun 18, 2026
See my workaround on #28963
AyalX commentedon Jun 27, 2026
I built a small CLI for this while waiting for native support: https://github.com/AyalX/codex-reset-tracker. It shows your banked resets with grant/expiry dates and days left, plus current 5h/weekly usage. Read-only, lightweight. Happy to add whatever's useful.
JayPernet commentedon Jul 23, 2026
I implemented and locally validated a focused Codex CLI/TUI prototype for the “next expiring reset” part of this issue.
What it does:
reset-expiryas a configurable status-line item and includes it in the default status line.expires_atamong reset credits whose status isAvailable.The implementation includes focused tests for earliest-expiry selection, startup refresh behavior, and the TUI snapshot. The focused tests,
just fix -p codex-tui,git diff --check, andcargo build -p codex-clipass. I also tested the compiled CLI interactively with real reset-credit data.Implementation branch and commit:
43f7e687a feat(tui): show next reset expiry in status lineI read the contribution policy and understand that external PRs are invitation-only. If this scoped CLI approach aligns with the intended solution, would a maintainer be willing to invite a PR against
main? I can adjust the wording, default status-line composition, or scope before opening it.