"Approaching weekly usage limit" banner fires at 54% weekly usage

Status Open
Reported on v2.1.271
Maintainer reply None cached
Activity 3 comments · opened Sep 16, 2026

Environment

  • Claude desktop app 2.110.0, Windows 11 (MSIX install)
  • Bundled Claude Code 2.1.271
  • Plan: Max (20x)

What happens

A banner appears above the composer reading:

Approaching weekly usage limit — Resets Sun, Sep 20, 2:00 PM

At the same moment, the plan usage popup shows:

| Window | Used | Resets |
|---|---|---|
| 5-hour limit | 4% | in 4 hr 16 min |
| Weekly, all models | 54% | Sun 2:00 PM |
| Weekly, Fable | 56% | Sun 2:00 PM |

The weekly window had roughly 4.5 days left at the time.

Why this is a problem

The banner and the popup disagree, and the banner gives the user nothing to
reconcile them with. 54% used with two thirds of the week still to go does not
read as "approaching" a limit. There is no number in the banner, no indication
of which window it refers to, and no way to dismiss it or turn it off.

What I found in the code

In claude-code 2.1.271 the warning message is built by a function equivalent to:

return [
n ? You've used ${n}% of your ${label} : Approaching ${label},
resets && resets ${resets},
hint
].filter(Boolean).join(" · ")

where n = utilization ? Math.floor(utilization * 100) : undefined.

So the bare "Approaching <label>" form is only produced when utilization is
absent. When it is present the message carries the percentage instead.

There is also a display gate that drops any warning whose utilization is below
0.7:

if (status === "allowed_warning") {
if (util !== undefined && util < 0.7) return null
...
}

The local pace rules (utilization 0.75/0.5/0.25 against 60%/35%/15% of the
window elapsed) always attach a numeric utilization, and bail out early if it is
missing. So they cannot produce this banner at 54%: they would either render the
percentage or be suppressed by the 0.7 gate.

That leaves the server-driven path, which reads
anthropic-ratelimit-unified-{5h,7d,overage}-surpassed-threshold and passes
through utilization as-is, so it can be undefined. This looks like the source.

If that is right, the server is flagging a threshold without sending a matching
utilization value, which both bypasses the 0.7 display gate and strips the
number out of the message.

Suggested fixes, any one of which would help

  1. Send the utilization alongside the surpassed-threshold flag so the banner

says "You've used 54% of your weekly limit" and matches the popup.

  1. Suppress the bare "approaching" form when the client already knows and

displays the real percentage.

  1. Add an opt-out setting, along the lines of the existing

skipWorkflowUsageWarning key in settings.json.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