Claude Max subscribers are auditing Anthropic's meter

A Max 5x subscriber reports that between 01:30 and 03:30 UTC on September 11, every active Claude Code session on their two machines began thinking on 95% to 100% of requests, up from 30% to 67%. Their model and effort setting had not changed. The report anchors an analysis by Nooneshappy arguing that Max subscribers cannot check what they paid for without reverse-engineering Anthropic's own usage meter.

At a glance

• Max 5x costs $100 a month and Max 20x costs $200, yet Anthropic publishes no token allowance for either, so the only gauge subscribers have is Anthropic's own usage meter.
• Users divide the tokens recorded in Claude Code's local logs by how far the meter moved, and one upgrader found 1% of the week cost about 840k tokens on Max 5x, against roughly 3M expected.
• None of the reports has been independently verified, and chats on claude.ai and the mobile app leave no local token log, so that usage cannot be checked this way at all.

Weekly caps predate this dispute. According to AQ, Anthropic introduced weekly limits on August 28, 2025, and expected them to affect fewer than 5 percent of subscribers. A temporary boost of roughly 50 percent on weekly limits ended on September 13, 2026. The permanent increase of about 25 percent that replaced it on September 14 left about 17 percent less weekly headroom than in August 2026, a reduction Anthropic acknowledged.

At least three class actions now target Anthropic's Pro and Max plans

Anthropic sells Max 5x and Max 20x as multiples of Pro. Kahn v. Anthropic, filed in June, alleges that the actual usage on Max 5x and Max 20x is far below the advertised amount. Pascual v. Anthropic alleges that Anthropic reduced the value of Pro and Max through backend changes between March and May 2026.

A third suit, filed September 8, alleges that the 5x and 20x figures apply only to the five-hour session window, not to the weekly limit subscribers actually run into. The GitHub issues on the Claude Code repository are more concrete. In #79773, from July 21, a Max 20x user saw the weekly limit drain at the 5x rate or faster.

In #92834, from September 8, a user was told they had hit the weekly limit while /usage showed 0%. The same day, in #92906, a Max 5x subscriber's Fable meter jumped from 0% to about 60% after two short chats. In #92576, from September 7, another Max 5x user found Fable blocked behind paid credits even though the plan included an allowance.

After an upgrade to Max 5x, 1% of the week bought about 840k tokens instead of about 3M

The sharpest figures come from users who measured. In #97467, filed September 26, a subscriber who upgraded from Pro to Max 5x found that 1% of the week cost 612k tokens on Pro and 840k afterwards. On Max 5x it should be about 3M. The app still said Pro.

In #92201, a Max user on Opus 5 logged 154.5M weighted tokens in one August week without hitting the limit. In September, 35.5M used 63% of the week. In #97074, a Max user on Opus 5 found that the same work used 1.8x more of the five-hour limit when run from a script with claude -p than in the app.

In #91623, a Max 20x user found that Fable 5.1 produced twice the output of Fable 5, and the weekly meter went from 0% to 88% in 22 hours. In #72872, a user who moved from 5x to 20x used 1.3x more but ran near the weekly limit more often, not less.

On September 11, output on one Max 5x account rose from 250–960 tokens per request to 2,500–3,000

Issue #93596 comes from a subscriber who runs Opus 5 at the xhigh effort setting on two machines, a setup they had used for about two months. Before the change, 30% to 67% of requests included a thinking block. Afterwards, 95% to 100% did.

Output averaged 250 to 960 tokens per request before the change and rose to 2,500 to 3,000 in the first hours after it. Both machines ran client 2.1.260 when it started. No settings, hooks or project instructions had been edited in the previous 19 hours.

A full five-hour window normally used 40% to 50% of their session limit. After the change, 24% went in 36 minutes, a pace that would hit the limit in about two and a half hours. Their weekly limit resets on Monday and they usually reach it with about 2% to spare. This week it stood at 97% by Friday evening.

A second user saw thinking tokens go from 40 to as many as 35,000 on the same binary

A second user added measurements 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 on September 10, used 40 thinking tokens on a 43,000-token input. Their first abnormal call, on the same binary early on September 11, used 25,000 to 35,000 thinking tokens per request.

They then ran two client versions side by side, at the same minute, on the same prompt. Client 2.1.237 used 0 thinking tokens, 25,148 output tokens and 5.4 minutes of wall time. Client 2.1.268 used 16,128 thinking tokens, 48,586 output tokens and 10.3 minutes. The write-up reads the first result as a change on Anthropic's side, possibly rolled out in phases, and the second as a sign that the client plays a part too.

Claude Code's local logs let you work out what 1% of the week costs

The method only works for Claude Code, including the Code tab in the desktop app, because no other Claude product keeps a local token log. Each session is a JSONL file under ~/.claude/projects/, and each response records message.usage: input, output, cache write, cache read and thinking tokens. One response is written as several lines carrying the same figures, so you have to deduplicate totals by requestId. If you skip that step, the count roughly doubles.

Next, divide the token total by how far the meter moved. Claude Code stores that reading as cachedUsageUtilization in ~/.claude.json. If 5.9M tokens move the weekly gauge from 0% to 7%, 1% is about 842,000 tokens. Think of a taxi meter that shows only a percentage bar: you count the kilometres yourself and work out the rate. Some posters weight token types by API prices: input 1x, cache writes 1.25x, cache reads 0.1x, output 5x.

The simplest tool is ccusage, which is open source and reads the same logs. Running npx ccusage@latest weekly totals tokens by week, and ccusage blocks groups them into five-hour windows. Check /usage right after a weekly reset and again a few days later, then compare the two with ccusage's total for the same period. The logs only cover the machine they sit on.

The write-up is open about its limits. None of this has been independently verified, the API-price weighting is a guess because Anthropic does not publish its own, and the evidence comes from a few technical users who kept careful logs. In our view, the weak point is the design: only Anthropic's meter can settle a dispute, even though Claude Code already writes token counts locally and would need just one more field per request to make them checkable.

Baseline, quota record, change log

The write-up asks Anthropic for three fixes. The first is a reference workload per plan, with the model, effort and caching assumptions stated. The second is a per-request quota figure in Claude Code's transcripts. The third is notice of any server-side change that affects consumption. The #93596 reporter asked only for such changes to be announced, with a way to opt out. Nothing has been said yet about whether Anthropic will adopt any of these, or when the three suits will be decided.