Expose rate-limit reset times, balance, plan as status_line tokens

Summary

The CLI status_line exposes five-hour-limit and weekly-limit as percentages only. The underlying rate-limit data is richer — account/rateLimits/read returns resetsAt, windowDurationMins, credits.balance, planType — but those fields aren't reachable via status_line tokens.

Missing tokens (as of 0.133.0)

five-hour-limit-reset — formatted local time of primary.resetsAt
weekly-limit-reset — formatted local time of secondary.resetsAt
credits-balance — credits.balance (e.g. $766.76) when credits.hasCredits && !credits.unlimited
plan-type — planType (e.g. prolite)
(optional) rate-limit-window-primary / -secondary — windowDurationMins formatted

Use case

Mirrors Claude Code's statusline which shows percentage + reset time. Without reset times the bare percentage is hard to act on — "5h 80%" doesn't tell you whether you have 10 minutes or 3 hours of breathing room. With it:

... · 5h 80% @11:36pm · weekly 83% @5/27 5:40am · ...

Workaround

Spawn codex app-server from outside, JSON-RPC handshake, call account/rateLimits/read, parse, render. Works but adds ~3-5s subprocess startup per query and requires users to build their own caching layer. The data is already there inside the running CLI; surfacing it as a token is a small change.

Verified data shape (0.133.0)

account/rateLimits/read returns:

{
  "rateLimits": {
    "limitId": "codex",
    "primary": { "usedPercent": 25, "windowDurationMins": 300, "resetsAt": 1779459394 },
    "secondary": { "usedPercent": 18, "windowDurationMins": 10080, "resetsAt": 1779826837 },
    "credits": { "hasCredits": true, "unlimited": false, "balance": "766.76..." },
    "planType": "prolite",
    "rateLimitReachedType": null
  },
  "rateLimitsByLimitId": { ... }
}

Acceptance

Adding these to the existing config:

status_line = ["model-with-reasoning", "codex-version", "context-remaining",
               "five-hour-limit", "five-hour-limit-reset",
               "weekly-limit", "weekly-limit-reset",
               "credits-balance", "project", "git-branch"]

Produces:

gpt-5.5 high · 0.133.0 · Context 28% left · 5h 25% @11:36pm · weekly 18% @5/27 5:40am · $766.76 · self-service-workbench · main

Thanks for the great CLI.

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

Codex Windows app no longer shows remaining usage / rate limit reset information #23450

Powered by Codex Action

Two related UX observations from building a workaround:

1. TUI rate-limit display doesn't auto-refresh

The StatusRateLimitState in the TUI updates only when:

A model response arrives (TokenCount events carry rate_limits)
Session start / resume (explicit one-shot read)
An account/rateLimits/updated notification fires

There's no periodic poll. For long-running idle sessions, the displayed values freeze at whatever was last seen until the user sends a new prompt.

Concrete impact: open a Codex session at noon when 5h is at 50%, work for 4 hours, idle for 1 hour. The 5h window has now rolled past your earlier usage and you genuinely have ~95% headroom again, but the TUI keeps showing 50% until you next prompt.

Would be helpful if either (a) the TUI polled account/rateLimits/read on a slow cadence (e.g. every 5 minutes when idle), or (b) the status_line tokens proposed in the issue body got auto-refreshed independently of TokenCount events.

2. `usedPercent` vs displayed-remaining naming mismatch

The API field is RateLimitWindow.usedPercent (in account/rateLimits/read and TokenCountEvent). The TUI display shows 100 - usedPercent ("5h 94%" when 6% is used).

This is a footgun for anyone integrating against the data. Either:

Add a remainingPercent field to the API response so integrators don't have to do the conversion (and don't display the same number with opposite meaning by accident), or
Rename the existing field to make the semantic explicit (e.g. windowUsedPercent).

Burned about an hour debugging an apparent mismatch between an external integration showing usedPercent and the TUI showing remaining; both were live and correct, just inversely framed.

Thanks again.

On the usedPercent vs displayed-remaining footgun, which is a real one: I built aistat, and calling account/rateLimits/read from outside the CLI I hit the same trap, so it emits both fields rather than picking one.

It surfaces most of what you listed — both reset times (primary/secondary.resetsAt), the plan (planType), and used + remaining percentages, recomputed against now each call. Two caveats: it doesn't expose credits.balance today, and the window duration shows up as the window label (five_hour/seven_day) rather than a raw windowDurationMins. Human view:

$ aistat -h
Claude usage
- personal@example.com (active) [Max 5x]
  - 5-hour: 92.0% (resets in 4h 53m)
  - 7-day: 71.0% (resets in 2d 5h)
- work@example.com [Max 20x]
  - 5-hour: 4.0% (resets in 4h 12m)
  - 7-day: 12.0% (resets in 5d 9h)

Codex usage
- personal@example.com (active) [Pro]
  - 5-hour: 25.0% (resets in 5h 16m)
  - 7-day: 18.0% (resets in 4d 18h)

and the full JSON:

$ aistat usage codex
{
  "checked_at": "2026-05-29T18:21:04+00:00",
  "providers": {
    "codex": {
      "accounts": [
        {"email": "you@example.com", "plan": "Pro", "active": true,
         "limits": {
           "five_hour": {"used_percent": 25, "remaining_percent": 75, "resets_at": "2026-05-29T23:36:34+00:00", "reset_after_seconds": 18930},
           "seven_day": {"used_percent": 18, "remaining_percent": 82, "resets_at": "2026-06-03T05:40:37+00:00", "reset_after_seconds": 472773}
         }}
      ]
    }
  }
}

