[BUG] "Usage limit reached" hard-stop fires below the displayed 5-hour ceiling (~95%, not 100%)

Preflight

• This is a single bug report (the related "overload mislabeled as quota" concern is being

raised separately as a comment on #56633, not duplicated here).

• Primary evidence is the Plan-usage screenshot described below; flagged as such.

What's Wrong?

The client displayed a red "Usage limit reached · Resets at 5:10 PM" banner and blocked
the session, while the Plan-usage panel in the same view showed the 5-hour limit at 95%
— visibly short of 100%. A hard stop at 95% is either a premature enforcement threshold or a
display/enforcement mismatch near the ceiling. Either way the user was denied service they had
not exhausted.

Evidence (screenshot)

The usage panel and the block appeared simultaneously:

• Context window: 62.7k / 200.0k (31%)
• 5-hour limit: 95% · resets 57m (red bar, not full)
• Weekly · all models: 41%; Sonnet only: 19%
• Banner: "Usage limit reached · Resets at 5:10 PM"
• Banner (concurrent): "Server is temporarily limiting requests"

The 5-hour bar is clearly below 100%, yet the hard-stop banner fired.

!Plan-usage panel at the moment of the block — "Usage limit reached · Resets at 5:10 PM" fired with the 5-hour bar at 95% (not 100%), concurrent with a "Server is temporarily limiting requests" banner

Note on the client's own wording

The client already has a correct, distinct string for transient overload — observed
verbatim in #59520 as Server is temporarily limiting requests (not your usage limit) · Rate
limited. So the client is capable of distinguishing the two conditions, which makes a quota
hard-stop firing at 95% (concurrent with the overload banner) look like a threshold or
classification problem rather than a genuine quota exhaustion.

Expected vs Actual

• Expected: a "usage limit reached" hard stop corresponds to 100% of the relevant bucket.
• Actual: the hard stop fired at 95%.

Asks

1. Reconcile the displayed 5-hour percentage with the value that triggers the hard stop.
2. If a sub-100% safety buffer is intentional, document it and show the effective ceiling

rather than a percentage the user can exceed without reaching 100%.

Related issues reviewed — why this is distinct

• #50321 (open), #51219 (closed, stale), #50473 (closed, stale) — also "usage

limit fired while the bar shows headroom," but in each the bar is far from the ceiling
(0–28% consumed), pointing at stale-enforcement / tier-gate causes that do not fit a
~5%-from-ceiling case. This report is specifically about a near-100% trigger threshold.

• #56633 (open, stale), #25770 (closed), #53586 (open, stale) — the

overload-mislabeled-as-quota class. That is a separate concern, contributed as a comment on
#56633 rather than duplicated here.

• #57296 (open) — HTTP 400 "prompt is too long" mislabeled as usage limit; a different

underlying error (context overflow), same misclassification surface.