[BUG] Weekly usage counter appears not to reset; conflicting reset boundaries reported in same view (Max 20x)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
On a Max 20x account the weekly usage counter appears not to have reset at the Friday boundary, and the weekly meter subsequently advanced far faster than activity accounts for.
Observed
Weekly reset occurred at approximately 22:00 BST on Friday 24 July 2026. At 23:26 BST on Saturday 25 July, twenty five and a half hours later, the "All models" weekly bar read 58% used.
Activity across that entire window, reconstructed from timestamped filesystem records: seven files produced by scheduled engines between 06:14 and 08:23, two folder-sync touches, and twenty four hourly transcript-routing runs of which every single one logged a null result. No new conversations were started. One short mobile conversation on an unrelated topic.
Subsequent readings, all screenshotted below:
| Date | Time (BST) | Weekly | Session |
|---|---|---|---|
| Sat 25 Jul | 23:26 | 58% | 3% |
| Sun 26 Jul | 00:39 | 63% | 20% |
| Sun 26 Jul | 02:04 | 65% | 26% |
| Sun 26 Jul | 02:25 | 68% | 37% |
| Sun 26 Jul | 03:38 | 69% | 40% |
| Sun 26 Jul | 11:48 | 72% | 4% |
| Sun 26 Jul | 12:29 | 73% | 5% |
The 58% to 63% rise occurred across seventy three minutes in which the only activity was a text conversation with the in-app support assistant about this fault.
Additional interface inconsistencies
- The reset boundary is reported as both "Fri 9:59 PM" and "Fri 10:00 PM" across screenshots. In the 02:25 capture the two rows disagree within a single view: "All models" reads "Resets Fri 10:00 PM" while "Fable" immediately beneath reads "Resets Fri 9:59 PM". See the fourth screenshot below (02:25).
- The Fable weekly meter moved from an explicit "You haven't used Fable yet, 0% used" at 02:04 to "3% used" at 02:25, without Fable being invoked.
- The weekly meter advanced one percentage point across forty one minutes while the five-hour session meter stood at 4% to 5%.
- A forced re-authentication banner appeared mid-sequence.
Evidence
Meter readings were captured contemporaneously by screenshot as the fault unfolded. The activity record was read separately from timestamped filesystem records afterwards. The two are independent of each other and neither rests on recollection.
Full evidence report available on request, including the complete hour-by-hour activity reconstruction and appendices.
Related
Same family, reset boundary behaviour not matching the displayed boundary: #69904 (open), #64913 (closed), #69451 (closed). Also #49599, #51222.
This report differs from the above in that it evidences weekly consumption occurring with no corresponding account activity, reconstructed from timestamped filesystem records, in addition to the reset boundary inconsistency.
Reported through official support first
This was raised through the in-app support assistant before being filed here. Three support conversations were opened on 26 July 2026. Each was escalated to human support with a confirmation that an agent would respond by email. No response has been received on any of them. One of the three was ended by the assistant mid-conversation without resolution.
Support conversation IDs, for internal lookup:
- 215475233598146
- 215475234869522
- 215475236149873
Filing here because the official channel has not produced a response.
1. Sat 25 Jul, 23:26 BST — weekly 58%, session 3%. Twenty five and a half hours after the reset.
<img width="1536" height="1440" alt="Sat 25 Jul 23:26 BST, weekly 58 percent, session 3 percent" src="https://github.com/user-attachments/assets/a9eb2baf-0698-4881-ad7d-1d5bbc5ea364" />
2. Sun 26 Jul, 00:39 BST — weekly 63%, session 20%.
<img width="1536" height="1440" alt="Sun 26 Jul 00:39 BST, weekly 63 percent, session 20 percent" src="https://github.com/user-attachments/assets/b19026c3-cbcf-43a3-aa31-5f6d5eda24fb" />
3. Sun 26 Jul, 02:04 BST — weekly 65%, session 26%. Fable reads "You haven't used Fable yet, 0% used".
<img width="1536" height="1440" alt="Sun 26 Jul 02:04 BST, weekly 65 percent, Fable 0 percent" src="https://github.com/user-attachments/assets/af05b940-9264-4f50-b6b8-4ff7b1d05886" />
4. Sun 26 Jul, 02:25 BST — weekly 68%. Note the two conflicting reset labels in this single view: "All models" resets Fri 10:00 PM, "Fable" resets Fri 9:59 PM. Fable has also moved to 3% since 02:04.
<img width="1536" height="1440" alt="Sun 26 Jul 02:25 BST, conflicting reset boundaries in one view, Fable moved to 3 percent" src="https://github.com/user-attachments/assets/2367960f-2de7-495e-b46e-0f732fe24d02" />
5. Sun 26 Jul, 03:38 BST — weekly 69%, session 40%.
<img width="1536" height="1440" alt="Sun 26 Jul 03:38 BST, weekly 69 percent, session 40 percent" src="https://github.com/user-attachments/assets/7e094d42-309d-4f49-bace-0af5783c30a0" />
6. Sun 26 Jul, 11:48 BST — weekly 72%, session 4%.
<img width="1536" height="1440" alt="Sun 26 Jul 11:48 BST, weekly 72 percent, session 4 percent" src="https://github.com/user-attachments/assets/13ec42ca-f797-4733-86a3-40fa8d217090" />
7. Sun 26 Jul, 12:29 BST — weekly 73%, session 5%. One further point consumed in forty one minutes with the session meter at 5%.
<img width="1536" height="1440" alt="Sun 26 Jul 12:29 BST, weekly 73 percent, session 5 percent" src="https://github.com/user-attachments/assets/8922e907-1758-4439-8e6b-105cbc098409" />
What Should Happen?
- The weekly usage counter should reset at the weekly boundary and should not carry a prior period's consumption across the reset.
- Weekly consumption should track actual usage. A period of near-total inactivity should not consume a substantial share of the weekly allowance.
- A single, consistent weekly reset boundary should be reported across the interface. The "All models" and "Fable" rows should not display different reset times in the same view.
- A model's weekly meter should not move from zero when that model has not been invoked.
Error Messages/Logs
Steps to Reproduce
Not reproducible on demand. Observed on a live account across a thirteen hour period, evidenced by timestamped screenshots and filesystem records.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Not applicable. Fault observed on claude.ai and the Claude desktop app, not the Claude Code CLI.
Platform
Other
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
The "Get Help" button in the Claude desktop app has also failed to open for several days during this period, so the in-app support channel had to be reached via Chrome.
3 Comments
Adding related public context, not as the same root cause but as the same account-ledger / support-routing class.
This report describes paid-plan usage meters and reset boundaries disagreeing with observed account activity, plus support conversations being routed to human follow-up without a visible response. My unresolved case is a different billing surface: manual prepaid / bulk usage-credit purchase fails or fails to commit, while automatic usage-credit reloads on the same paid billing setup keep charging successfully.
The overlap is the actionable part: Anthropic needs a single owner who can reconcile usage counters, model-specific entitlements, reset-boundary timestamps, usage-credit ledger state, auto-reload/payment events, and support/Fin routing together. Generic card-decline, top-up, or usage-limit advice cannot diagnose cases where the account ledger or entitlement view itself is inconsistent.
Privacy-sanitized public evidence hub for the related billing/ledger case:
https://coolak.github.io/anthropic-claude-billing-incident/
Owner/reconciliation matrix:
https://coolak.github.io/anthropic-claude-billing-incident/reconciliation-matrix.html
I am intentionally not posting card details, bank names, payment IDs, invoice IDs, support IDs, screenshots, raw logs, payment URLs, or private support-thread text here.
Thanks for adding this. Your case is a different fault to mine, but the pattern you describe matches exactly what happened here: escalated to a human three times, told each time that an agent would email, and no email on any of them.
Worth separating the two things though, so this issue stays actionable. The support-routing failure is why this was filed publicly. The technical fault is the substance, and it stands on its own: a weekly counter reading 58% twenty five and a half hours after a reset, in a window where the account produced seven scheduled-engine files and twenty four null checks, plus two conflicting reset boundaries displayed in a single view.
If anyone else is seeing the weekly meter advance without corresponding activity, timestamped screenshots of the usage panel are the useful thing to add here.
<img width="1536" height="1440" alt="Image" src="https://github.com/user-attachments/assets/96f4ec9b-4521-49e5-a565-922f367a0688" />
Sun 26 Jul, 21:45 BST — weekly 74%, session 2%, partway through a Sunday's work.
Follow-up: a comparison from the same account, same week.
Comparing two windows since filing, anchored on the 03:38 BST reading in image 5 above, which is where the abnormal rate stopped and normal working resumed.
| Period | Duration | Activity | Weekly meter |
|---|---|---|---|
| Sat 23:26 to Sun 03:38 BST | 4h 12m | No production work. Investigating this fault and conversing with the in-app support assistant about it. | 58% to 69%, +11 points |
| Sun 03:38 to Sun 21:45 BST | 18h 07m | Real working day: a detailed implementation plan built across several conversations, the kickoff of a second workstream lane, multiple models and agents, document output throughout. | 69% to 74%, +5 points |
Four hours of typing to a support bot consumed more than twice what a day of actual work consumed, in a quarter of the time.
For baseline: this account consumes 70 to 80 per cent of the Max 20x weekly allowance in a normal week. A normal weekday runs around 10 per cent and detailed development work more. Today is a Sunday and I am still working, so it will likely finish nearer 7 per cent, which is unremarkable for the day of the week.
This also does not fit the explanation offered by the in-app support assistant, which attributed the rise to long conversation context and cache expiry. Today involved considerably longer conversations and more context than Saturday night, at less than half the cost.
Separately, both weekly rows now read "Resets Fri 9:59 PM" consistently. The conflicting boundary shown in image 4 is no longer displaying.