[BUG] Inconsistent and Undisclosed Quota Accounting Changes in Claude Max Plan. Legal liability claim ready.

@argosdevo-svg : I applaud the analysis and the detailed effort. If I had not been previously demotivated/demoralized by Anthropic's lack of responsiveness, I would have done something similar. Please note that, as of this writing, the links to claude-thinking-audit tool are broken in your initial post: https://github.com/user/claude-thinking-audit should be https://github.com/argosdevo-svg/claude-thinking-audit.

Another factor to consider: was the 5-minute cache warm when the requests were made? My own experimentation shows that far less quota is consumed if I issue a new prompt within 5 minutes of the end Claude's previous work cycle (final assistant message in agentic workflow). While this is an inconvenient pattern of use, it has made a huge difference in the number of user prompts that I can issue in a given 5-hour period. Basically, treat Claude Code like a real-time strategy game which needs constant attention and response. Only take longer than 5 minutes to write a user message after a compaction or at the start of a new session, when the cache is already busted/cold and there are fewer tokens in the window. That said, I do completely agree that Anthropic is violating its own advertised limits, regardless of how Claude Code is being used.

Awesome observation and thank you for pointing out the link was broken!

To test this hypothesis with my dataset, I plan to:

1) Compute “time since last assistant message” for each request.
2) Bucket requests into <5 min vs ≥5 min.
3) Compare median tokens‑per‑1% quota and burn rates across buckets.
4) Treat compaction events and new sessions as cold‑start boundaries.

Even if a cache effect exists, it would still need to be documented and reflected in the advertised “5‑hour window” and “20x usage” claims. If caching materially changes quota cost, the behavior should be deterministic and disclosed.

Cache-Warmth Hypothesis - Tested

Thanks @emcd for the observation about cache warmth affecting quota burn. It's a reasonable hypothesis given Anthropic's documented 5-minute cache TTL.

I ran the analysis on my dataset to check if prompt timing correlates with quota cost:

Results from 3,429 quota samples + 8,444 audit samples:

Cold/Warm quota delta ratio 1.08x

Correlation (gap_minutes vs quota_delta) 0.024

Cache hit rate <5 min gap 97.7%

Cache hit rate >30 min gap 93.8%

What this suggests for my specific usage pattern:

The cache appears to stay warm even during longer gaps - hit rates remain 93%+ across all time buckets. The quota cost difference between "warm" and "cold" requests is negligible (1.08x).

This doesn't mean the cache effect doesn't exist in general - it may well matter for different usage patterns (longer idle periods, session restarts, compactions). But for my dataset, it doesn't appear to explain the 6x variance I observed.

@emcd's core point stands though: even if caching were the explanation, Anthropic should document how it affects the advertised "20x usage" and "5-hour window" claims. Users shouldn't need to reverse-engineer optimal prompting cadence.

27 minutes and im at 33% of my max subscription 5h quota with only one session running, this is getting ridiculous.

It seems the model got a bit more juice in it, and they try to balance the cost with less context window quota and higher burn rates.

Fraud report template is included in the audit tool.

<img width="1706" height="861" alt="Image" src="https://github.com/user-attachments/assets/ddbab603-c411-403b-88c2-6a794b25ec7b" />

│ 2026-02-03 │ - sonnet-4-5            │       127 │       493 │       304,565 │   3,996,488 │     4,301,673 │       $2.35 │

Here is what Claude himself thinks of it:

Key findings:
Non-deterministic quota accounting. The same token consumption burns wildly different percentages of quota - ranging from 5.6%/hour to 59.9%/hour within 48 hours on the same Max 20x plan.
"Token-to-Quota Correlation" analysis reveals Anthropic's quota system is inconsistent - same tokens don't always cost the same percentage.
Your numbers validate the bug. With only 127 input + 493 output + 304K cache creation today, hitting 68% utilization is absurdly high. Cache reads (4M) explicitly don't count toward limits.
Multiple users affected. The bug reporter used mitmproxy to intercept x-ratelimit-5h-utilization headers directly from Anthropic's API responses, proving the inconsistency is server-side.
The issue suggests Anthropic either has a quota accounting bug or made undisclosed changes to rate limiting after their "holiday bonus" expired. Either way, your quota is burning 5-10x faster than your actual token consumption justifies.

Why is this happening?

Adding another data point to the billing inconsistency. After Claude Code v2.1.51 update, my 1M context sessions began consuming Extra Usage without notice. Feb 23 (v2.1.50): 644 Opus 1M calls, 85M cache_read tokens — no Extra Usage charged. Feb 25 (v2.1.51+): 392 calls, 80M tokens — $48.79 Extra Usage charged. Same workload, different billing. Full evidence in #28927.

Any news on this bug?

