Expose model-scoped weekly usage buckets (Fable / Opus / Sonnet) in the statusLine JSON payload

What I'm trying to do

Show per-model usage on my custom status line — specifically, how much of my weekly limit a given model (e.g. Fable 5) has consumed, so I can see it at a glance without opening /usage.

Current behavior

The rate_limits object passed to a statusLine command contains only two model-agnostic buckets. Verified empirically on v2.1.211 by teeing the status line's stdin to a file:

{
  "five_hour": { "used_percentage": 85, "resets_at": 1784229600 },
  "seven_day": { "used_percentage": 40, "resets_at": 1784275200 }
}

This matches the documented schema, which declares rate_limits as strictly { five_hour?, seven_day? }.

The CLI tracks more granular buckets internally, though — the binary carries these keys:

• seven_day_opus
• seven_day_sonnet
• seven_day_overage_included
• seven_day_oauth_apps

…which is what /usage renders as "Current week (all models)" vs. "Current week (Sonnet only)". Because the status line payload is a strict projection over five_hour and seven_day, those keys are dropped before a status line command ever sees them.

The data already ships to another first-party client

Claude Desktop's "Plan usage limits" panel (plan: Max 20x) shows a distinct, separately-labeled Fable weekly bucket as a percentage, alongside the aggregate one:

Plan usage limits   Max (20x)

Current session                             0% used
  Resets in 4 hr 59 min

Weekly limits
  All models                               40% used
    Resets in 12 hr 39 min
  Fable                                    68% used
    Resets in 12 hr 39 min

Two things this confirms:

1. seven_day in the status line payload is the "All models" bucket. It read 40%, matching the panel exactly — same value, same window.
2. The Fable bucket is a genuinely separate number, not an existing bucket relabeled. At 68% it diverges from "All models" at 40%, while sharing the same reset window (12 hr 39 min), i.e. the same weekly cycle.

So per-model weekly percentages exist server-side and are already surfaced to users in a first-party client. This isn't a request for new measurement — only for Claude Code to pass through what the platform already computes and displays elsewhere.

Notably, Claude Code's binary contains no seven_day_fable key at all (the full set of seven-day keys is listed above). So for Fable the gap looks wider than a status line projection issue: the CLI doesn't appear to model that bucket anywhere, which would explain why /usage doesn't break it out either. If the usage endpoint returns a Fable bucket that the CLI's schema silently drops, that seems worth fixing independently of the status line.

Requested behavior

Pass the model-scoped buckets through to the statusLine JSON payload, e.g.:

"rate_limits": {
  "five_hour":        { "used_percentage": 85, "resets_at": 1784229600 },
  "seven_day":        { "used_percentage": 40, "resets_at": 1784275200 },
  "seven_day_fable":  { "used_percentage": 55, "resets_at": 1784275200 },
  "seven_day_opus":   { "used_percentage": 62, "resets_at": 1784275200 },
  "seven_day_sonnet": { "used_percentage": 12, "resets_at": 1784275200 }
}

All sub-objects would stay optional, so existing status line scripts are unaffected — they simply keep reading five_hour / seven_day and ignore the new keys. Consumers that want per-model attribution could then do:

jq -r '.rate_limits.seven_day_fable.used_percentage // empty'

A generic, forward-compatible shape would be even better, so new models don't each require a new hardcoded key:

"rate_limits": {
  "five_hour": { "used_percentage": 85, "resets_at": 1784229600 },
  "seven_day": { "used_percentage": 40, "resets_at": 1784275200 },
  "seven_day_by_model": {
    "fable":  { "used_percentage": 55, "resets_at": 1784275200 },
    "opus":   { "used_percentage": 62, "resets_at": 1784275200 },
    "sonnet": { "used_percentage": 12, "resets_at": 1784275200 }
  }
}

Why it matters

When several models share one weekly ceiling, the aggregate seven_day percentage doesn't tell you which model is spending it. Claude Desktop shows this breakdown; Claude Code's status line can't. The status line is the natural place for an at-a-glance number, and the platform already computes it.

The only workaround today is scraping the private usage endpoint from the status line command, which means an undocumented API, an auth-token lift, and network latency on every status line repaint. Not a good trade for a number that's already being rendered in another client.

Environment

• Claude Code 2.1.211
• macOS (darwin 25.5.0)
• statusLine type command, custom bash script

---

_{Note: statements about internal key names come from running strings over the compiled binary, not from source, so treat them as indicative rather than authoritative. The Claude Desktop behavior is a direct user observation.}