statusLine input omits the per-model weekly rate-limit windows it already computes

What

The statusLine command receives only two rate-limit windows on stdin — rate_limits.five_hour and rate_limits.seven_day, each as {used_percentage, resets_at}. The per-model weekly windows never reach it, even though Claude Code already computes them.

Why it matters

On a plan with per-model weekly limits — or for anyone who remaps a model into the Opus/Sonnet tier via ANTHROPIC_DEFAULT_OPUS_MODEL / ANTHROPIC_DEFAULT_SONNET_MODEL — the window that actually gates the session is the per-model one, and a custom statusline has no way to show it. The only workaround is to read ~/.claude.json → cachedUsageUtilization directly, which is undocumented internal state a release can reshape without notice, so every statusline that does this is one refactor away from silently breaking.

The data already exists

The utilization payload behind GET /api/oauth/usage carries the per-model windows — seven_day_opus, seven_day_sonnet, and a model_scoped/limits[] array whose weekly_scoped entries each have a scope.model.display_name, a percent, and a resets_at. But the statusline input construction forwards only five_hour and seven_day into rate_limits, so everything model-scoped is dropped on the floor before the hook ever sees it.

Ask

Forward the per-model weekly windows into the statusLine stdin rate_limits object, in the same {used_percentage, resets_at} shape as the existing two — either as the named seven_day_opus / seven_day_sonnet keys, or as a model_scoped array carrying the label so a custom statusline can render a bar per model without reaching into internal state.