Show expiration dates for each available usage reset

Adding another current report from Windows Codex Desktop:

• Codex Desktop: 26.611.61753 (released 17 Jun 2026)
• Platform: Windows

Same concern: banked usage resets appear to be time-limited, around 30 days, but the UI does not show the exact expiration date/time or remaining countdown. Without that, users cannot tell whether a reset is safe to save or needs to be used soon.

The minimum useful UI would be enough, for example:

• 1 reset available
• Expires Jul 18, 2026 or Expires in 12 days

This should be visible wherever Codex shows reset/usage state. Related broader tracking issue: #28805.

See my workaround on #28963

literally why is this not a thing

I can reproduce this on Codex CLI 0.142.3 on macOS Apple Silicon.

/usage shows:

• Show usage
• Redeem usage limit reset
• You have 2 usage limit resets available

But Show usage only opens token activity views (daily, weekly, cumulative) and does not show the expiration date/time for available reset credits.

The only visible reset-related path is Redeem usage limit reset, which feels unsafe as a discovery path because users cannot tell whether they are only viewing reset state or about to consume a reset.

It would be helpful if /usage exposed reset credit state in a read-only way, for example:

• available reset count
• next expiration date/time
• days remaining
• whether selecting the reset flow is view-only or destructive

This matters because the UI says the reset opportunity expires after about 30 days, but there is no exact date available for setting a reminder before expiration.

There's a workaround for that, I think expirations are even in API response, they're just not visible in UI. Ask your agent to figure out API how to get an API response and show them to you

Adding my voice here. The single most useful thing for me would be seeing the latest use-by date across my whole bank — i.e. the date by which I need to have used my resets. Right now I see "X resets available" with no date, so I can't tell whether I should use one today or safely hold onto them. A single "use your resets by <date>" line would fix most of the problem for me; per-reset expiry would be even better.

At the very least, why not automatically apply it at the end of the window? I accidentally missed the window by 5 minutes and lost it. 30 days is one thing, but 30 days without an automatic redemption is rough, considering that there is a good amount of timing involved with when you should realistically spend it.

Alternatively, just always have it reset at 11:59 PM in the user's timezone (from the user's timezone that was configured when the reset was added, to avoid misuse).

me too i missedmy reset - i did not know what time it was expiring at PST timezone.

I was able to confirm the underlying data on macOS and narrow this down to a Desktop UI presentation issue rather than missing backend data.

Reproduction

The Codex Desktop Usage panel shows only date-level values:

• Expires 7/27
• Expires 8/1
• Expires 8/13

No exact time or timezone is shown.

Precise data source

Using the bundled local Codex app-server in a read-only manner, I sent the JSON-RPC sequence:

1. initialize
2. initialized
3. account/rateLimits/read

The response already contains exact Unix timestamps at:

rateLimitResetCredits.credits[].expiresAt

Converted to the Mac's local timezone (Australia/Sydney), the three reset credits expire at:

• 2026-07-27 09:46:44 AEST
• 2026-08-01 06:02:10 AEST
• 2026-08-13 03:33:15 AEST

Root cause hypothesis

The backend/app-server already provides the precise expiration timestamp, but the Desktop UI truncates it to a calendar date. That makes a label such as Expires 7/27 materially ambiguous, because the reset can disappear during the morning of July 27 rather than remaining available until the end of that day.

Suggested fix

Render the existing expiresAt value in the user's local timezone and include at least:

• full date
• exact time
• timezone abbreviation or UTC offset
• optionally, a remaining-time countdown near expiration

For example:

Expires Jul 27, 2026 at 09:46 AEST (UTC+10)

This should not require a backend change because the precise timestamp is already available in account/rateLimits/read.

I also added the same macOS cross-platform confirmation to #32540: https://github.com/openai/codex/issues/32540#issuecomment-5077102390

No reset was consumed during the investigation, and no tokens, account IDs, or credit IDs were exposed.

I ran into this issue yesterday.

One of my usage limit resets showed that it would expire that day, but the UI did not show the exact expiration time or timezone. I planned to use it after waking up, but when I checked again, the reset had already expired.

This was especially frustrating because I knew the expiration date and intended to use the reset in time, but the date-only display did not give me enough information to do so.

Showing the exact local expiration time, for example:

Expires Jul 27, 2026 at 09:46 JST (UTC+9)

would have prevented this.