Skip to content

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

Open

Description

@rookslog

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:

Activity

  1. added
    enhancementNew feature or request
    appIssues related to the Codex desktop app
    codex-webIssues related to Codex Web
    CLIIssues related to the Codex CLI
    extensionIssues related to the VS Code extension
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    on Jun 17, 2026
  2. github-actions commented on Jun 17, 2026

    @github-actions
    Contributor
  3. coygeek commented on Jun 18, 2026

    @coygeek

    See my workaround on #28963

  4. AyalX commented on Jun 27, 2026

    @AyalX

    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.

  5. JayPernet commented on Jul 23, 2026

    @JayPernet

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIappIssues related to the Codex desktop appcodex-webIssues related to Codex WebenhancementNew feature or requestextensionIssues related to the VS Code extensionrate-limitsIssues related to rate limits, quotas, and token usage reporting

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions