›_ Codex Issues
Codex Issues / #28805

Show banked reset count, expiration, eligibility, and reset events in Codex usage surfaces

Open 💬 4 comments Opened Jun 17, 2026 by rookslog
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 available from not eligible from failed 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:

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #28161
  • #27915
  • #27934

Powered by Codex Action

coygeek · 2 months ago

See my workaround on #28963

AyalX · 2 months ago

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 · 1 month ago

I implemented and locally validated a focused Codex CLI/TUI prototype for the “next expiring reset” part of this issue.

What it does:

  • Adds reset-expiry as a configurable status-line item and includes it in the default status line.
  • Selects the earliest expires_at among reset credits whose status is Available.
  • Ignores unavailable credits and credits without an expiration timestamp.
  • Refreshes the status line when reset-credit data is loaded at startup or updated.
  • Renders the expiration date in the user’s local timezone.

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, and cargo build -p codex-cli pass. I also tested the compiled CLI interactively with real reset-credit data.

Implementation branch and commit:

I 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.