Skip to content

Expose detailed rate-limit reset credits in Codex supported surfaces #29618

Closed
#30488
Closed
Expose detailed rate-limit reset credits in Codex supported surfaces#29618
#30488
Assignees
jayp-oai
Labels
app-serverIssues involving app server protocol or interfacesenhancementNew feature or requestrate-limitsIssues related to rate limits, quotas, and token usage reporting

Description

@darlingm
darlingm
opened on Jun 23, 2026

Summary

Codex currently exposes earned usage-limit reset count and redemption in some supported surfaces, but not the detailed reset-credit rows needed to show expiry dates.

In rust-v0.142.0, app-server exposes:

  • account/rateLimits/read -> rateLimitResetCredits.availableCount
  • account/rateLimitResetCredit/consume -> redeem one reset by idempotencyKey

It does not expose per-credit details such as grant time, expiry time, status, reset type, or id.

Please expose detailed rate-limit reset credits through supported Codex surfaces, especially app-server, so Codex CLI/TUI and Codex app can show reset expiry information without relying on private backend endpoints.

Why this matters

Banked Codex resets expire. Users can see that they have N resets available, but supported Codex surfaces do not currently show when each reset expires. That makes it easy to lose a reset unintentionally.

Open-source tools are already using a private backend endpoint directly to fill this gap:

GET /backend-api/wham/rate-limit-reset-credits

That is uncomfortable for users and maintainers because it is not clear whether OpenAI wants clients calling that endpoint directly. It also pushes clients toward reading local auth files and constructing ChatGPT backend headers themselves, instead of letting Codex own auth refresh, account selection, and compatibility.

Some public tools report finding this endpoint in the official openai.chatgpt VS Code extension webview bundle (webview/assets/codex-api-*.js). Others describe it as the internal Codex Desktop endpoint used by the app. So this does not appear to require inventing a new backend capability from scratch; it would expose existing reset-credit detail through supported Codex product/protocol surfaces.

Requested behavior

Expose detailed reset-credit rows in a supported Codex API, either by expanding account/rateLimits/read or adding a dedicated app-server method.

Example shape:

{
  "rateLimitResetCredits": {
    "availableCount": 2,
    "credits": [
      {
        "id": "RateLimitResetCredit_...",
        "resetType": "codex_rate_limits",
        "status": "available",
        "grantedAt": "2026-06-17T00:00:00Z",
        "expiresAt": "2026-07-17T00:00:00Z"
      }
    ]
  }
}

Product surfaces

This would be useful in:

  • Codex CLI/TUI /usage
  • Codex app usage/account UI
  • app-server clients that want to show expiry warnings or explain reset availability
  • local tools that should avoid private backend calls

Notes

This request is not asking clients to depend on private wham endpoints. It is asking for a supported Codex surface so users and local tools do not need to call those endpoints directly.

Activity

  1. github-actions
    added
    enhancementNew feature or request
    app-serverIssues involving app server protocol or interfaces
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    on Jun 23, 2026

  2. github-actions commented on Jun 23, 2026

    @github-actions
    github-actionsbot
    on Jun 23, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. hehee9 commented on Jun 27, 2026

    @hehee9
    hehee9
    on Jun 27, 2026

    I took a look at this and have a small local prototype for showing reset-credit expiries in /status.

    Proposed approach:

    • Keep rateLimitResetCredits.availableCount as-is for backward compatibility.
    • Extend rateLimitResetCredits with an optional credits array.
      • minimum useful field: expiresAt
      • additional passthrough fields if available: id, status, resetType, grantedAt
    • Preserve count-only responses, so existing clients keep working.
    • Use the details only for display in TUI /status; /usage reset redemption would continue to use the existing consume flow.

    Example UI:

    5h limit:             [████████████████░░░░] 82% left (resets 2h 08m)
