[FEATURE] Expose per-model weekly rate limits in the statusLine JSON

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

The rate_limits object in the statusLine JSON exposes exactly two windows, five_hour and seven_day. This is what the statusLine docs document, and the docs are explicit that those are the only two: "Each window (five_hour, seven_day) may be independently absent."

But /usage displays more than two windows. It shows per-model weekly allowances alongside the all-models weekly window, including a Sonnet-only row and server-labeled per-model buckets. That a model-scoped weekly limit is a real, separately-consumable thing is already established on this repo by #73820 ("Both weekly rate limit and Fable rate limit consumed while using Opus").

The result is that a status line can be actively misleading. On a plan with a model-scoped weekly allowance, a status line reading 7d: 41% looks comfortable while the model actually in use is near its own separate cap, and the user gets cut off with no warning from the HUD they built precisely to avoid that. The all-models number does not predict the per-model one, so there is no way to derive or approximate the missing value from what is exposed.

There is no programmatic way to close the gap. /usage is interactive only and cannot be called from a script or hook, and the per-model windows are not in the hook payload either.

Proposed Solution

Extend the existing rate_limits object with the per-model weekly windows that /usage already computes and renders. A server-labeled array avoids hard-coding model names into the schema, so new models need no further schema changes:

{
  "rate_limits": {
    "five_hour":  { "used_percentage": 23.5, "resets_at": 1738425600 },
    "seven_day":  { "used_percentage": 41.2, "resets_at": 1738857600 },
    "model_scoped": [
      { "display_name": "Fable", "used_percentage": 62.0, "resets_at": 1738857600 }
    ]
  }
}

Same conventions as the existing windows: used_percentage 0-100, resets_at in Unix epoch seconds, and the whole key absent when there is nothing to report, so jq -r '.rate_limits.model_scoped // empty' degrades gracefully.

This is purely additive. Scripts that only read five_hour and seven_day are unaffected.

Why this should be low-effort

The data already reaches the client. /usage renders these exact rows today, so this is a matter of forwarding values the session already holds into the statusLine payload, not fetching anything new.

This is the same shape of request as #18121, which shipped the current rate_limits object in v2.1.80. That issue solved "the status line cannot see plan usage at all." This one covers the windows that were left out.

Environment

• Claude Code 2.1.233
• macOS 26.5.2 (build 25F84)
• Claude.ai subscriber, custom statusLine command script