[BUG] Non-deterministic quota accounting: 65% of 5-hour session consumed with minimal actual token usage — Max $100 plan

Resolved 💬 18 comments Opened Feb 26, 2026 by gudcks0305 Closed Feb 27, 2026

Environment

Plan: Max ($100/month, 5x usage)
OS: macOS (Darwin 25.3.0)
Date: February 26, 2026

Problem

My 5-hour session quota jumped from ~20% to 65% within a handful of message turns. ccusage data shows modest actual token consumption that does not justify consuming 65% of my session window.

Evidence

ccusage output (2026-02-26):

| Date | Models | Calls | Input | Output | Cache Creation | Cache Read |
|------|--------|-------|-------|--------|----------------|------------|
| 2026-02-26 | haiku-4-5, opus-4-6, sonnet-4-6 | 1,300 | 9,421 | ~2,150K | ~29,696K | ~31,857K |

Dashboard (claude.ai):

Current session: 65% used
Resets in 30 min

The numbers do not add up. How does ~9,421 input tokens and ~2.15M output tokens translate to 65% of a $100/month Max plan's 5-hour window? Where is the remaining 45% being attributed to?

This directly corroborates the findings in #22435, which demonstrated a 1,500x variance in tokens-per-1%-quota (2,517 to 18,531,900) through 5,396 mitmproxy samples. The quota accounting system is either broken or deliberately opaque.

This is not an isolated incident

This exact problem has been reported and documented for over two months across numerous issues:

| Issue | Upvotes | Description | Anthropic Response |
|-------|---------|-------------|-------------------|
| #16157 | 536 | Instantly hitting limits with Max subscription | "Limits haven't changed" |
| #23706 | 59 | Opus 4.6 consumes 3x more tokens than 4.5 | ❌ None |
| #22435 | - | 10x burn rate variance with mitmproxy proof | ❌ None |
| #22876 | - | 429 errors despite dashboard showing available quota | ❌ None |
| #20767 | - | Pro quota reduced to ~20 prompts per 5 hours | ❌ None (marked stale) |
| #28927 | - | Silent billing change in v2.1.51 routing to Extra Usage | ❌ None |
| #17084 | 237 | Most restrictive limits since Opus 4.5 launch | ❌ None |

The pattern is clear: hundreds of users, months of data, zero meaningful response.

The only official statement

The sole response from Anthropic (ThariqS, Jan 26) was:

"Rate limits have not changed since Opus 4.5 launch."

This is contradicted by:

