[FEATURE] Populate `rate_limits` in statusLine JSON before the first API call of a session

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

#18121 and #27915 (both closed) asked for rate_limits (5-hour / 7-day plan quota usage) to be exposed in the statusLine JSON input at all. That shipped in v2.1.80 — thank you, it's a huge improvement.

There's a gap left over, though: rate_limits (and, separately, context_window.total_input_tokens / total_output_tokens) are null/absent until Claude Code has completed at least one real API call in the session. In practice this means a brand-new session shows nothing about plan usage at all until you've already sent a message — which is exactly the moment you'd most want to check it, e.g. before starting a long task, to decide whether you have enough 5-hour quota left to safely begin it.

So the original ask from #18121/#27915 — "let me see my quota without interrupting my workflow" — is only partially solved: you can now see it during a session, but not before you commit to starting one.

Proposed Solution

Populate rate_limits (and ideally context_window.total_input_tokens/total_output_tokens) in the very first statusLine render of a session, before any user message has been sent — e.g. via a lightweight session-init check against the same anthropic-ratelimit-unified-status headers already used to power /usage, rather than waiting for it to be a side-effect of the first real completion call.

Minimal viable behavior: if a cached/recent rate-limit reading exists for the account (e.g. from the tail end of the previous session), surface that immediately on session start instead of null, and let it refresh normally once the first real call happens.

Alternative Solutions

| Workaround | Why it fails |
|---|---|
| Run /usage manually before starting | Interrupts workflow — the exact problem #18121/#27915 already established this doesn't solve |
| Wait for the first message, then check the statusLine | Defeats the purpose — you wanted to know before committing to a task, not after |
| Cache the last-seen rate_limits value client-side between sessions | Possible as a script-side workaround, but it's stale by definition and every statusLine script would need to reimplement it individually |

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

Use Case Example

1. I open a new Claude Code session for a large refactor.
2. Before typing anything, I check my statusline to see how much of my 5-hour quota is left, so I know whether to start now or wait for the reset.
3. Today: the Sessions: line shows nothing at all, because rate_limits is still null — I have to either guess or send a throwaway message just to populate it.
4. With this fixed: the statusline shows my quota immediately, using the most recently known reading, and I can make an informed decision before starting.

Additional Context

I ran into this directly while building super-status, a community statusLine script that surfaces plan usage, context, cost, and session-quality metrics as labeled lines. Every field that depends on rate_limits or the cumulative token totals is correctly hidden on a fresh session (per the "never render null/undefined" design in that project), but the net effect for users is exactly what #18121 and #27915 originally set out to fix: no visibility into quota until it's arguably too late to act on it.

Related closed issues

Both of the following were closed once rate_limits shipped in v2.1.80, but neither covers the "before the first API call" timing gap described above:

| # | Issue | Status |
|---|---|---|
| 1 | #18121 — Expose rate limit/session usage data to statusLine configuration | Closed |
| 2 | #27915 — Expose rate-limit / plan quota usage in statusLine JSON input | Closed (shipped in v2.1.80) |

For reference, #27915 itself consolidated the following as duplicates of "expose rate limits to statusLine at all" (all now moot, since the field shipped) — included here so this issue isn't mistakenly re-filed as another duplicate of the same original ask:

| # | Issue | Upvotes | Status |
|---|---|---|---|
| 1 | #5621 — StatusLine should expose API usage/quota in JSON input | — | Closed (not planned) |
| 2 | #6093 — Native status line for 5h and weekly limits | — | Closed (duplicate) |
| 3 | #10527 — Display usage statistics in CLI terminal | — | Closed (duplicate) |
| 4 | #11917 — Expose usage metrics in session JSON | — | Open (stale) |
| 5 | #13585 — Add quota information access to CLI | — | Open |
| 6 | #13667 — Display Max/Pro rate limits in status line | — | Closed (duplicate) |
| 7 | #14136 — Expose plan usage/subscription limits in status line | 7 | Open |
| 8 | #15844 — Expose usage quota in status line JSON | 13 | Open |
| 9 | #18121 — Expose rate limit/session usage to statusLine | — | Closed |
| 10 | #19385 — Expose rate limit data in statusline JSON input | — | Closed (duplicate) |
| 11 | #20636 — Expose rate limit usage (session %, weekly %) to statusLine | 31 | Open |
| 12 | #22221 — Expose Max/Pro plan usage limits for status line display | — | Open |
| 13 | #23650 — Show plan usage allowance in status bar | — | Open |