I want to add a note here;

ephemeral_5m_input_tokens in the jsonl files would state the tokens used for responses. ephemeral_1h_input_tokens would be zeros all over. Through testing, the cache would live more than 5 minutes; cache was hit after more than 5 minutes of inactivity.

Today I rechecked. Now ephemeral_1h_input_tokens is actually not always zero.

Must have been a bug fixed from Jan 27th onwards, not documented publicly, v2.1.20;

<details>
<summary>

<body>
<table>
<thead>
<tr>
<th>Period</th>
<th>5m!=0 occ</th>
<th>1h!=0 occ</th>
<th>5m=0 occ</th>
<th>1h=0 occ</th>
<th>5m!=0 files</th>
<th>1h!=0 files</th>
<th>5m=0 files</th>
<th>1h=0 files</th>
</tr>
</thead>
<tbody>
<tr>
<td>W49</td>
<td>49</td>
<td>0</td>
<td>0</td>
<td>49</td>
<td>1</td>
<td>0</td>
<td>0</td>
<td>1</td>
</tr>
<tr>
<td>W51</td>
<td>3495</td>
<td>0</td>
<td>3</td>
<td>3498</td>
<td>19</td>
<td>0</td>
<td>3</td>
<td>19</td>
</tr>
<tr>
<td>W52</td>
<td>3283</td>
<td>0</td>
<td>2</td>
<td>3285</td>
<td>36</td>
<td>0</td>
<td>2</td>
<td>36</td>
</tr>
<tr>
<td>W1</td>
<td>4109</td>
<td>0</td>
<td>48</td>
<td>4157</td>
<td>38</td>
<td>0</td>
<td>28</td>
<td>56</td>
</tr>
<tr>
<td>W2</td>
<td>1104</td>
<td>0</td>
<td>0</td>
<td>1104</td>
<td>8</td>
<td>0</td>
<td>0</td>
<td>8</td>
</tr>
<tr>
<td>W3</td>
<td>2234</td>
<td>0</td>
<td>1</td>
<td>2235</td>
<td>13</td>
<td>0</td>
<td>1</td>
<td>13</td>
</tr>
<tr>
<td>W4</td>
<td>28946</td>
<td>0</td>
<td>87</td>
<td>29033</td>
<td>147</td>
<td>0</td>
<td>36</td>
<td>152</td>
</tr>
<tr>
<td>2025-01-26</td>
<td>8080</td>
<td>0</td>
<td>31</td>
<td>8111</td>
<td>29</td>
<td>0</td>
<td>12</td>
<td>31</td>
</tr>
<tr>
<td>2025-01-27</td>
<td>3427</td>
<td>1487</td>
<td>1505</td>
<td>3445</td>
<td>42</td>
<td>12</td>
<td>21</td>
<td>43</td>
</tr>
<tr>
<td>2025-01-28</td>
<td>2941</td>
<td>336</td>
<td>349</td>
<td>2954</td>
<td>48</td>
<td>12</td>
<td>18</td>
<td>48</td>
</tr>
<tr>
<td>2025-01-29</td>
<td>3754</td>
<td>6011</td>
<td>6053</td>
<td>3796</td>
<td>37</td>
<td>41</td>
<td>51</td>
<td>48</td>
</tr>
<tr>
<td>2025-01-30</td>
<td>1</td>
<td>1575</td>
<td>1581</td>
<td>7</td>
<td>1</td>
<td>17</td>
<td>18</td>
<td>4</td>
</tr>
<tr>
<td>2025-01-31</td>
<td>34</td>
<td>4525</td>
<td>4527</td>
<td>36</td>
<td>1</td>
<td>30</td>
<td>30</td>
<td>2</td>
</tr>
<tr>
<td>2025-02-01</td>
<td>0</td>
<td>13</td>
<td>13</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>1</td>
<td>0</td>
</tr>
<tr>
<td>W6</td>
<td>443</td>
<td>8906</td>
<td>8938</td>
<td>475</td>
<td>6</td>
<td>84</td>
<td>84</td>
<td>23</td>
</tr>
<tr>
<td>W7</td>
<td>99</td>
<td>14353</td>
<td>14384</td>
<td>130</td>
<td>4</td>
<td>119</td>
<td>120</td>
<td>22</td>
</tr>
<tr>
<td>W8</td>
<td>0</td>
<td>14843</td>
<td>14875</td>
<td>32</td>
<td>0</td>
<td>144</td>
<td>144</td>
<td>20</td>
</tr>
<tr>
<td>W9</td>
<td>35</td>
<td>11219</td>
<td>11246</td>
<td>62</td>
<td>2</td>
<td>123</td>
<td>125</td>
<td>13</td>
</tr>
<tr>
<td>W10</td>
<td>7771</td>
<td>20850</td>
<td>20921</td>
<td>7842</td>
<td>54</td>
<td>231</td>
<td>234</td>
<td>80</td>
</tr>
<tr>
<td>W11</td>
<td>6037</td>
<td>18839</td>
<td>18899</td>
<td>6097</td>
<td>79</td>
<td>163</td>
<td>165</td>
<td>90</td>
</tr>
<tr>
<td>W12</td>
<td>6</td>
<td>290</td>
<td>292</td>
<td>8</td>
<td>1</td>
<td>2</td>
<td>2</td>
<td>2</td>
</tr>
</tbody>
</table>
</body>
</html>