Empirical data showing 10x burn rate variance on the same account, same day (#22435)
Community-estimated ~60% reduction in effective token limits (The Register)
The automatic upgrade to Opus 4.6, which benchmarks show generates 3x more tokens for identical tasks — effectively a stealth limit reduction without touching the "rate limit" number
Silent billing changes in v2.1.51 routing 200K+ context calls to Extra Usage (#28927)

Saying "limits haven't changed" while deploying a model that consumes 3x more tokens against unchanged limits is a limit reduction. This is not a technical nuance — it's basic arithmetic.

A word on "Anthropic"

The name "Anthropic" derives from the Greek anthropikos — "of or pertaining to humanity." The company's stated mission is to build AI that is "safe, beneficial, and understandable."

What is neither beneficial nor understandable:

Charging $100–200/month (Max plan) for a service with undisclosed, non-deterministic quota accounting
Ignoring months of documented evidence from paying customers, including mitmproxy captures, JSONL billing analysis, and API header data
Marking legitimate bug reports as "stale" instead of addressing them
Auto-upgrading users to a 3x more token-hungry model without disclosure or consent, then claiming "limits haven't changed"
Silently changing billing behavior in patch updates (v2.1.51) without changelog entries
Moderating criticism on Discord while issues pile up on GitHub unanswered

When developers present 5,396 API samples proving quota inconsistency and the response is silence — or worse, dismissal as "resumption of normal limits" — this is not a company living up to its name. This is consumer deception.

Users in #22435 have already outlined potential violations under UCC 2-313, FTC Act Section 5, and California Business & Professions Code 17200. The legal exposure grows with every week of silence.

What we need — not want, need

Publish the quota consumption formula. If quota is based on something other than raw token count, disclose it. Today.
Explain the variance. Why does 1% quota cost 2,517 tokens in one session and 18,531,900 in another?
Real-time quota visibility in Claude Code CLI — not a hidden settings page on claude.ai
Opt-in model upgrades. Do not auto-upgrade to models that burn quota 3x faster
Acknowledge the problem exists. Silence is not a strategy. It is a choice, and it speaks louder than any PR statement.

Related Issues

#16157 #17084 #20767 #22435 #22439 #22876 #23706 #27310 #28927

View original on GitHub ↗

18 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

kuroanji · 4 months ago

Same here, started from yesterday (Version: 2.1.59).

nmtitov · 4 months ago

Same here.
I see the same on MAX 100$/month tariff.
Within 15 min session and 10 short messages I got 40% of my 5 hour limit used. Before that I have never ever hit limits with my usage patterns.

dmurat · 4 months ago

For all participants, which version of claude-code you are using?
Mine is 2.1.59 (the latest one at the moment of writing)

nmtitov · 4 months ago

@dmurat

$ claude --version
2.1.59 (Claude Code)

s070681 · 4 months ago

2.1.59, windows 11 (10.0.26200), 20x plan

confirming the usage spike - hit 96% session usage in a single moderate conversation. have never ever come close to a session limit on 20x, that's how i noticed it - my session status bar populated and i've never seen it since upgrading to max 20x. luckily hit 90% with only 30 min until reset

/cost is broken for me too - only shows "You are currently using your subscription to power your Claude Code usage" with no actual token/cost breakdown

but i think the usage issue might be a symptom of a deeper auth bug in 2.1.59:

/doctor reports Config install method: unknown
every folder prompts to "trust" again, even ones i've used for weeks
re-authentication prompts fire repeatedly across folders despite valid credentials at ~/.claude/.credentials.json
auto-compact setting reverts to default on every session start
claude install fixes it temporarily, then it reverts

possibly related to #28625 and #27910 - if the install method detection is broken, it might not be reading the plan tier correctly, which would explain why usage accounting feels off. each re-auth could also be fragmenting sessions against the quota

downgraded to 2.1.55, same onboarding/trust behavior persisted but once i went through it once it seems to have subsided. so the config damage from 2.1.59 may survive downgrades? i'm not sure yet.

---

worth noting from the 2.1.59 changelog:

Fixed config file corruption: Fixed an issue where running multiple Claude Code instances simultaneously could cause config files to become corrupted, resulting in lost credentials.

MCP OAuth race condition fix: Fixed a race condition in OAuth token refresh when running multiple Claude Code instances simultaneously.

i run multiple cc sessions in parallel panes as my normal workflow and had zero issues before 2.1.59. no config corruption, no auth problems, no usage spikes. whatever this "fix" introduced is worse than the original bug - it seems to have broken install method detection, config persistence, and possibly plan tier recognition in the process

lemonroti · 4 months ago

Same here, started from yesterday (Version: 2.1.59).
Rollback to 2.1.56 also same again , just reset from limit , using half an hour then hit the 75% limit already

s070681 · 4 months ago

i guess .52 is the one you want to be on for now? i'm not sure. pretty bad this has almost been out for 24h?

nmtitov · 4 months ago

@s070681 Great observations.

For me I can tell that I clearly do see spiky token burn. Out of my 5 hour limit in 10 simple messages using Opus model.

BUT! I never had any problems with auth. Never had a need to re-authenticate.

/doctor correctly shows me "Config install method: native"
/cost correctly displays breakdown of current context.

Sonnet is still using "pre-update" number of % usage as I can see. I had to send a lot of messages to Sonnet in the same context just to see 1% bump in my 5 hour window limits. Still on 0% of "Sonnet-only limits". With Opus I get at least 5%-10% of % usage of 5 hour window limits on each request.

mrbarbosa · 4 months ago

I usually end the week around 80% of total usage and I typically have to really push to get there. If the few sessions I had today are any indicator I'll have burned through usage by Saturday and end up at 260% this week.

I'm seeing 3.5x the burn rate.

Vasiliy-Makogon · 4 months ago

claude --version
2.1.59 (Claude Code)
Ubuntu 22 on WSL

Yesterday, the Sonnet 4.6 model worked flawlessly for a very long time. Today, however, the 4-hour limit was reached on the very first request!

When the limit was reached, the console program went into an uncontrollable stupor, endlessly displaying the limit reached message. No keystroke could stop it.

shawnm-anthropic · 4 months ago

Hi folks. If you have a session which used an unexpectedly large portion of your rate limit, please run /feedback from that session and post the feedback ID here on this issue.

If you revert to an older version, please also report the version you downgraded to and whether you still experience the issue.

SarfarazAliKhan · 4 months ago

Downgrading to Version 2.1.52 worked for me. That's a huge difference since I downgraded and my usage went back to normal.

rjbutler · 4 months ago

@shawnm-anthropic After burning through 24% of my 5 hour window in 10 minutes with very simple prompts on a new session, I revoked all of my CC tokens and logged in again. It's back to normal now. The previous session started burning quickly at the end of the previous 5 hour window, but it was a long session and context was close to full so I didn't think much of it at the time. But in hindsight it was happening then too.

s070681 · 4 months ago

Hi folks. If you have a session which used an unexpectedly large portion of your rate limit, please run /feedback from that session and post the feedback ID here on this issue. If you revert to an older version, please also report the version you downgraded to and whether you still experience the issue.

not really sure how to go back and tag all my sessions from today on .59, it wasn't just one in particular. but i'll update this comment when im back at my desk with an id from a session or two.

i downgraded to .52 and all issues i experienced were solved.

shawnm-anthropic · 4 months ago

Hi. This is fixed in v2.1.62. Please run claude update. We've also reset rate limits: https://x.com/trq212/status/2027232172810416493

junaidtitan · 4 months ago

We ran into similar token accounting confusion. Built cozempic partly to get visibility into actual token consumption — it reads the exact \usage\ fields from your session JSONL so you can see real numbers vs what the billing says.

\\\pip install cozempic cozempic current --diagnose \\\

Shows exact token count, context window %, and a breakdown of where your tokens are going (conversation, tool results, system overhead, etc.). Helps debug whether the issue is bloat eating your budget or a billing discrepancy. Open source, happy to hear feedback.

github-actions[bot] · 4 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.