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

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/51219
2. https://github.com/anthropics/claude-code/issues/54601
3. https://github.com/anthropics/claude-code/issues/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

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.

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.

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.

I have the same issue:

I seem to be blocked from using my workplace's Claude, both Claude Code in the terminal I'm currently typing in, and the desktop app. However, this is despite having very little usage of Claude, in particular compared to my colleagues. What happens is my session starts at no usage and then after a few seconds of getting Claude to do a task, it immediately goes to 100% usage and then stops, telling me I'm now at 100% usage and it will reset in a few hours. Can you please help me fix this?

Same symptom here, June 11, 2026 - Claude Code 2.1.173, macOS (Darwin 25.3.0).

My session limit hit 100% after roughly 5–10x LESS local usage than the previous day,
which did not exhaust the limit. Numbers below are exact sums of the usage fields from
local Claude Code transcripts (~/.claude/projects/**/*.jsonl), not estimates:

| Day | API calls | Output tokens | Cache write | Cache read | Session limit |
|---|---|---|---|---|---|
| June 10 (3 parallel sessions) | 906 (600 Fable 5, 306 Opus 4.8) | ~1,236k | 6.8M | 214.2M | never hit |
| June 11 (work seat) | ~299 (~241 Fable 5, ~52 Sonnet 4.6) | ~340k | 1.5M | 21M | 100% used twice a day |

• Weekly meters look plausible (All models 26%, Sonnet 22%) — it's specifically the

5-hour session meter that doesn't match local usage.

• Same machine, same projects, same settings both days. No ANTHROPIC_API_KEY /

ANTHROPIC_AUTH_TOKEN overrides.

• The 100% is shown on the claude.ai usage page as well, so this is server-side accounting,

not a local display issue (re-login does not help).

This matches the attribution/accounting pattern described in the OP and in #38335. +1 for a
server-side usage breakdown by surface/session — right now there is no way to see what
consumed the session budget.

Related: I filed #68271, which isolates one narrow piece of what's described here — the terminology overloading in the /usage view itself.

Independent of the accounting question raised in this issue, the panel reuses the word "session" for two unrelated scopes in the same screen: the top "Session" block (Total cost, etc.) is the current CLI run, while the "Current session" limit bar is the rolling ~5-hour account-wide window. That collision is a big part of why it's hard to tell which "session" hit 100% here. #68271 proposes just renaming one of the two so the scopes are unambiguous.

Adding a concrete, reproduced root cause for the "limit at 100% despite low visible usage" symptom: on --resume, the prompt cache is fully rebuilt every turn, and those cache_creation_input_tokens count against your rate limit while showing up as almost nothing in visible local usage. This is the hidden drain.

