claude-code - 💡(How to fix) Fix Statusline: add a static fair-share quota indicator for Team plans [1 participants]

Summary

For Team plans, the statusline currently shows only per-user quota (e.g., 5h:81%) and not the share of the org-level rate-limit pool that fairly belongs to a single seat. Heavy users have no visible signal that they may be eating into other teammates' effective share until the org pool is empty and others get rate-limited unexpectedly.

This proposes a static fair-share indicator computed at session start, with zero live polling and zero exposure of peer activity.

Problem

On Team plans, two limits stack:

1. Per-user quota (e.g., default_claude_max_5x) — visible in statusline.
2. Org-level pool (e.g., default_raven) — shared across all seats, invisible to the user.

A heavy user can comfortably hit 5h:90% of their personal quota while having already consumed a disproportionate slice of the org pool — leaving teammates rate-limited despite their personal quotas being almost untouched. From the user side this looks like "I still have 10% left" while the real bottleneck is the org pool.

This causes:

• Surprise rate-limit errors for other teammates.
• Org admins reaching out post-hoc ("you're at 10x of your peers") with no in-product signal the user could have acted on earlier.
• Social tension that is fundamentally a UX gap, not a billing gap.

Proposed solution

Add a second, static indicator to the statusline next to the existing per-user one:

Opus 4.7 │ ctx:11% │ 5h personal:81% │ 5h fair-share:97% ⚠

Where fair-share is computed once per session/org-config change as:

fair_share_consumed_pct = (user_consumed_in_window / (org_pool_size / org_seat_count)) * 100

So fair-share: 97% means "you've consumed 97% of the slice that would fairly belong to one seat if the org pool were divided equally." Going over 100% is allowed — it just means you're now consuming someone else's potential share. The indicator turns from neutral → warning → red as it climbs.

Why this is privacy-safe and lightweight

• Numbers are fully derivable from data the user already has access to: their own consumption (already shown), org pool size (set when the contract was signed), seat count (set when the contract was signed). None of this requires reading peer-level activity.
• No live polling. Computed once per session start (or whenever org config changes). Identical caching characteristics to the existing per-user indicator.
• Indicator only — never a hard limit. It does not throttle, block, or alter routing. It is a self-regulation hint, exactly analogous to the existing personal 5h:% indicator.
• Shows only the user's own ratio, never any peer's stats. If teammate X has consumed 50% of the org pool, that fact is not exposed — only the static slice.

Why it matters

Team plans are sold on the assumption of statistical multiplexing — that average seat utilization stays well below 100% and the org pool is sized accordingly. Today, a heavy user has no UI signal of where the "fair line" lies, so the only feedback loop is reactive (admin escalation after the damage is done). A static fair-share indicator turns this into a real-time, privacy-respecting nudge without changing pricing or rate-limit semantics.

Out of scope

• No change to billing or rate-limit enforcement.
• No need for any cross-seat data flow.
• No org admin UI changes required (admin dashboard already exposes the underlying numbers).