Weekly limit:         [████████░░░░░░░░░░░░] 39% left (resets 3d 7h 37m)
Usage limit resets:   2 available
                     #1 expires 09:39 on 18 Jun 2026   Full reset (Weekly + 5h)
                     #2 expires 08:59 on 27 Jun 2026   Full reset (Weekly + 5h)

    Fallback behavior:

    • availableCount == 0: show none available
    • count-only response: show N available without synthetic detail rows
    • monthly/free/go-style reset scope: show Full reset (Monthly)
    • narrow terminals: wrap the expiry/detail line rather than truncating it

    Tests I would include:

    • backend-client parses detailed and count-only reset-credit responses
    • app-server/protocol preserve the optional detail rows
    • TUI renders multiple credits, zero credits, count-only responses, narrow-width wrapping, monthly reset scope, and avoids stale cached reset-credit rows when a later response omits details

    Would this be an acceptable direction for a PR, assuming external PRs are currently by invitation?

  4. dezmen3 commented on Jun 27, 2026

    @dezmen3
    dezmen3
    on Jun 27, 2026

    This is actually very needed feature as we can't see expire dates on codex cli while many of users have only access to gpt via codex cli and not always web.

  5. jayp-oai
    self-assigned this
    on Jun 28, 2026

  6. KaixuanLi-sibcb commented on Jul 6, 2026

    @KaixuanLi-sibcb
    KaixuanLi-sibcb
    on Jul 6, 2026

    Adding a user-facing confirmation from current Codex Desktop behavior.

    In the account menu, Codex shows only a count such as 2 available resets, while the read-only backend response already includes per-credit details from:

    GET /backend-api/wham/rate-limit-reset-credits

    The response includes available_count and credits[] entries with fields including status, title, description, profile_user_id, granted_at, and expires_at. In my case the UI showed two available resets, and the endpoint returned two available credits with distinct granted_at / expires_at values and the title Full reset (Weekly + 5 hr).

    This confirms the exact data needed for a better UX already exists server-side, but users currently have to inspect private/local state or call an internal endpoint to find out when resets expire.

    Requested behavior:

    • show exact expiry time for each available reset in the account menu / “See resets” modal
    • show what the reset applies to, e.g. Weekly + 5 hr
    • expose the same detail through supported Codex surfaces such as app-server / CLI instead of requiring direct calls to private backend endpoints
    • show remaining reward-eligible referral invites directly in the invite panel, or explicitly say when invites are still allowed but no longer reward-eligible

    This would make banked resets auditable and prevent users from unintentionally losing expiring reset credits.

  7. jayp-oai
    added a commit that references this issue on Jul 6, 2026

    [app-server] Include reset-credit details in rate limits (#30395)

    58ec528

  8. MaximeMichaud commented on Jul 6, 2026

    @MaximeMichaud
    MaximeMichaud
    on Jul 6, 2026

    Hello.
    I haven't reviewed the PR code, but I agree this feature should be in Codex. The example UI from @hehee9 looks good to me. Right now I had no clear way to see when my reset credits expire; I saw that some people had this in the web app, so I ended up checking through the API to avoid losing my resets. It would be great to have this properly integrated in Codex :)
    Thanks.

  9. jayp-oai
    closed this as completedin #30488on Jul 7, 2026
  10. jayp-oai
    added a commit that references this issue on Jul 7, 2026

    [codex-cli] Show reset details in redemption picker (#30488)

    d7ab20c
  11. leonardosahon
    added a commit that references this issue on Sep 5, 2026

    claude-sonnet-5 (feat): add banked Codex reset activation to usage qu…

    1dfd567
  12. sedna-release-publisher
    added 2 commits that reference this issue on Sep 15, 2026

    [app-server] Include reset-credit details in rate limits (openai#30395)

    3fad668

    [codex-cli] Show reset details in redemption picker (openai#30488)

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

Metadata

Metadata

Assignees

Labels

app-serverIssues involving app server protocol or interfacesenhancementNew feature or requestrate-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