[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)