Still happening on CLI 2.1.183 — well after the fix attributed to ~2.1.90 (#42309) — specifically for the per-turn --resume pattern that GUI/agent wrappers use (a fresh claude --resume <id> process per message). Same fingerprint as #42338 / #34629 / #43657.

What I measured

One ~2h session, context grew to ~730k tokens. 143 model requests. Most turns hit cache (16–60s). But several turns did a full cold re-prefill:

cache_read_input_tokens     = 15,951        ← frozen at this exact value every cold turn
cache_creation_input_tokens = 122k → 232k → 464k → 649k → 716k   (≈ full context, re-billed each time)

That constant 15,951 is just the static system+tools prefix — matching #27048's "~19K preserved, everything after rewritten" and #34629's ~14.5k cache_read floor. Everything else is re-created and billed as cache_creation on every resume.

Why visible usage looks low while the limit drains

cache_creation is the expensive part of the bill and the rate-limit hit, but tools/dashboards that surface "session usage" tend to show output/visible tokens, not the silent re-prefill. So you burn limit at roughly context_size × turns instead of Δcontext × turns, with nothing obvious to point at. On a long session that's the difference between ~$0.50/hr and several $/hr (cf. the ~20x figure in #34629).

Not the 5-minute TTL

Two of the cold re-prefills happened 35s and 58s after the prior turn — inside the cache window, with neighboring turns warm. So it's structural prefix invalidation on resume reconstruction (consistent with the deferred_tools_delta v2.1.69 tool-reordering cause in #42338), not expiry.

Minimal repro

# Build a session to a few hundred K tokens, then within seconds:
claude --print --resume <session-id> --output-format stream-json "ok"
# usage on that turn: cache_read ≈ ~15k (system prefix only, does NOT grow),
#                     cache_creation ≈ full context size. Repeats every turn.

Environment: claude 2.1.183, claude-opus-4-8, invocation includes --output-format stream-json --input-format stream-json --resume <id>, wrapper spawns a new process per turn. Happy to share full per-turn usage traces.

Related: #42338 (locked), #34629 (closed), #43657 (closed, not planned), #42309 (claims fix in 2.1.90 — incomplete for this path).

Same symptom here (Max 20x, v2.1.199, macOS) — with what looks like a root-cause candidate and an immediate recovery procedure, since I caught it with live evidence on both sides of the disagreement.

Summary

After legitimately exhausting a 5-hour window with 5 parallel Claude Code sessions (fleetview; all Fable 5, auto mode, xhigh effort), 3 sessions surfaced the usage-limit UI but 2 remained "stuck" in an intermediate state. From then on, every new Claude Code request on the account was blocked with "You've hit your session limit" — across models (Fable 5, Opus 4.8, Haiku 4.5), effort levels (xhigh → low), fresh sessions in other directories, and Claude Code web — while the CLI's own /usage panel and claude.ai's usage settings both reported the current session at 3%. The enforcement counter read 100–102% with a reset clock (2:20am) that did not match the meters' clock (2:30am). claude.ai chat was unaffected throughout.

Recovery: aborting the 2 stuck sessions with Ctrl+C immediately released the block — hours before the displayed 2:20am reset. This strongly suggests the enforcement state was held open by the stuck client sessions (unreleased in-flight reservations, or a background retry loop re-pinning the counter), rather than by a server-side timer.

Environment

• Claude Code v2.1.199, macOS (iTerm2); block also reproduced on Claude Code web (claude.ai/code)
• Plan: Max 20x · Timezone: America/Los_Angeles · Thu Jul 2, 2026

Steps to reproduce (as best understood)

1. Run several parallel Claude Code sessions (5 here, via fleetview) on a high-burn configuration (Fable 5, auto mode, xhigh effort) until the 5-hour session window is legitimately exhausted.
2. Observe that some sessions surface the usage-limit UI while others hang in an intermediate state (exact stuck-state UI not captured — sessions were aborted before screenshotting).
3. Leave the stuck sessions running and wait for the session window to lapse (~2.5 h here).
4. Attempt any new Claude Code request (any model, any effort, any directory, CLI or web): blocked with "You've hit your session limit," while /usage and claude.ai settings show the session meter nearly empty.
5. Ctrl+C the stuck sessions → block clears immediately.

Evidence timeline

| Time (PT) | Surface | Event |
|---|---|---|
| afternoon–7:00 PM | CLI ×5 (fleetview) | Fable 5 / auto / xhigh; legitimately exhausted the 5h window. 3 sessions showed the usage-limit UI; 2 appeared stuck |
| 7:00 PM | — | Weekly window rolled over (weekly limits reset Thu 7:00 PM; meters show "resets Jul 9 at 7pm") |
| 7:00–9:20 PM | — | No intentional usage (stuck sessions still running) |
| ~9:20 PM | — | Enforcement window opens (inferred from the 2:20am reset clock) — plausibly a stuck session's background retry, since my manual resume was ~9:30 PM |
| 9:31 PM | CLI | continue blocked: "session limit · resets 2:20am". Status line 5h: 100%→2:20a \| 7d: 1% |
| 9:31 PM | claude.ai settings | Current session 0%; weekly all-models 1%, Fable 2% — nonzero weekly with zero successful post-rollover requests ⇒ attribution lag across the weekly boundary |
| 9:35–9:40 PM | CLI | /model opus → blocked; fresh session in another directory (Opus, xhigh) → blocked; /model haiku + /effort low → blocked. Status line now 102% |
| 9:29–9:45 PM | claude.ai chat | Works normally throughout, same account/browser |
| 9:41 PM | claude.ai settings | Current session 3%, resets ≈2:29–2:30am |
| 9:44 PM | Claude Code web | New cloud session (Haiku 4.5): blocked, "Resets Fri, Jul 3, 2:20 AM" (the CLI's clock); transient "Server is temporarily limiting requests" banner at init |
| 9:45 PM | CLI /usage | Current session 3%, resets 2:30am (matches claude.ai, contradicts status line/enforcement). Weekly all-models 2%, Fable 2%. Local blocked session: $0.0000, 0 input/output/cache tokens |
| ~9:50 PM | CLI | Ctrl+C on the 2 stuck sessions → all sessions resumable immediately, well before the 2:20am reset |

Screenshots available for every row.

Key observations

1. Enforcement and metering disagreed within the same CLI binary: status line 100–102% (reset 2:20am) vs /usage panel 3% (reset 2:30am), simultaneously.
2. The /usage session meter matched claude.ai settings exactly ⇒ the shared account meter was correct; the enforcement counter was the outlier.
3. The block followed the Claude Code product path (CLI + Code web, same reset clock) while chat was untouched.
4. The reset-clock gap fits blocked-requests-bill-zero: the meter's window opened at the first successful request (a chat message, ~9:30pm); the enforcement window's ~9:20pm open predates my manual resume and likely traces to stuck-session activity.
5. The counter climbed 100% → 102% while every request was refused and zero local tokens were billed.
6. Recovery via Ctrl+C, not via timer, implicates held client state (reservation leak or retry loop) as the mechanism.

Requests

• Investigate how a hung/stuck session can hold or re-pin the 5-hour enforcement counter after the underlying window lapses (and across the weekly rollover boundary — the wall-hit and rollover coincided at ~7:00 PM here).
• Ensure enforcement reservations are released on session hang/timeout, not only on clean exit.
• Label the enforcement counter vs. the metered "Current session" distinctly in the status line and /usage, since they can diverge by ~100 points.
• Consider surfacing "another live session is holding capacity" as an actionable message instead of "you've hit your session limit."

Related

Same symptom family: #61828 (enforcement blocks while claude.ai panel shows under-limit, web chat unaffected — near-identical scenario), #42277 (new window exhausted in 10–15 min). Possibly related accounting issues: #38335, #41930, #41788. Posting the short workaround on #61828 as well, since this recovery may unblock people there.

I reproduced a controlled version of this account-wide attribution problem on a Claude Max 20x account.

Recurring problem and start of today's incident

The current incident began at approximately 03:00 Mauritius time on August 3, 2026, when usage started being depleted after the daily reset despite no corresponding intentional Claude activity. The unexplained depletion continued during the day across multiple usage windows.

This was also not the first time I had experienced the broader problem: similar unexplained depletion occurred during the previous week. During an earlier incident, approximately $150 of separately purchased credits was also consumed, but my central concern here is not the credit-purchase policy—it is that I still cannot determine what requests were attributed to my account.

The timeline below is the latest and best-instrumented reproduction of the problem that began at approximately 03:00 that day.

Controlled timeline

On August 3, 2026, at approximately 23:01 Mauritius time (19:01 UTC), the signed-in Claude Usage page showed:

• Current session: 0%
• “Starts when a message is sent”
• Weekly all-model usage: 57%
• Fable usage: 5%

I did not send a message or intentionally use Claude after the reset.

At approximately 23:05 Mauritius time (19:05 UTC), the page showed:

• Current session: 11%
• A new five-hour window with approximately 4h54m remaining
• Weekly all-model usage: 59%

At 23:13 Mauritius time (19:13 UTC), without intentional Claude activity, it had increased again:

• Current session: 59%
• Weekly all-model usage: 66%
• Fable usage: 6%

At 23:19 Mauritius time (19:19 UTC), still without intentional Claude activity:

• Current session: 100%
• Weekly all-model usage: 72%
• Fable usage: 6%

The entire new five-hour allowance was therefore consumed in approximately 18 minutes without a prompt being sent.

Usage-credit spending remained $0.00, the credit balance did not change, and usage credits and auto-reload remained disabled.

Local evidence

A passive watcher sampled the Mac every 10 seconds throughout the controlled period. It recorded no non-baseline:

• Claude or IDE process activation
• Claude session-file modification
• Matching Claude/IDE network connection

This appears distinct from the --resume cache-rebuild and stuck-process explanations discussed above: Claude Code was not intentionally run, no prompt was sent, and no corresponding local activity was observed.

Support difficulty

I have also been trying to get this investigated through Anthropic support under Conversation ID 215475337901788. Organization ID for Anthropic account correlation: d2a6bf95-6095-40a6-b8b7-7e2b7f7b5251. After repeated exchanges with the automated support agent and a human response, I still have not received confirmation that Anthropic inspected the request-level ledger. The discussion has repeatedly returned to refund policy even though my principal request is identification of what generated the usage and restoration of the unexplained allowance.

Could Anthropic please inspect the requests attributed to this account from approximately 03:00 Mauritius time on August 3, 2026, with particular attention to the controlled 19:01–19:19 UTC interval, as well as the earlier unexplained depletion reported in that support conversation? Please determine the originating product surface/client or session category and confirm whether this was another device/session, an integration, a background service, or a metering defect.

A sanitized diagnostic showing product surface, request timestamps, model, and token totals would make it possible to distinguish a security incident from an accounting problem. I have retained the timestamped local evidence and can provide it privately to Anthropic.

Thanks @akshayramdass — this matches my case closely. Max 20x, weekly meter read zero on Sat 1 Aug afternoon, then 50% all-models / 100% Fable by Sun 2 Aug evening with the account idle and no scheduled tasks. Fable was never invoked during the cycle.

Adding my support conversation for correlation: 215475330722681. Between us that's two Max 20x accounts on separate continents reporting idle-period depletion within days of each other, both stuck in refund-policy responses rather than ledger inspection.

Linking to #54750 as the canonical thread, and noting #82074 — I also have Claude for Chrome authorised, so if that OAuth grant is invisible to session controls it's a candidate surface here too.

Second controlled reproduction — August 4, 2026

I completed another isolated post-reset test on the same Claude Max 20x account.

At approximately 04:00 Mauritius time on August 4, 2026 (00:00 UTC), the Claude Usage page showed the current session at 0%. I did not send any prompts or intentionally use Claude afterward.

The session then increased without intentional use:

| Mauritius time | UTC | Current session |
|---|---|---:|
| ~04:01 | ~00:01 | 1% |
| ~04:05 | ~00:05 | 2% |
| 04:44 | 00:44 | 4% |
| 04:46 | 00:46 | 5% |
| 04:50 | 00:50 | 7% |
| 04:55 | 00:55 | 8% |
| 04:58 | 00:58 | 9% |
| 05:00 | 01:00 | 11% |
| 05:08 | 01:08 | 13% |
| 05:15 | 01:15 | 14% |
| 05:20 | 01:20 | 15% |
| 05:23 | 01:23 | 16% |
| 05:25 | 01:25 | 20% |
| 05:28 | 01:28 | 26% |
| 05:30 | 01:30 | 29% |

During the same controlled period, weekly all-model usage increased from 72% to 77%. Fable remained at 6%.

Controls in place during the sustained increase:

• Every visible Claude connector was disconnected.
• Claude Desktop was logged out.
• Claude in Chrome was blocked.
• Artifacts were disabled.
• Claude Code was not run.
• No Claude API call was made.
• No prompt was sent.
• Usage credits and auto-reload remained off.
• Credit spending stayed at $0.00 and the existing credit balance remained unchanged.

A verified local watcher remained active throughout the sustained increase. It recorded no corresponding non-baseline Claude/IDE process appearance, Claude-file modification, or matching Claude/IDE network activity.

This reproduced after the connectors were disconnected and without observable Claude activity on the monitored Mac. It does not match the workaround involving terminating a locally stuck Claude Code process because no such process was active.

Support case for private account correlation: 215475337901788.

Could Anthropic please inspect the request-level ledger covering approximately 00:00–01:30 UTC on August 4, 2026, particularly the accelerated increase from 01:23–01:30 UTC? Please identify the originating product surface or session category, model and token totals, OAuth client or token family, and whether this represents another authenticated session, retained background work, delayed attribution, or a metering defect.

I have retained the timestamped incident summary and underlying watcher evidence and can provide them privately to Anthropic. I am intentionally not uploading raw machine logs publicly.

Related automatic-recharge reports

Two additional reports appear particularly relevant to the earlier automatic recharges associated with this incident:

• #68773 reports 29 automatic recharges, including six within ten minutes, followed by the same inability to obtain human billing escalation through Fin support.
• #81941 reports 35 Usage Credit charges, many occurring overnight while the account holder was asleep and their computers were off, with charges appearing at regular four-to-six-minute intervals.

These reports do not establish that the same mechanism affected my account, but they reinforce the need for Anthropic to inspect the request-level and auto-reload ledger rather than treating the matter solely as a standard non-refundable credit purchase.

Additional independent corroboration — August 4, 2026

This Reddit report now documents multiple Max users describing the same idle-drain pattern, including usage increasing after resets while computers were off, authorization tokens had been deleted, and scheduled tasks had been paused or removed:

https://www.reddit.com/r/ClaudeAI/comments/1v8d1ck/possible_claude_max_usage_bug_session_limit/

A separate user has also linked that discussion from #82506 after reporting continued depletion despite closing all sessions, powering off or reformatting computers, and deleting authorization tokens: https://github.com/anthropics/claude-code/issues/82506#issuecomment-5180686754

These community reports do not establish a root cause, but they provide independent corroboration and make an ordinary local stuck process less persuasive. Anthropic still needs to inspect the account-level request ledger to identify the originating product surface, authorization family, request metadata, model, and token totals. My controlled reproductions and support correlation remain documented in #54750 under support Conversation ID 215475337901788.

Incident index: zero-client Max allowance consumption and related billing effects

This remains unresolved and reproducible across resets. On August 4 (Mauritius time), I ran a controlled idle test after a fresh five-hour reset: the current-session meter rose from 0% to 13% without prompting Claude or running Claude Code. Connectors were disconnected, usage credits and auto-reload were disabled, spending remained at $0 during the observation window, and a local watcher found no corresponding non-baseline activity.

The important new development is independent corroboration with a closely matching zero-client timeline:

| Evidence | Idle state | Meter movement | Financial/account effect |
|---|---|---|---|
| My August 4 controlled reproduction | No prompts; Claude Code not run; connectors disconnected | 0% to 13% after reset | Separate dispute concerning approximately $150 in additional usage-credit charges |
| #84374 | User asleep; no client open; consumption reportedly continued after sessions were revoked and during machine-off periods | 40% of a fresh session over 2h20, plus weekly/Fable increases | Unrequested Pro-to-Max 20x plan change reported immediately beforehand |
| #84358 | Separate customer report | Phantom extra usage alleged | Unrequested Max upgrade and multiple extra-credit charges reported |

#84394 documents a real and reproducible authentication/billing-transparency problem involving a hidden credentials-file fallback. It appears to be a different mechanism, because that case billed Console/API credits while subscription allowance remained largely unused; it should not be treated as an explanation for every zero-client subscription-meter report.

My refund and investigation request has now reached Anthropic's human-support queue, but I have not yet received a human response. I am not claiming a confirmed root cause. The public evidence now supports asking four specific technical questions:

1. Is Anthropic investigating zero-client Max allowance consumption as an incident?
2. For the documented windows, which product surface and authorization family generated the metered activity?
3. Were actual inference requests, models, and token totals recorded, or did the allowance state change without corresponding requests?
4. Can affected customers receive a sanitized server-side usage-attribution export to reconcile subscription allowance and usage-credit charges?

Community corroboration and a structured public timeline are also collected here. Affected users should add precise timestamps, timezone, meter changes, client/device state, and billing effects rather than posting credentials or private account data.

Thank you for indexing my report, and for the controlled reproductions — the
10-second sampling and the explicit control list are considerably more rigorous
than anything I was able to document after the fact.

A few reports you may not have come across yet, in case any of them are useful.

Billing side (plan or credits altered without user action)

• #51168 (2026-04-20) — Pro annual silently changed to Max. The reporter

states the trigger was redeeming a promotional voucher. Billing symptoms only,
no metering component. Predates the earliest reproduction in this thread by nine
days.

Metering side (zero-client consumption)

• #61012 (2026-05-21, OPEN) — Pro account, session limit repeatedly reaching

100% without use, including overnight. The reporter had logged out of all
devices, verified no scheduled tasks via API, and identified a clean gap in local
logs across the affected window.

• #65687 (2026-06-05, OPEN) — usage continuing to climb while Claude Code sits

inactive.

• #58355 (2026-05-12) — Claude Desktop, background consumption with roughly

5% of the weekly allowance lost overnight.

One pattern that might be worth recording in the index itself: the billing-side
reports (#51168, #41499, #47290, #76087) are all labelled invalid, while the
metering-side ones carry bug + area:cost. Whatever the reason for that split,
the effect is that the billing half has never accumulated in one place — which may
be part of why the two halves have not been looked at together.

On #51168 specifically, since it is the only one with a documented trigger: the
Help Center describes claiming a promotional credit as "turns on usage credits for
your account, but you're only charged if you buy additional usage credits later"
(https://support.claude.com/en/articles/15862783). If that report's account of the
trigger is accurate, the documented behaviour and the observed behaviour do not match.

It is really disappointing the way they handle customer support, leaving AI Agent always respond to you even by email and nothing is solved even after requesting several times a Human to handle my case!!
I had other issue that happen as soon as I upgraded to 20X from the 5X plan, with in 2 to 3 days the whole weekly limit vanishes!! for a month now I can not even for once reach the hourly limit, I used to reach the hourly limit at the 5X plan several time per day before the weekly limit start to count a meaningful value, and I was struggling to consume all the weekly limit on the 5X plan, now it is totally the opposite!, I do not even make it the 30% or 40% limit of the hourly limit and my weekly limit just vanish with in 2 to 3 days every week, this is the last week in my 20X plan and honestly I will definitely reconsider using Anthropic AI and start using other Chinese models !