[BUG] Session usage meter accruing at impossible rate — Max plan, single + multi-session usage
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
[BUG] Session usage meter accruing at impossible rate — Max plan, single + multi-session usage
Preflight Checklist
I have searched existing issues and this hasn't been reported yet
Claude Code version 2.1.41 (freshly updated from 2.0.72)
OS Windows 11
Terminal PowerShell
Plan Claude Max
PowerShell
Bug Description
Session usage is accruing at a rate that is completely disproportionate to actual work being performed. On a
Max plan, a single session went from 0% to 84% in under 50 minutes with minimal activity (settings
navigation, light conversation — no coding, no file operations, no tool use).
Expected Behaviour
A Max plan session should sustain several hours of active work across multiple sessions
Usage accrual should correlate with actual token consumption
If limits are being reached, clear notification should be provided rather than silent session exits
Related Issues
#18987 — Session limit consumption far exceeds actual token usage
#24719 — Rate limit triggers before reaching 100% usage
#19673 — "You've hit your limit" while usage shows 84%
#8926 — Reset time inconsistent between CLI and claude.ai
#24478 — CLI freezes and becomes unresponsive (SIGKILL required)
#19060 — CLI freezes with "No messages returned" error
Impact
At the current accrual rate, the Max plan — which is priced and marketed for power users running multi-session
workflows — cannot sustain even a single hour of light usage. This represents a significant gap between what is
being paid for and what is being delivered.
What Should Happen?
Context
This was observed immediately after updating from 2.0.72 to 2.1.41
I typically run 3–4 concurrent sessions in my normal workflow
Even accounting for multiple sessions, the accrual rate is excessive
Several of my sessions run a lightweight validation workflow: send instruction to Google Vertex →
Vertex processes and returns output → Claude reads the output file → Claude makes targeted edits →
revalidates. The heavy token work is done by Vertex, not Claude Code
The coding sessions involve standard file editing — nothing unusually large
This pattern has been occurring over the past several days, not just post-update
Error Messages/Logs
Session Exit Examples
Example 1 — Session exits mid-documentation update:
Example 2 — Session exits during bash command execution:
● Same result. Let me check this output to see what the LLM returned.
● Read(outputs\VERTEX_document_validation_..._2026-02-13_1610.md)
⎿ Read 175 lines
· Updating documentation… (esc to interrupt · ctrl+t to show todos · 3m 58s · ↓ 5.2k tokens · thinking)
>
⏵⏵ accept edits on (shift+tab to cycle)
PS C:\Users\simpl\dev_files\...>
In both cases, Claude Code drops to the PowerShell prompt without any error output or session limit
notification.Steps to Reproduce
Timeline (Single Session, Minimal Activity)
Time Elapsed Session Usage Activity
~0 min 0% Fresh session start
~15 min 19% Navigated settings, ran claude update
~38 min 69% Continued light conversation only
~48 min 84% No change in activity
Session resets in ~4 hr 12 min at time of last check. At this burn rate, the full 5-hour session window would be
exhausted in approximately 55–60 minutes.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.41
Platform
Other
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Additional Observations
Usage meter has been observed jumping 10–20% in the space of a few minutes, then taking much longer
to progress through an equivalent amount
The accrual rate does not correlate with the complexity or volume of work being performed
Sessions have also been exiting/dropping unexpectedly mid-task without error messages (separate but
potentially related issue — see terminal output below)
11 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is not a duplicate. The referenced issues describe similar symptoms but my report includes a documented timeline with specific usage percentages and timestamps on the latest version (2.1.41), plus session exit behaviour on Windows. Happy to provide additional logs.
I noticed the same thing. It seems that when a session gets interrupted due to exhausting token credit budget, the credits from that session get double charged when you resume the session after your limit resets. I made a video here:
https://youtu.be/sk6fuMLJMsQ?si=oWdLJ7mnXM_HOGIT
Environment info: win32, vscode, v2.1.45
Facing the exact same issue. Was using PowerShell in Win terminal.
Weekly limit reset at 11am. Session limit at 11:15am was at 98%. Session limit never even got reset after weekly limit was reset! Was using claude code 2.1.49 but downgraded to previous versions and problem still persists. seems like a server side issue not client side as my Claude app also uses extremely high session limit. Contact their support and their chatbot said "high volume of people are complaining about this since 19th and 20th Feb".
<img width="970" height="448" alt="Image" src="https://github.com/user-attachments/assets/01128ee8-bf6c-4565-baa4-5c62df6803aa" />
This is my usage according to claude code, yesterday I ran the same task, barely used 1% in session usage. today it used 23%. I'm on Max x20 plan. Even based on their token usage numbers its impossible for me to do 98% session limit and use that much token.
<img width="616" height="398" alt="Image" src="https://github.com/user-attachments/assets/df33eac3-2d95-4a72-8ecd-2e27539f0851" />
Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.
What's happening: Claude Code login flow on Windows/PowerShell fails to persist Max Plan OAuth session, falling back to API key billing. The /login command completes OAuth authorization but the credential store writes the session as 'API' type instead of 'Max Plan', causing all subsequent requests to bill against the API balance. This is a client-side credential persistence bug in Claude Code v2.1.x on Windows.
What worked for us:
This is a Claude Code client bug, not user-fixable via code. Workarounds: (1) Verify active auth method with 'claude /doctor' or check ~/.claude/credentials.json to confirm session type, (2) Unset any ANTHROPIC_API_KEY environment variable that may override OAuth login, (3) Try 'claude config set authMethod max-plan' if available, (4) Downgrade to last known working version until fix is released. File for API credit refund via Anthropic support.
Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞
---
<sub>🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.</sub>
Update — March 23, 2026 — v2.1.81 — still occurring, new data points
Revisiting this with fresh evidence from tonight.
New observations:
Session reset after hitting 100%. Within 1–2 messages across two light Claude Code chats (no coding, no file operations, no tool use), usage had already jumped to 7%
Earlier today, 27% was consumed in approximately 15 minutes across two sessions doing mostly internal computer-based operations
In both cases, no warning was shown before hitting 100% — it jumped straight to the limit with no 80% or 90% threshold notification
Re: @sstklen's suggestion — I ran the full diagnostic:
$env:ANTHROPIC_API_KEY # returned nothing — no API key set
cat ~/.claude/credentials.json # file does not exist (Windows stores auth in Credential Manager)
claude /doctor # confirms Claude Max, Opus 4.6, 1M context, properly authenticated
Auth is clean. No ANTHROPIC_API_KEY override, no fallback to API billing. This is genuine phantom accrual on a correctly authenticated Max plan session. The sstklen theory doesn't apply here, but appreciate the suggestion.
Also noted: When I hit the session limit and attempted to switch to API credit billing as a workaround, login failed entirely — separate but potentially related.
Version: 2.1.81 (ahead of stable 2.1.74), Windows 11, PowerShell, Opus 4.6 1M context.
Follow-up — March 24, 2026
One more concrete data point since my last comment: a single exchange involving a plain text document of approximately 400 words (a list of 10 LinkedIn profiles with URLs) consumed 5% of the session limit in claude.ai. At that rate, a Max plan session would be exhausted by roughly 20 similar lightweight exchanges.
This is on top of the session reset I mentioned — within 1–2 messages after that reset, usage was already at 7%.
Update — March 24, 2026 — v2.1.81 — major new findings, two distinct bugs identified
Following on from my comment yesterday, significant new evidence gathered today that clarifies what's actually happening. I believe there are two separate but related bugs at play.
Bug 1 — Session context re-ingestion after limit pause (the more serious issue)
Today my session limit was hit mid-task in a long-running provechain session. Claude Code presented three options: stop and wait, pay for extra usage, or upgrade. I chose stop and wait and did nothing further.
At 2:00pm the session reset. I returned at approximately 2:50pm. I did not manually resume the session — I simply said "please continue" to the existing paused session.
Within 5–10 minutes the session meter was already at 92%, with 4hr 6min remaining on the reset timer.
To understand why, I had Claude Code scrape all messages across all three active sessions since 2pm. Here's what it found:
Session data since 2pm reset:
→ validators: 9 user msgs / 13 assistant msgs / ~50KB
→ provechain: 25 user msgs / 39 assistant msgs / 438KB
→ business: 2 user msgs / 3 assistant msgs / ~10KB
→ TOTAL: 36 user msgs / 55 assistant msgs / ~498KB
Note: provechain JSONL total file size is 21.6MB accumulated over several days.
The provechain session JSONL file has been running for several days and has grown to 21.6MB total. When I said "please continue" after the reset, Claude Code re-ingested that entire accumulated history as input tokens against the fresh session limit — consuming 92% almost instantly.
This is the core of Bug 1: I did not resume a session. I did not start new work. I said two words after a session reset. The context that drove that 92% consumption was built up across multiple previous session windows that were already fully consumed when they ran. Re-ingesting it after a reset is effectively double-billing for the same context.
The validators session is particularly informative as a comparison. It has also been running for several days and has arguably done comparable work — but being more conversational and less tool-heavy, its JSONL is significantly smaller. It did not cause a comparable spike. This suggests the problem is specifically tool-heavy sessions accumulating large JSONL histories that get re-submitted in full against a fresh session window on continuation.
Bug 2 — Session meter misfiring independently of actual token consumption
Separate from the above, the session meter is also misfiring on genuinely lightweight activity. Two concrete examples from today:
A single exchange involving a plain text document of approximately 400 words (a list of 10 LinkedIn profiles with URLs) consumed 5% of the session limit. After a separate session reset, within 1–2 messages across two light sessions (no coding, no file operations), the meter had already jumped to 7%
The weekly counter provides the clearest corroboration. At the point the session meter showed 93%, the weekly counter showed only 46%. If the session meter accurately reflected real token consumption, these two figures should move in rough proportion. The divergence strongly suggests the session meter is misfiring independently of actual usage.
/usage output captured at approximately 2:55pm today:
Current session
██████████████████████████████████████████████▌ 93% used
Resets 7pm (Europe/Dublin)
Current week (all models)
███████████████████████ 46% used
Resets Mar 27, 12pm (Europe/Dublin)
Current week (Sonnet only)
0% used
Extra usage
Extra usage not enabled
Summary
Bug 1 — Context re-ingestion double-billing
Said "please continue" after a session reset. Claude Code re-ingested 21.6MB of accumulated provechain JSONL history against the fresh session limit. 92% consumed in 5–10 minutes from two words. That context was built across previous session windows already fully consumed when they ran — re-billing it after a reset is charging twice for the same work.
Bug 2 — Session meter misfiring
Independently of Bug 1, the session meter accrues disproportionately fast on lightweight activity. A 400-word plain text document cost 5%. At the same moment the session showed 93%, the weekly counter showed only 46% — if consumption were real, these should move proportionally.
https://github.com/anthropics/claude-code/issues/38910#issuecomment-4134768536
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
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.