reset_after_seconds sidesteps the "freeze at last seen value" problem — recomputed against now on every call, so any polling cadence gives a fresh "in N minutes" string. 90s file cache makes aggressive statusline refresh safe. Same binary covers Claude/Copilot.

https://github.com/drogers0/aistat

Adding another user data point: the current statusline can show 5h 60% left · weekly 84% left, but it still does not show the reset timestamp for either window. That makes the percentages hard to act on because 60% left is very different if the 5h window resets in 10 minutes versus several hours. This is a pretty important usability gap for terminal-first users; the Claude Code ecosystem already has many statusline plugins that show usage together with reset timing, so users coming from that workflow expect this information to be visible directly in the CLI footer. Adding the reset time next to each existing limit token, for example 5h 60% left (resets 14:30) and weekly 84% left (resets Mon 03:00), would make the current tokens much more actionable.

@Jasonzh8

+1 to @Jasonzh8 ’s point. The current statusline percentages are useful, but without reset timing they’re hard to act on.

the token split reads clean in config but it leaks the moment the 5h window rolls between two status_line refreshes. five-hour-limit and five-hour-limit-reset get rendered on separate ticks, so you can briefly show 80% next to a resetsAt that already fired, which is exactly the case the reset time was supposed to fix. they both come off one rateLimits/read snapshot, so the fix is reading usedPercent and resetsAt from the same fetch and rendering them as one unit, not two independent tokens that can desync.

we hit the same desync reading claude's quota off the same endpoint settings/usage renders, ended up pinning percent and resetsAt to one fetch: https://claude-meter.com/r/kqh8mw3f

feat(claude): show rate-limit reset time in the status line

Adding my voice as a paying ChatGPT subscriber. The official Codex pricing documentation still says local messages and cloud tasks share a five-hour window, with additional weekly limits potentially applying. However, the current /status output does not show the five-hour reset time, so users cannot tell when that included allowance refreshes or reliably distinguish the five-hour and weekly limits.

Please restore clear visibility of both quota windows in /status and the status line, including:

five-hour usage remaining and exact reset time
weekly usage remaining and exact reset time
plan type and any purchased-credit balance
a clear indication of which limit is currently binding

If the five-hour allowance has been removed, reduced, or replaced by a weekly-only system for any accounts, OpenAI should state that plainly and notify affected subscribers before the change. Hiding or omitting reset information materially reduces transparency and the value of a paid subscription.

Please expose the 5-hour and weekly rate-limit reset times in the built-in Codex CLI statusline.

Requested display:

5h 82% left · 22:14
wk 97% left · 0803 09:00

On Codex CLI 0.146.0, account/rateLimits/read currently returns only the weekly 10080-minute window for my account, so the 5-hour window cannot be displayed
even though the pricing documentation describes it.

Please either:

expose reset-time statusline items such as five-hour-limit-reset and weekly-limit-reset, and
clarify whether the missing 300-minute window is a backend/account regression or an intentional change.

The current behavior makes it impossible to tell when the 5-hour limit resets.

Please support an absolute reset time in the user’s local timezone, using a generic format such as weekly 91% left · YYYY-MM-DD(ddd) HH:mm JST reset. The concrete date should come from the current rate-limit metadata, not from configuration.

If you want exact rate-limit reset times and countdowns in your Codex prompt today, check out cxstatusline.

It exposes:

5-Hour & Weekly Countdowns: Combines percentage with live countdowns (e.g. 5h 85% ↻ 2h 45m, week 22% ↻ 4d 18h).
Context Tokens: Raw used/window tokens (k/200k) and visual progress bars.
Custom Formatting: Interactive terminal TUI (cxstatusline) to customize labels, ordering, and Powerline separators.

It uses verified prebuilts and can be cleanly reverted at any time via cxstatusline revert.

👉 Web Playground: https://cxstatusline.adrijshikhar.dev
📦 GitHub Repo: https://github.com/adrijshikhar/cxstatusline

+1 for exposing weekly reset/window information in the status line.
The most useful form would be percentage of the weekly window remaining, displayed beside weekly-limit, e.g.:
weekly quota 62% · week remaining 47%
That immediately tells the user whether they are ahead of or behind sustainable usage pace. A reset timestamp/countdown is much less actionable because it requires mentally converting time-to-reset into a fraction of the window.
Since Codex already knows the reset time and window duration, this should be a trivial derived field.

Navigation Menu

Repository navigation

Expose rate-limit reset times, balance, plan as status_line tokens #24080

Summary

Missing tokens (as of 0.133.0)

Use case

Workaround

Verified data shape (0.133.0)

Acceptance

1. TUI rate-limit display doesn't auto-refresh

2. `usedPercent` vs displayed-remaining naming mismatch

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Expose rate-limit reset times, balance, plan as status_line tokens #24080

Description

Summary

Missing tokens (as of 0.133.0)

Use case

Workaround

Verified data shape (0.133.0)

Acceptance

Activity

github-actions commented on May 22, 2026

NavinAgrawal commented on May 22, 2026

1. TUI rate-limit display doesn't auto-refresh

2. usedPercent vs displayed-remaining naming mismatch

drogers0 commented on Jun 3, 2026

Jasonzh8 commented on Jun 13, 2026

zhangchitc commented on Jun 16, 2026

m13v commented on Jun 18, 2026

m13v commented on Jun 18, 2026

chuckatbcs commented on Jul 12, 2026

yukinaga-yoshida commented on Jul 31, 2026

potatoEggCheese commented on Aug 24, 2026

adrijshikhar commented on Oct 1, 2026

johnw3d commented on Oct 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

2. `usedPercent` vs displayed-remaining naming mismatch