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

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:

• https://github.com/anthropics/claude-code/issues/38335 — Max plan 5-hour session limit exhausted abnormally fast since March 23, 2026; users report 21% to 100% jumps on a single prompt.
• https://github.com/anthropics/claude-code/issues/37394 — Max plan hitting limits extremely fast; user reports one message plus two Python script calls jumping usage from 0% to 24%.
• https://github.com/anthropics/claude-code/issues/42052 — Max 20x plan reaches 100% after ~2 hours of light work; explicitly links several related abnormal usage drain reports.
• https://github.com/anthropics/claude-code/issues/41788 — Max 20 plan exhausted within ~70 minutes after reset; suspected server-side cached/thinking-token accounting or prompt-cache invalidation.
• https://github.com/anthropics/claude-code/issues/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.