claude-code - 💡(How to fix) Fix Bug: Claude Code current session limit reaches 100% despite low visible local session usage [2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#54750Fetched 2026-04-30 06:37:04
View on GitHub
Comments
2
Participants
3
Timeline
7
Reactions
1
Timeline (top)
labeled ×3commented ×2cross-referenced ×2

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.

Error Message

  • The next trivial prompt immediately produced a hard limit error.

Root Cause

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.

Code Example

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

---

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

---

npx ccusage@latest blocks --json

---

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
RAW_BUFFERClick to expand / collapse

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:

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.

extent analysis

TL;DR

The current session limit exhaustion in Claude Code may be due to incorrect usage accounting or attribution, and adding a server-side usage attribution breakdown in the /usage page could help diagnose the issue.

Guidance

  • Review the related issues found (e.g., #38335, #37394, #42052, #41788, #41930) to see if they are experiencing similar problems with usage accounting or attribution.
  • Consider adding a breakdown by active Claude Code token/session/device in the /usage page to help identify the source of the usage.
  • Look into adding a warning when usage contributing to the current session is coming from outside the local machine/transcript to alert users of potential security issues.
  • Use the ccusage command to inspect local Claude Code transcript usage and compare it with the usage reported in the /usage page to identify any discrepancies.

Example

No code snippet is provided as the issue is more related to the product's usage accounting and attribution rather than a specific code problem.

Notes

The issue may be related to a server-side accounting bug or a security incident, and it's essential to investigate further to determine the root cause. The suggested improvements, such as adding a server-side usage attribution breakdown and a breakdown by active Claude Code token/session/device, could help diagnose and resolve the issue.

Recommendation

Apply a workaround by regularly checking the /usage page and using the ccusage command to monitor usage and identify any discrepancies, while waiting for the product team to implement the suggested improvements to address the usage accounting and attribution issues.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING