How the number is worked out
What the luck score means, what the model assumes, and what it deliberately does not cover.
The problem
Claude Code refills your weekly usage limit at a fixed weekday and time tied to your account. Anthropic's blanket resets land whenever Anthropic decides. The two clocks are unrelated, so the same announcement is worth wildly different amounts to different people.
A reset announced on a Friday afternoon is worth a few hours to someone whose own refill is Friday evening, and nearly two full days of extra runway to someone who refills on Sunday morning. Same announcement, very different value.
The model
A reset landing p hours into your 168-hour window is worth the smaller of two things.
1. What you get back
You can only be refunded quota you had already spent. A reset an hour after your normal refill gives you nothing, because your tank was already full.
spent(p) = min(1, p / paceHours)
2. What you can still spend
A refund is worthless if your normal refill arrives before you can burn it. Your five-hour limit caps how fast you can draw down, so runway matters.
runway(p) = min(1, (168 − p) / burnHours)
The value to you is min(spent, runway), in weekly caps. Summed across
every tracked reset, that total drives the curve, the dial and the percentile.
The function is a tent. It peaks where the two lines cross, which on every usage profile lands on day four or five of your cycle: late enough that you have burned real quota, early enough that you can still spend the refund.
The two knobs
paceHours is how deep into the week you would normally exhaust your cap. burnHours is how long hard, sustained work takes to burn a full cap from zero.
| Profile | paceHours | burnHours | Peak |
|---|---|---|---|
| Casual | 168 | 96 | day 4.5 |
| Balanced | 120 | 48 | day 5.0 |
| Heavy | 72 | 30 | day 4.9 |
The ranking barely moves across that whole range, because the peak stays near day five regardless. There is a test in the repository asserting that the best day is identical across all three profiles, weighted and unweighted.
Weighting
Not every reset reached everyone. The 19 June 2026 fix touched about 3% of Max and Pro users; the 20 June follow-up touched everybody. Each event carries a weight for the share of the paid base it plausibly reached, and gains scale by it.
What this does not model
- Whether a reset also shifted your cycle date. Users reported this after the 27 February 2026 reset, and a shifted cycle can cost allowance rather than grant it.
- Resets that did not fully zero the counter. Several were reported as partial.
- Five-hour limits. They roll on a short enough window that scheduling luck barely applies.
- Whether you were awake. A 04:00 reset is worth less if you are asleep, but that is your time zone's problem, not a modelling one.
Time precision
Official posts on X embed a UTC timestamp in the post ID, so those events are exact to the second. Blog posts and support articles often published only a date; those default to 12:00 UTC and are labelled time assumed wherever they appear. Eleven tracked weekly resets drive the statistics, most of them exact.
What is collected
When you check a window, the site stores the slot itself — weekday, time, time zone, usage profile, plan — so it can eventually show the real distribution of reset windows instead of a modelled one. It does not store your IP address. Uniqueness comes from a random identifier your browser keeps locally, combined with your address and a secret salt, then hashed one way. Clear your site data and the link is gone. The aggregate stays hidden until at least 50 people have submitted, so no single bucket can identify anyone.
Reset reports are separate, held for review, and never enter the statistics until a human confirms them against a primary source.
Sources
Every entry links to its origin: Anthropic's engineering blog, support articles, official developer posts on X, or preserved mirrors where the original is no longer reachable. The full dataset is available as JSON.