Bug: Claude Code current session limit reaches 100% despite low visible local session usage

[Troskiev83]

Bug: Claude Code shows current session limit exhausted despite very low visible local session usage

Summary

Claude Code / Claude Desktop reported the current session limit as 100% used and blocked further Claude Code usage, even though the usage visible locally in Claude Code and local transcripts did not appear to justify exhausting a Max 20x current-session limit.

This could be either:

1. A usage accounting / attribution bug, where the current session limit is being computed incorrectly or includes usage not represented in local Claude Code usage views.
2. A security / token attribution issue, where usage from another device/session/token is being charged to the same Claude Code account but is not visible in local Claude Code transcripts.

At minimum, Claude Code's /usage UI appears insufficient for diagnosing why the current session was exhausted.

Environment

• Claude Code version: 2.1.123
• OS: macOS 26.2 (arm64)
• Node.js: v22.17.0
• npm: 10.9.2
• Plan shown in Claude UI: Max 20x
• Timezone: Europe/Madrid
• Date observed: 2026-04-29

What happened

At approximately 2026-04-29 18:25 CEST, Claude Desktop and Claude Code showed:

• Current session: 100% used
• Reset: around 21:40 Europe/Madrid
• Current week, all models: 60% used
• Current week, Sonnet only: 1% used

In Claude Code /usage, the visible local session summary was small:

Session
Total cost: $0.76
Total duration (API): 53s
Total duration (wall): 2h 53m 5s
Total code changes: 0 lines added, 0 lines removed

Usage by model:
claude-haiku-4-5: 370 input, 14 output, 0 cache read, 0 cache write
claude-opus-4-7: 21 input, 2.5k output, 436.2k cache read, 76.9k cache write

Current session: 100% used
Resets 9:40pm (Europe/Madrid)

Current week (all models): 60% used
Current week (Sonnet only): 1% used

The same local Claude Code transcript recorded the hard limit after a trivial prompt:

timestamp=2026-04-29T16:26:16.363Z
user prompt="a"

timestamp=2026-04-29T16:26:16.859Z
message="You've hit your limit · resets 9:40pm (Europe/Madrid)"

This makes the limit feel disconnected from the visible local Claude Code usage.

Local transcript usage cross-check

I also inspected local Claude Code transcript usage using ccusage:

npx ccusage@latest blocks --json

Relevant blocks for the same day:

2026-04-29T04:00:00Z - 2026-04-29T09:00:00Z
totalTokens=363,679,444
cacheReadInputTokens=358,827,700
cacheCreationInputTokens=4,361,929
outputTokens=478,605
models=claude-opus-4-7, claude-haiku-4-5, claude-sonnet-4-6

2026-04-29T09:00:00Z - 2026-04-29T14:00:00Z
totalTokens=214,817,570
cacheReadInputTokens=211,368,028
cacheCreationInputTokens=3,297,689
outputTokens=151,103
models=claude-opus-4-7, claude-opus-4-6

2026-04-29T14:00:00Z - 2026-04-29T19:00:00Z
isActive=true
totalTokens=35,577,623
cacheReadInputTokens=34,247,311
cacheCreationInputTokens=1,269,568
outputTokens=60,358
models=claude-opus-4-7, claude-haiku-4-5

The active block corresponds to approximately 16:00-21:00 CEST. At the time Claude Code reported the current session as exhausted, local transcript usage for the active block was only about 35.6M tokens according to ccusage.

I understand ccusage is not an official Anthropic source of truth, but the discrepancy is large enough that the CLI should expose enough attribution/debug information to explain it.

Expected behavior

One of the following should happen:

• If current-session usage is exhausted, Claude Code /usage should show which surfaces/sessions/tokens/models contributed enough usage to exhaust it.
• If usage from Claude Desktop, claude.ai, Claude in Chrome, other devices, or other Claude Code tokens is included, /usage should make that explicit and provide a breakdown or at least a clear attribution category.
• If the session total shown by Claude Code is not the same accounting scope as "Current session 100% used", the UI should label those scopes clearly.
• A trivial prompt after a low visible local session total should not immediately hit the limit unless other usage is clearly attributed.

Actual behavior

Claude Code showed:

• A very small visible local session summary ($0.76, ~436k cache read in the visible session summary).
• At the same time, Current session: 100% used.
• The next trivial prompt immediately produced a hard limit error.
• Local transcript usage for the active block did not explain the current-session exhaustion.

Why this matters

From the user's perspective, there is no way to tell whether:

