Usage-limits UI: state real numbers and real dates — a boost with a rolling end-date is not a boost
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
- 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.
- 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.
- 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
- 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.
- Define the plan multiplier against a stated baseline.
- If the boost renews every cycle, drop the countdown and display it as what it is: the standing allowance.
- 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
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