</summary>

<body>
<pre><code>#!/usr/bin/env bash
set -euo pipefail
DIR=&quot;${1:-.}&quot;
GLOB=&#39;[0-9a-f]-[0-9a-f]-[0-9a-f]-[0-9a-f]-[0-9a-f]*.jsonl&#39;
cd &quot;$DIR&quot;

<span class="comment"># Step 1: Find all matching files</span>
echo &quot;Finding files...&quot; &gt;&amp;2
mapfile -t files &lt; &lt;(rg --glob &quot;$GLOB&quot; -l &#39;ephemeral_5m_input_tokens&#39; 2&gt; /dev/null)
echo &quot;Found ${#files[@]} files&quot; &gt;&amp;2

<span class="comment"># Step 2: Build file-&gt;date map</span>
echo &quot;Reading file dates...&quot; &gt;&amp;2
declare -A file_date
for f in &quot;${files[@]}&quot;; do
file_date[&quot;$f&quot;]=$(date -d @&quot;$(stat --format=&#39;%Y&#39; -- &quot;$f&quot;)&quot; +%Y-%m-%d)
done

<span class="comment"># Step 3: Count matches per file with single rg passes (4 total, not 4 per file)</span>
echo &quot;Counting 5m!=0...&quot; &gt;&amp;2
declare -A count_5m_nz
while IFS=: read -r f c; do
count_5m_nz[&quot;$f&quot;]=$c
done &lt; &lt;(rg -c &#39;ephemeral_5m_input_tokens&quot;:\s*[1-9]&#39; --glob &quot;$GLOB&quot; 2&gt; /dev/null || true)

echo &quot;Counting 5m=0...&quot; &gt;&amp;2
declare -A count_5m_z
while IFS=: read -r f c; do
count_5m_z[&quot;$f&quot;]=$c
done &lt; &lt;(rg -c &#39;ephemeral_5m_input_tokens&quot;:\s*0[,}]&#39; --glob &quot;$GLOB&quot; 2&gt; /dev/null || true)

echo &quot;Counting 1h!=0...&quot; &gt;&amp;2
declare -A count_1h_nz
while IFS=: read -r f c; do
count_1h_nz[&quot;$f&quot;]=$c
done &lt; &lt;(rg -c &#39;ephemeral_1h_input_tokens&quot;:\s*[1-9]&#39; --glob &quot;$GLOB&quot; 2&gt; /dev/null || true)

echo &quot;Counting 1h=0...&quot; &gt;&amp;2
declare -A count_1h_z
while IFS=: read -r f c; do
count_1h_z[&quot;$f&quot;]=$c
done &lt; &lt;(rg -c &#39;ephemeral_1h_input_tokens&quot;:\s*0[,}]&#39; --glob &quot;$GLOB&quot; 2&gt; /dev/null || true)

<span class="comment"># Step 4: Aggregate by date</span>
echo &quot;Aggregating...&quot; &gt;&amp;2
declare -A s5nz s5z s1nz s1z f5nz f5z f1nz f1z
for f in &quot;${files[@]}&quot;; do
d=&quot;${file_date[$f]}&quot;
v=&quot;${count_5m_nz[$f]:-0}&quot;
s5nz[$d]=$(( ${s5nz[$d]:-0} + v ))
(( v &gt; 0 )) &amp;&amp; f5nz[$d]=$(( ${f5nz[$d]:-0} + 1 ))
v=&quot;${count_5m_z[$f]:-0}&quot;
s5z[$d]=$(( ${s5z[$d]:-0} + v ))
(( v &gt; 0 )) &amp;&amp; f5z[$d]=$(( ${f5z[$d]:-0} + 1 ))
v=&quot;${count_1h_nz[$f]:-0}&quot;
s1nz[$d]=$(( ${s1nz[$d]:-0} + v ))
(( v &gt; 0 )) &amp;&amp; f1nz[$d]=$(( ${f1nz[$d]:-0} + 1 ))
v=&quot;${count_1h_z[$f]:-0}&quot;
s1z[$d]=$(( ${s1z[$d]:-0} + v ))
(( v &gt; 0 )) &amp;&amp; f1z[$d]=$(( ${f1z[$d]:-0} + 1 ))
done

echo &quot;| Date | 5m!=0 occ | 1h!=0 occ | 5m=0 occ | 1h=0 occ | 5m!=0 files | 1h!=0 files | 5m=0 files | 1h=0 files |&quot;
echo &quot;|------|----------:|----------:|---------:|---------:|------------:|------------:|-----------:|-----------:|&quot;

<span class="comment"># Step 5: Print sorted</span>
echo &quot;&quot; &gt;&amp;2
for d in &quot;${!s5nz[@]}&quot;; do
printf &quot;| %s | %d | %d | %d | %d | %d | %d | %d | %d |\n&quot; \
&quot;$d&quot; \
&quot;${s5nz[$d]:-0}&quot; &quot;${s1nz[$d]:-0}&quot; \
&quot;${s5z[$d]:-0}&quot; &quot;${s1z[$d]:-0}&quot; \
&quot;${f5nz[$d]:-0}&quot; &quot;${f1nz[$d]:-0}&quot; \
&quot;${f5z[$d]:-0}&quot; &quot;${f1z[$d]:-0}&quot;
done | sort
</code></pre>
</body>

</details>

I've done extensive analysis on this exact problem. Using ccusage_go (open-source Claude Code usage tracker), I found that Cache Read tokens consumed 97.7% of my session costs — API actual cost was $1.47, total billed cost was $64.98 (a 44x markup). Cache also degrades instruction following in long sessions, which I documented with per-turn JSONL analysis.
Full write-up with data, community issue references, and Claude Code's own self-analysis report:
https://blog.sd.idv.tw/en/posts/2026-03-25_claude-code-cache-trap/
Tool: https://github.com/SDpower/ccusage_go

The undisclosed quota changes continue. Max 20 ($200/mo), v2.1.89, April 1 2026: 100% in ~70 min after reset. No transparency from Anthropic on what changed.

Support acknowledged "resolved incidents" on Mar 31-Apr 1 but offered no explanation or fix — just "enable extra usage" (pay more).

Full report: #41788
Related: #38335, #38239, #40790, #41055, #41663, #40903

I've been experiencing the same issue on Max 20 ($200/mo) — rate limit 100% exhausted in ~70 minutes.

After setting up a monitoring proxy using the official ANTHROPIC_BASE_URL env var, I identified two cache bugs as the root cause (#40524, #34629) and measured the impact: cache read ratio dropped to 4.3%, meaning ~20x token inflation per turn. After applying workarounds it stabilized at 89-99%.

Full analysis with per-request measured data, safe workarounds, and community references (including cc-cache-fix): https://github.com/ArkNill/claude-code-cache-analysis

Update (April 2): v2.1.90 has significantly improved cache efficiency — benchmark shows 95-99% cache read in stable sessions (both npm and standalone installations).

If you're still affected:

1. Update: claude update (or npm install -g @anthropic-ai/claude-code)
2. Pin the version: add "DISABLE_AUTOUPDATER": "1" to ~/.claude/settings.json env section
3. Avoid --resume (still broken)

Note: server-side quota issues (org-level pool sharing, accounting mismatches) remain unresolved — the above fixes the client-side cache drain only.

Benchmark data: https://github.com/ArkNill/claude-code-cache-analysis

April 3 update: v2.1.91 fixes the cache regression that caused the worst drain. If you are still hitting limits after updating, there are additional unfixed mechanisms: a 200K tool result budget cap, a client-side false rate limiter, and silent context stripping — all confirmed via proxy testing. Anthropic acknowledged peak-hour tightening on X (Lydia Hallie) but stated "none were over-charging you." Measured data and analysis: claude-code-cache-analysis

Same issue here. Max 20x subscriber.

Since the May 27–28 server-side change that merged Claude Design's previously separate quota pool into the shared Claude.ai + Claude Code allowance, my Cowork usage is visibly eating into my main quota.

This week (June 1–4, 2026) I'm running multiple parallel Cowork sessions (Claude Design agents) and quota burn rate feels 2–3x what it was two weeks ago. The extra capacity I used to have via Cowork's separate budget is gone.

I subscribed to Max 20x specifically because Cowork had its own meter — that's what made parallel agent workflows viable on this plan. The silent merge undermines that value proposition.

Asking for one of:

1. Restore Claude Design (Cowork) as a separately metered budget for Max 20x users, OR
2. 2. Officially announce the merge with impact analysis for heavy Cowork users, OR
3. 3. Increase Max 20x weekly limits proportionally to compensate.

This is a material change to the Max plan that wasn't disclosed at purchase. Please give us back the separate Cowork budget. Thanks for transparent communication going forward.