• the current-session usage calculation is wrong,
• usage from another Claude surface is being included,
• a stale/old Claude Code process is consuming usage,
• another Claude Code authorization token is consuming usage, or
• the account/session has been compromised.

This makes it difficult to distinguish a product bug from a security incident.

Related issues found

I searched existing anthropics/claude-code issues and found several likely related reports:

• [BUG] Claude Max plan session limits exhausted abnormally fast since March 23, 2026 (CLI usage) #38335 — Max plan 5-hour session limit exhausted abnormally fast since March 23, 2026; users report 21% to 100% jumps on a single prompt.
• [BUG] Claude Code Usage for Max Plan hitting limits extremely fast #37394 — Max plan hitting limits extremely fast; user reports one message plus two Python script calls jumping usage from 0% to 24%.
• [BUG] Max 20x plan: 100% usage after 2 hours of light work (5 commits, no agents) #42052 — Max 20x plan reaches 100% after ~2 hours of light work; explicitly links several related abnormal usage drain reports.
• Max 20 plan: rate limit 100% exhausted within ~70 minutes after reset (never happened before v2.1.89) #41788 — Max 20 plan exhausted within ~70 minutes after reset; suspected server-side cached/thinking-token accounting or prompt-cache invalidation.
• [BUG] Critical: Widespread abnormal usage limit drain across all paid tiers since March 23, 2026 — multiple root causes identified, no formal communication issued #41930 — broader report on abnormal usage limit drain across paid tiers, including possible prompt-caching and session-resume causes.

This issue may overlap with those, but the specific additional concern here is the diagnostic mismatch: Claude Code's local /usage and transcript-derived usage do not explain why the global current-session limit is exhausted. The product should expose enough attribution to determine whether usage came from this local Claude Code session, another Claude surface, another token/device, or a server-side accounting bug.

Suggested improvements

Please consider adding one or more of:

• A server-side usage attribution breakdown in /usage, grouped by product surface: Claude Code, Claude Desktop, claude.ai, Claude in Chrome, etc.
• A breakdown by active Claude Code token/session/device where possible.
• A clearer distinction between "this local Claude Code session" and "global current 5-hour account/session limit".
• A warning when usage contributing to the current session is coming from outside the local machine/transcript.
• A support/debug export command that produces a sanitized usage report users can attach to Anthropic support.

Attachments available

I can attach a screenshot of Claude Code /usage showing:

• Local session total cost: $0.76
• Current session: 100% used
• Reset: 9:40pm Europe/Madrid
• Current week all models: 60% used
• Current week Sonnet only: 1% used

I can also provide a private support report with account/session screenshots and sanitized local transcript excerpts. I am intentionally not including account IDs, authorization tokens, bearer tokens, or private project names in this public issue.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Usage limit reached despite UI showing low consumption percentages #51219
2. [Bug] Team Premium usage meter shows 85% but token count indicates ~4% usage #54601
3. [BUG] Limit hit - Usage showing 0% #40725

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

[0xbrainkid]

This is usage-accounting truthfulness failure at the session-limit surface.

If the current session limit reaches 100% despite low visible local session usage, then the meter that users rely on to judge remaining capacity is no longer describing the state they can inspect.

Why it matters:

• users make pacing and compaction decisions based on that meter
• when visible history and reported exhaustion diverge sharply, the operator cannot tell whether hidden state, accounting bugs, or real usage is responsible
• false exhaustion erodes trust in both the meter and the recovery advice built around it

I would want clarity on:

1. whether the 100% reading includes hidden context sources, resumed-state carryover, background/session metadata, or stale accounting
2. whether the cap is enforced by the same backend value shown in the UI, or whether the display and enforcement paths can diverge
3. whether the product can expose a per-source breakdown of what consumed the session budget so users can reconcile meter vs transcript

A limit meter has to be legible to be useful. If it reports full while the inspectable session looks small, the control surface stops reflecting reality.

[BeardOnTheBlock]

This is a pain in the ass. Paying for Max 20x and constantly being told my usage limit has run out while showing sub 20% is annoying af and disrupts my workflow constantly.

It's nearly $200/month. Please do better.

[junaidtitan]

Session limit showing 100% when local usage doesn't justify it is deeply concerning. While the root cause may be server-side, keeping your session JSONL lean helps reduce the tokens billed per turn. Cozempic has 18 pruning strategies and a guard daemon that auto-prunes at 4 thresholds. The cozempic doctor command can also audit your session for hidden bloat (oversized entries, orphaned tool results, stale data) that might be contributing. pip install cozempic && cozempic doctor to inspect, cozempic guard for ongoing protection. Would love to hear what the doctor finds on your sessions.