Usage-limits UI: state real numbers and real dates — a boost with a rolling end-date is not a boost

Status Open
Maintainer reply None cached
Activity 1 comment · opened Sep 1, 2026

What the UI currently says

"Your limits are temporarily boosted. Your weekly Claude Code limit is 50% higher through September 13."

(Max 20x plan · Claude Code v2.1.252 · linux)

Three problems

  1. No baseline is stated. "50% higher" than an unstated number, expiring into another unstated number. A user planning multi-week work cannot derive their post–September-13 capacity from this screen, and cannot tell whether "Max (20x)" is defined against the boosted or unboosted level.
  2. The end-date rolls forward. This is not the first cycle — the expiry has moved repeatedly, each month announcing elevated capacity with a fresh deadline. A "temporary" allowance that renews indefinitely is the de facto baseline, and displaying the baseline as an expiring bonus manufactures a recurring planning cliff — and recurring anxiety — with no compensating benefit to the user.
  3. The framing is persuasive where it should be calibrated. "Temporarily boosted" is the loss-aversion rotation of "your limit changes on September 14." Loss-aversion framing is an emotional lever, not an informational one; deploying it on this audience underestimates them.

Why the bar is higher here

This screen is not a marketing surface — it is an instrument panel. Users make daily commitments of work, money, and trust against it, inside a tool that holds their private material. An instrument panel owes its reader calibration: numbers, dates, plain causes. Persuasion techniques inside an instrument panel teach users they cannot read the product literally — a strange lesson from the company whose differentiator is being the lab you can trust.

How I suspect this happened — a charitable reconstruction

I doubt there was a villain. More likely: infra set a genuine temporary uplift for the Fable 5 launch window (Fable is expensive; that boost was probably real). Someone drafted the banner as marketing copy, and review optimised it for two things — don't promise permanence ("temporarily") and sound generous ("50% higher"). Nobody in that chain owned the question "can a user compute their post-window number from this screen?", because nobody classified the surface as an instrument. Then the window kept extending — each extension reading internally as good news — and the rolling countdown emerged from copy nobody revisited. If that reconstruction is roughly right, the fix is organisational and cheap: assign this screen the calibration standard, not the marketing one.

What it costs you

I am a Max 20x subscriber. Every month this banner makes me re-run the Claude-versus-ChatGPT decision, because I cannot price what I'm actually buying past the next rolling date. Uncertainty you manufacture is churn pressure you pay for.

Requests

  1. State the numbers on this screen: current weekly limit, the limit after the boost window, and the changeover date — not behind a "learn more" link.
  2. Define the plan multiplier against a stated baseline.
  3. If the boost renews every cycle, drop the countdown and display it as what it is: the standing allowance.
  4. Adopt plain framing for limit changes generally — e.g. "From September 14 your weekly limit will be X (currently Y)."

Grateful for the capacity itself. This is solely about being able to plan against it, and about what kind of reading this screen deserves to invite.

Refs: in-product feedback 7307e456-eeb0-4c62-865b-c6a63e4c2642

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