Feature: Expose full usage/limits data in CLI (/status command)

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

• #14235
• #14319
• #15123

Powered by Codex Action

You can configure the CLI to display the usage limits in the status line using the /statusline command and selecting five-hour-limit and/or weekly-limit.

Люди которые

Thanks @etraut-openai — the /statusline items are useful, and I've been using five-hour-limit + weekly-limit myself. Just wanted to share a few thoughts on why a dedicated /usage surface might still be worth keeping on the table, alongside the statusline approach.

A pane (or /status --detailed) could cover a few cases that a single statusline row can't easily handle:

• Multiple limits + reset times side by side — 5h, weekly, weekly-Sonnet (Max/Team), Extra usage / credits (Pro/Max), each with its own reset timestamp in the user's timezone. Statusline tends to truncate when several of these stack up.
• Plan-aware rows — the Sonnet bar is redundant for Plus users, Extra usage only matters for Pro/Max. Conditional rendering feels more natural in a pane.
• Discoverability — /usage is self-documenting; statusline items require users to know they exist and opt in.

Implementation-wise the data already lives in rate_limit_snapshot (same payload behind the current statusline items and the JSON shape @alwint3r outlined in #20310), so this is largely a TUI addition rather than new plumbing.

For inspiration there's a fairly polished version in Claude Code's components/Settings/Usage.tsx — the eighth-block Unicode glyphs (▏▎▍▌▋▊▉█) give ~1/8-cell precision in about 30 lines and would port cleanly to a small ratatui widget.

One open question: would the team prefer a new /usage command or a --detailed flag on /status? Either pattern works; the answer probably depends on cross-surface consistency goals. Happy to also move this to a separate enhancement issue if that fits better — just didn't want to fragment the discussion away from here by default.

If the direction looks aligned and you'd welcome a contribution, I'm glad to put together a small prototype gist first (eighth-block widget rendered against mocked snapshot data) so the visual is concrete before any PR discussion. For what it's worth on the process side, I'm an active Linux kernel contributor, so the atomic-commit / patch-series review workflow in the contributing guide is familiar ground.

For the scripted/external slice of this, complementing the /statusline pointer above: I built aistat, which reads the same account/rateLimits/read endpoint. The human view across accounts:

$ 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 same data as JSON for the scripted case:

$ 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.0, "remaining_percent": 75.0, "resets_at": "2026-05-29T23:36:34+00:00", "reset_after_seconds": 18930},
           "seven_day": {"used_percent": 18.0, "remaining_percent": 82.0, "resets_at": "2026-06-03T05:40:37+00:00", "reset_after_seconds": 472773}
         }}
      ]
    }
  }
}

/statusline items are still the right answer for in-CLI rendering; this is just for the external case. The same binary covers Claude too.

https://github.com/drogers0/aistat

This is about programmatically getting the 5 hour and weekly usage status via the codex CLI so you can get them from lets say a python script and use in a skill or something.

Right now GPT5.5 has no way to know what the current usage limits are for 5 hour or weekly so it makes it horrible to plan orchestration of subagents as you risk having to restart partial work and waste do those tasks over again.

The original request as written is what is requested by the original post I assume, so while its nice people are trying to tell how to use statusline but that will not resolve this issue.

I am surprised that this was not already a thing, and I am surprised that you do not have a tool the AI can use in your harness to read current usage. It would be amazing if it can get this data to better manage subagents and know when to pause.