Show expiration dates for each available usage reset #28161
Description
Codex app version
Desktop Codex: 26.609.41114 — released Jun 12, 2026
Platform / plan
- macOS Tahoe
26.5.1 - Pro plan
Summary
Please show the expiration time for each available usage reset.
In the account menu, Codex currently shows something like:
2 resets available
However, if reset opportunities expire after a limited time window, for example around 30 days, the UI should show the remaining expiration time for each reset.
Current behavior
The menu only shows how many resets are available, but it does not clearly show when each reset will expire.
This makes it hard for users to know whether they should use a reset soon or whether it is safe to save it for later.
Expected behavior
Codex should display the expiration date or remaining time for each available reset, such as:
- Reset 1: expires in 12 days
- Reset 2: expires in 27 days
or:
- Reset available until Jun 25
- Reset available until Jul 8
Why this matters
If resets have an expiration window, users need to know when they will expire. Otherwise, users may accidentally lose reset opportunities simply because the UI did not warn them in advance.
Showing the expiration time would help users plan their usage more reasonably and use resets before they expire.
Request
Please add an expiration date / countdown display for each available reset, and consider showing a warning when a reset is close to expiring.
Activity
furkancak1r commentedon Jun 18, 2026
Adding another current report from Windows Codex Desktop:
26.611.61753(released 17 Jun 2026)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 availableExpires Jul 18, 2026orExpires in 12 daysThis should be visible wherever Codex shows reset/usage state. Related broader tracking issue: #28805.
coygeek commentedon Jun 18, 2026
See my workaround on #28963
myudak commentedon Jun 20, 2026
literally why is this not a thing
scyuo commentedon Jun 29, 2026
I can reproduce this on Codex CLI
0.142.3on macOS Apple Silicon./usageshows:Show usageRedeem usage limit resetYou have 2 usage limit resets availableBut
Show usageonly 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
/usageexposed reset credit state in a read-only way, for example: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.
Lisenish commentedon Jun 29, 2026
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
vtsixthai commentedon Jul 6, 2026
ryanbliss commentedon Jul 18, 2026
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).
krazykoder commentedon Jul 18, 2026
me too i missedmy reset - i did not know what time it was expiring at PST timezone.
YBJ0000 commentedon Jul 25, 2026
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/27Expires 8/1Expires 8/13No 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:
initializeinitializedaccount/rateLimits/readThe response already contains exact Unix timestamps at:
rateLimitResetCredits.credits[].expiresAtConverted to the Mac's local timezone (
Australia/Sydney), the three reset credits expire at: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/27materially 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
expiresAtvalue in the user's local timezone and include at least: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: #32540 (comment)
No reset was consumed during the investigation, and no tokens, account IDs, or credit IDs were exposed.
y4ho0 commentedon Jul 28, 2026
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.