[Bug] Max 20x weekly quota drained 53% in 2 days; transcript accounting shows those days were <half the load of a heavier week that didn't drain — cache_read metering suspected

Status Open

Maintainer reply None cached

Activity 5 comments · opened Jul 25, 2026

Environment

Plan: Claude Max 20x ($200/mo), individual account (not Teams)
Claude Code: v2.1.220
OS: macOS 26.5.2 (Darwin 25.5.0)

Symptom

~53% of my weekly usage quota was consumed between Jul 24 and Jul 25, 2026, including periods when the machine was idle. My normal pattern on this plan, with the same working style (heavy use of Fable 5), is 60–70% of the weekly quota consumed across an entire week.

Evidence: local API-reported usage cannot explain the drain

I parsed every local session transcript (~/.claude/projects/**/*.jsonl) for Jul 11–25 and converted each request's usage object to dollar-equivalent cost at published rates (input×1.0 + cache_write×1.25 + cache_read×0.10 + output, per-model rates). Records were deduplicated by message.id (transcripts repeat the usage object once per content block — 14,532 of 29,696 records were duplicates); synthetic/API-error records excluded.

Per-day cost (deduplicated):

| Day | $-equivalent | Quota result |
|---|---|---|
| 2026-07-17 | $198.01 | normal |
| 2026-07-18 | $413.73 | heaviest day of the window — normal |
| 2026-07-24 | $266.20 | 53% burn begins |
| 2026-07-25 | $29.57 | burn continued, machine mostly idle |

Jul 17+18 = $611.74 → no abnormal drain.
Jul 24+25 = $295.77 → 53% of the weekly quota.

The two days that drained half my quota carried less than half the workload of an earlier pair that drained nothing unusual. Rolling 7-day windows don't explain it either: the week ending Jul 24 ($1,459) is only 5.6% above the week ending Jul 18 ($1,382), which stayed within normal limits.

Suspected cause: `cache_read_input_tokens` metered at full input weight

My workload is 96.1% cache-read tokens (1,802,057,513 cache-read vs 4,374,429 fresh input + 68,959,189 cache-write over the window). Cache reads should meter at 0.1×. If they are metered at 1.0×:

| Day | Correct | If cache_read at 1.0× | Inflation |
|---|---|---|---|
| 2026-07-24 | $266.20 | $1,626.58 | 6.1× |
| 2026-07-25 | $29.57 | $178.63 | 6.0× |
| Total Jul 11–25 | $2,582 | $16,072 | 6.2× |

A ~6× metering inflation is exactly the magnitude needed to turn a normal two days into 53% of a weekly quota. This matches #49302 (cache_read consuming the 5-hour bucket at input-token rate, ~7×, Max plan — closed "not planned"), and is consistent with #24147, #41930, #54750, #46829.

Ruled out

Credential theft: single userID/machineID/keychain credential across all 29,696 records; no ANTHROPIC_API_KEY in env; no foreign account/org UUIDs. All usage originated from this machine.
Local autonomous agents: an unattended agent fleet did run Jul 23–24; its usage is included in the totals above and still doesn't explain the drain. It has been decommissioned.
Model mix: part of the load moved from Fable 5 to Opus 5 (half the price) on Jul 24–25 — this reduced marginal cost.

Request

Reconcile my account's quota-meter charges for Jul 24–25 against the API-reported usage above (I can supply per-request raw data).
Confirm the metering weight applied to cache_read_input_tokens for Max weekly/5-hour limits vs the documented 0.1× rate.
If a discrepancy is confirmed, restore the incorrectly consumed quota.

View original on GitHub ↗

4 Comments

KodBena · 1 month ago

Yep, something is weird. I just compacted, it drained 2% Fable quota at 20x, then I asked it to resume, instantly drained another 2% (before producing anything at all).

dmki · 1 month ago

Exactly the same thing. Nearly drained in 2 days, doing nothing special. I upgraded to "20x" because 5x did the same. I didn't start using it more, but having the same issue. Only one question to Anthropic - WTF?

Regsorm · 1 month ago

Same profile here — adding a second Max data point using your dedup-by-message.id method.

Environment: Claude Code v2.1.220, Windows, Max 20x plan.

My weekly window reset Friday evening (24 Jul); I was idle Fri–Sat, so it started from zero. After ~1 hour of active work today (Sun 26 Jul) the meters read Session 6% / Weekly 2%.

One honest difference from your report: my consumption was not during idle time — it was real interactive Claude Code work, fully accounted for by my visible sessions. So I can't corroborate the idle-drain symptom. What I can corroborate is the token profile your hypothesis rests on.

Parsing today's transcripts and deduplicating by message.id (54% of usage records were duplicates — the usage object repeats per content block, matching your 49%):

| Token type | Deduplicated |
|---|---|
| input (fresh) | 465 |
| cache_write | 3,439,179 |
| cache_read | 31,139,361 |
| output | 197,875 |
| cache_read share | 89.5% |

Applying your metering test (cache_read at 0.1× vs 1.0×, output at 5× input):

correct: ~8.4M units
if cache_read metered at 1.0×: ~36.4M units
→ ~4.3× inflation (your figure: 6.2×)

Caveats, to keep this honest:

I cannot verify the actual meter charge against these tokens — the absolute weekly token budget isn't exposed client-side, so I can only show the token mix, not prove the server metered cache_read at 1.0×.
I cannot isolate this by model — my sessions mixed Opus 5 / Opus 4.8 / Haiku, so cache_read can't be attributed to a single model. This points to cache_read metering generally, not a model-specific bug.

Net: another Max workload that is ~90% cache_read — exactly the profile that would be hit hardest if cache_read is metered above the documented 0.1×. +1 to your request #2 (confirm the cache_read metering weight for the weekly / 5-hour limits).

COOLak · 1 month ago

Adding a related Billing Platform / usage-meter reconciliation signal, kept public-safe.

This report is important because it gives Anthropic a concrete customer-side accounting hypothesis: visible transcript usage, after deduplication, does not explain the Max 20x weekly/session quota drain unless cache-read or equivalent cached-context tokens are being metered differently from the expected discounted weight in the plan-limit system.

My direct unresolved case is a different Claude billing surface: manual prepaid / bulk usage-credit purchases fail or fail to commit cleanly while automatic usage-credit reloads on the same paid billing setup continue charging successfully. The shared owner boundary is the same: customer-visible billing/usage state, hidden usage-meter state, credit / allocation debits, and support remediation are not reconciled end-to-end.

Requested triage path: please route this issue family to a human Billing Platform / usage-ledger / cost-control owner with authority to compare, for the same account and time window:

transcript-level token usage after deduplication by message/request id;
cache_read / cache_write / fresh input / output metering weights used for Max weekly and 5-hour limits;
visible usage-meter percentages shown to the customer;
hidden limit buckets and reset-window state;
usage-credit or extra-usage debits, if any;
support-visible account state and any credit/cap restoration policy.

Concrete resolution test: Anthropic should be able to explain why a lower-cost/lower-workload window consumed materially more paid allocation than a heavier prior window, or restore the incorrectly consumed quota/credits if the meter applied the wrong cache-read weight.

Public, privacy-sanitized evidence hub for the related billing case:
https://coolak.github.io/anthropic-claude-billing-incident/

Billing reconciliation matrix / owner map:
https://coolak.github.io/anthropic-claude-billing-incident/reconciliation-matrix.html

I am intentionally not posting card details, bank names, private payment IDs, invoice IDs, support IDs, raw logs, screenshots, payment URLs, one-time codes, token values from private accounts, or private support-thread text here.

Showing cached comments. Read the full discussion on GitHub ↗