Statusline: expose per-model rate limit usage in rate_limits (e.g. separate Opus/Fable windows)

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 statusline stdin JSON only exposes aggregate rate limit windows:

"rate_limits": {
"five_hour": { "used_percentage": ..., "resets_at": ... },
"seven_day": { "used_percentage": ..., "resets_at": ... }
}

However, Claude.ai subscription plans have per-model limits — e.g. Opus has its own weekly cap separate from the overall limit, and Fable 5 has its own usage limits distinct from Sonnet/Opus/Haiku. The /usage screen already displays these separately, so the data exists client-side, but a custom statusline script can't access it. When switching between models, the aggregate percentages don't tell me how close I am to the limit of the model I'm actually using.

Proposed Solution

Extend the rate_limits object with per-model (or per-limit-bucket) entries, mirroring what /usage shows. For example:

"rate_limits": {
"five_hour": { "used_percentage": 23.5, "resets_at": 1738425600 },
"seven_day": { "used_percentage": 41.2, "resets_at": 1738857600 },
"per_model": {
"opus": { "seven_day": { "used_percentage": 60.0, "resets_at": 1738857600 } },
"fable": { "seven_day": { "used_percentage": 12.0, "resets_at": 1738857600 } }
}
}

Exact shape doesn't matter — even just the limit bucket that applies to the current session model (rate_limits.current_model) would cover the main use case: showing "how much of this model's quota is left" in the statusline.

Alternative Solutions

• Parsing /usage output — not scriptable.
• Estimating from transcript files (ccusage-style) — approximate and doesn't reflect actual server-side limit buckets.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

I run a Max plan subscription and switch between models depending on the task: Fable 5 for hard debugging/architecture work, Sonnet for routine edits. These models have separate usage limits — Fable has its own quota distinct from the Sonnet/Opus/Haiku pool.

A typical day:

1. I start a session on Fable 5 to debug a tricky race condition. My statusline shows 5h: 30% | 7d: 45% from rate_limits.
2. Those numbers are the aggregate windows, mostly driven by heavy Sonnet usage earlier in the week. What I actually need to know is: how much of my Fable quota is left? — because that's the scarce resource for this task.
3. I open /usage to check. It shows the per-model breakdown: overall weekly at 45%, but Fable-specific usage already at 80%.
4. This means my statusline was giving me false comfort. Had I known Fable was at 80%, I would have saved it for the hardest part of the debugging and done the exploratory grep/read work on Sonnet first.
5. This actually happened to me: I only caught it because I happened to open /usage mid-session — the statusline had shown nothing alarming. At that point I had to stop, split the task in two, defer the deep-analysis half until closer to the reset, and reshuffle the rest of my day around a quota I could have been tracking passively all along.

With per-model rate limit data in the statusline stdin JSON (or even just the limit bucket applying to the current session's model), my statusline script could show e.g. [Fable] this-model 7d: 80% ⚠ | all: 45% — and I'd budget my model choice proactively instead of discovering the limit by luck. Checking /usage manually before every model switch is the current workaround, but the whole point of the statusline is to make exactly this kind of session state passively visible.