Anthropic’s Claude Max Plans Are Misleading at Best
Anthropic sells Claude Max as a multiple of Pro. Max 5x is $100 a month and Max 20x is $200. Anthropic doesn’t publish how many tokens either plan buys, so the only way to track usage is Anthropic’s own meter which I personally find inconsistent at best, and programmatically diminishing at worst.
There are multiple issues on Anthropic’s Claude Code GitHub repository describing discrepancies between what subscribers paid for and what they got. One user saw consumption double overnight with no change on their side. Several of the people reporting this measured it themselves from Claude Code’s local logs, and users are using proxies to capture exact token spends for testing.
There are also at least three class action lawsuits against Anthropic over these plans. Kahn v. Anthropic, filed in June, alleges that “the actual usage provided by the Max 5x and Max 20x plans is far below the advertised amount of usage.” [1] Pascual v. Anthropic alleges Anthropic reduced the value of Pro and Max through backend changes between March and May 2026. [2] A third suit, filed September 8, alleges the 5x and 20x figures only apply to the five-hour session window, not the weekly limit subscribers actually run into. [3]
The main issue here is that customers can’t check what they bought without reverse-engineering the usage meter. Here’s a breakdown of what the posters found and tracked.
| Issue | Date | Plan | What they found |
|---|---|---|---|
| #79773 | Jul 21 | Max 20x | Weekly limit draining at the 5x rate or faster |
| #92576 | Sep 7 | Max 5x | Fable blocked behind paid credits despite the included allowance |
| #92834 | Sep 8 | — | “You’ve hit your weekly limit” while /usage showed 0% |
| #92906 | Sep 8 | Max 5x | Fable meter jumped 0% → ~60% after two short chats |
| #93596 | Sep 11 | Max 5x | Thinking on ~100% of requests, 2–7× output tokens, no client change |
| #97467 | Sep 26 | Pro → Max 5x | ~840k tokens per 1% of the week, vs ~3M expected. App still says “Pro” |
How people are tracking it
The token count comes from Claude Code’s local logs so this only works for Claude Code, including the Code tab in the desktop app, because it’s the only Claude product that keeps a local log of tokens. Chats on claude.ai and the mobile app don’t.
Every session is saved as a JSONL file under ~/.claude/projects/. Each response records message.usage, which lists input tokens, output tokens, cache writes, cache reads, and thinking tokens. One response is written to the log as several lines carrying the same usage figures, so totals have to be deduplicated by requestId. Skipping that step roughly doubles the count. At least one poster made that mistake and corrected it publicly. [#92201]
To calculate what 1% of your limit costs, divide the tokens you used by how many points the meter moved. If 5.9M tokens move the weekly guage from 0% to 7%, 1% is about 842,000 tokens.
The meter reading comes from the cachedUsageUtilization value Claude Code stores in ~/.claude.json.
Some posters also weight the token types by Anthropic’s API prices: input at 1x, cache writes at 1.25x, cache reads at 0.1x, and output at 5x. But that’s just a guess. Anthropic of course doesn’t publish its weighting, that would be too transparent.
How you can track it
I encourage all users to track their real world usage just for visibility. The simplest option is ccusage, an open source tool that reads the same local logs. Running npx ccusage@latest weekly totals tokens by week. ccusage blocks groups them into Claude Code’s five-hour windows. You can track your /usage percentage right after a weekly reset and again a few days later to compare it with ccusage’s total for the same period.
The logs only cover the machine they’re on, so usage from other computers, claude.ai, or the mobile app won’t appear unless you manually aggregate them.
What they found
| Issue | Plan | Finding |
|---|---|---|
| #97467 | Pro → Max 5x | 1% of the week cost 612k tokens on Pro, and 840k after upgrading. On Max 5x it should be about 3M |
| #92201 | Max, Opus 5 | 154.5M weighted tokens in one August week without hitting the limit. In September, 35.5M used 63% of the week |
| #97074 | Max, Opus 5 | The same work used 1.8x more of the five-hour limit when run from a script (claude -p) than in the app |
| #91623 | Max 20x | Fable 5.1 produced twice the output of Fable 5. The weekly meter went from 0% to 88% in 22 hours |
| #93596 | Max 5x | Output per request rose 2–7x overnight on Sep 11, with no change on the user’s side |
| #72872 | Pro, 5x, 20x | After upgrading from 5x to 20x, they used 1.3x more but ran near the weekly limit more often, not less |
None of this has been independently verified. It comes from GitHub issues and their comments. But the lawsuits show that the complaints were serious enough for attorneys to file.
What else can’t we track
The most detailed September report tracks the amount of work behind each request changing. A Max 5x subscriber runs Claude Code on two machines, using Opus 5 at the xhigh effort setting, which they had used for about two months. Between 01:30 and 03:30 UTC on September 11, every active session on both machines started behaving differently. [4] Before the change, somewhere between 30% and 67% of requests included a thinking block, and output averaged 250 to 960 tokens per request. After it, 95% to 100% of requests included thinking, and output rose to 2,500 to 3,000 tokens per request in the first hours. A clear example of the API changing without any user involvement.
The user measured this from Claude Code’s transcript files. They took output tokens per request, removed duplicates by request ID, excluded subagents, and broke the results out by hour and by session. The client version was 2.1.260 on both machines when it started. The model, the effort setting, the sessions, and the kind of work hadn’t changed. No settings, hooks, or project instructions had been edited in the 19 hours before. [4]
A full five-hour window normally used 40% to 50% of their session limit. After the change, they used 24% in 36 minutes, a pace that would hit the limit in about two and a half hours. The weekly limit resets on Monday, and they usually reach it with about 2% to spare. This week they were at 97% by Friday evening, with three days still to go. [4]
A second user added their own measurements in the comments, from a very different setup: a Linux server calling Claude Code non-interactively with a fixed prompt template. Their last normal call on client 2.1.263 was on September 10, with 40 thinking tokens on a 43,000-token input. Their first abnormal call, on the same binary, was early on September 11, with 25,000 to 35,000 thinking tokens per request. [4]
They also ran two client versions side by side, at the same minute, on the same prompt.
| Client | Thinking tokens | Output tokens | Wall time |
|---|---|---|---|
| 2.1.237 | 0 | 25,148 | 5.4 min |
| 2.1.268 | 16,128 | 48,586 | 10.3 min |
The first results claim the same client started behaving differently overnight, which suggests a change on Anthropic’s side, possibly rolled out in phases. The second says different client versions behave differently on the same day, which suggests the client plays a part too. A server-side change to how adaptive thinking responds to effort settings could interact with whatever each client version sends. But the important finding is that ultimately the user has no control, no stability over how Anthropic determines their adaptive thinking, clients, and ultimately tokens to be generated. This is why vibe coding isn’t stable. It’s why so many fight with the tools just to try and achieve reliable output disguised as cost savings.
It also represents an auditability problem. Thinking tokens are tokens the customer didn’t write and often doesn’t read. If the service decides to do more of that work, the customer pays for it, and finds out about it only when the meter runs out early. The user’s request in the report was modest: announce this kind of change, and provide a way to opt out. [4]
How can they fix it
When the meter is wrong, the customer has almost no independent way to show it. The cases above were only caught because a small number of technical users kept careful logs. None of this requires Anthropic to give away more usage. It requires making the usage that’s already sold visible and verifiable.
A published baseline would be a start. It doesn’t have to be one fixed token count. It could be a reference workload per plan, with the model, effort, and caching assumptions stated, so a customer can tell whether “5x” still means what it did last week.
A per-request quota record would do more. Claude Code already writes token counts to local transcripts. If each entry also recorded how much of the session and weekly quota that request consumed, the reverse engineering above would become a simple lookup.
A change log for server-side behavior that affects consumption would be welcomed. If the frequency or length of reasoning at a given effort level changes, subscribers should be told, the same way they’re told about a new client version.
Flat-price subscriptions for metered products are already quite common but the arrangement only works if the customer can trust the usage tracker. Right now, with Claude Max, the evidence suggests that trust has to be taken on faith, and that it is occasionally misplaced.
References
1. Anthropic hit with lawsuit over its Claude Max usage limits. Engadget, 2026-06-15. Accessed 2026-09-28.
2. Anthropic class action alleges Claude subscribers paid for degraded AI service. Top Class Actions, 2026-08-05. Pascual v. Anthropic PBC, No. 3:26-cv-07699 (N.D. Cal.). Accessed 2026-09-28.
3. Anthropic users are taking the company to court over Max subscription terms. Engadget, 2026-09-09. Accessed 2026-09-28.
4. Opus 5 at xhigh: thinking on ~100% of requests and 2-7x output tokens per request since ~02:30 UTC 11 Sep, with no client or settings change. anthropics/claude-code, issue #93596, 2026-09-11. Accessed 2026-09-28.
5. [BUG] Weekly usage limit not updated after upgrade from Pro to Max 20x — account still behaves as Pro/5x. anthropics/claude-code, issue #58101, 2026-05-11. Accessed 2026-09-28.
6. [BUG] Weekly usage limits not updated after upgrade from Max 5x to Max 20x — account still enforcing 5x caps. anthropics/claude-code, issue #76093, 2026-07-09. Accessed 2026-09-28.
7. [BUG] Max 20x upgrade not reflected in weekly limits — depleting at Max 5x rate or worse (upgraded July 16, 2026). anthropics/claude-code, issue #79773, 2026-07-21. Accessed 2026-09-28.
8. [Bug] Fable 5.1 incorrectly blocked by usage credits despite included Max plan allowance. anthropics/claude-code, issue #92576, 2026-09-07. Accessed 2026-09-28.
9. You’ve hit your weekly limit · resets Sep 15 at 7pm. anthropics/claude-code, issue #92834, 2026-09-08. Accessed 2026-09-28.
10. [BUG] Weekly usage jumped from 0% to ~60% after two short conversations; “Approaching weekly limit” banner contradicts displayed 27%/13%. anthropics/claude-code, issue #92906, 2026-09-08. Accessed 2026-09-28.
11. [BUG] Paid Max 5x, weekly limit still enforced at Pro size (2nd paid week, support escalation unanswered for 5 days). anthropics/claude-code, issue #97467, 2026-09-26. Accessed 2026-09-28.
12. [Bug] Rate limit consumption disproportionate to measured token usage for opus-5-1m with prompt caching. anthropics/claude-code, issue #92201, 2026-09-04. Accessed 2026-09-28.
13. ccusage. Open source usage analyzer for Claude Code and other coding agent CLIs. GitHub. Accessed 2026-09-28.
14. [BUG] Headless claude -p (entrypoint sdk-cli) uses ~1.8× more of the 5-hour window per token than interactive cli, same workload. anthropics/claude-code, issue #97074, 2026-09-25. Accessed 2026-09-28.
15. Max 20x plan drained in ~22 hours after Fable 5.1; 5.1 emits 2x the output per turn of Fable 5. anthropics/claude-code, issue #91623, 2026-09-02. Accessed 2026-09-28.
16. Max 20x weekly cap does not scale proportionally with session multiplier. anthropics/claude-code, issue #72872, 2026-07-01. Accessed 2026-09-28.