[BUG] Session usage shows "100% used" with $0.0000 cost and 0 tokens consumed
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?
've encountered this issue twice in the past few days
across two different machines (Windows and Parrot
OS Linux), both on the Pro plan using Claude Sonnet
5.
First occurrence (Windows machine):
Session showed 100% used after a session with
real activity: $1.07 total cost, 22.2k input / 15.4k
output / 751.3k cache read / 125.7k cache write
on claude-sonnet-5, plus some claude-haiku-4-5
usage.
The /usage breakdown attributed this to
subagent-heavy usage (100% of usage from
subagent-heavy sessions, 72% from subagents
under "claude"). This one made sense — heavy
subagent orchestration burned through the 5h
window fast. Second occurrence (Parrot OS Linux machine, same
account):
Session shows 100% used, but:
Total cost: $0.0000
Total duration (API): 0s
Usage: 0 input, 0 output, 0 cache read, 0
cache write
No code changes, no measurable API activity of
any kind, yet the session bar reads 100% used and
blocks further prompts until reset (3:59pm
Africa/Porto-Novo that day).
Weekly usage (all models) showed only 19% used
at the same time, so this isn't a case of hitting a
real weekly cap either.
This second case has zero token/cost correlation
with the reported 100% usage, which suggests a
display or backend sync bug rather than an actual
limit being reached — similar to previously reported
issues where usage counters became inaccurate and
blocked messages entirely.
Environment
Plan: Pro
Model: Claude Sonnet 5
What Should Happen?
Session usage percentage should correlate with
actual measured token/cost consumption. A session
showing $0.0000 cost and 0 tokens across all fields
should not be marked as 100% used.
Error Messages/Logs
Session usage bar shows 100% used with all
underlying metrics (cost, duration, tokens) at zero,
blocking further prompts until the stated reset time.
No explicit error message was shown in the terminal
— Claude Code did not throw a visible error when the
prompt was blocked. The only indication was the
/usage panel itself:
Session
Total cost: $0.0000
Total duration (API): 0s
Total duration (wall): 3m 57s
Total code changes: 0 lines added, 0 lines removed
Usage: 0 input, 0 output, 0 cache read, 0 cache write
Current session
[100% used]
Resets 3:59pm (Africa/Porto-Novo)
Current week (all models)
[19% used]
Resets Aug 1, 5:59am (Africa/Porto-Novo)
I don't have local session/debug logs saved from this
instance (wasn't aware I'd need them until the
inconsistency appeared). If there's a specific log file
or --debug flag the team wants me to capture next
time this happens, let me know and I'll attach it in a
follow-up comment.Steps to Reproduce
- Use Claude Code normally on Windows machine
until session usage naturally reaches 100% (in
this case, driven by subagent-heavy orchestration
— confirmed via /usage breakdown).
- Wait for the session to reset (reset time shown in
/usage ).
- On a separate machine (Parrot OS Linux), same
Anthropic account, open Claude Code and check
/usage before sending any prompt, or after
sending very few/no prompts.
- Observe that "Current session" show3. On a separate machine (Parrot OS Linux), same
Anthropic account, open Claude Code and check
/usage before sending any prompt, or after
sending very few/no prompts.
- Observe that "Current session" shows 100% used
despite Total cost = $0.0000, Total duration (API)
= 0s, and 0 input/0 output/0 cache read/0 cache
write.
- Confirm weekly usage (all models) is far from
capped (19% used) at the same time, ruling out an
actual weekly limit being hit.
I was not able to reliably reproduce this on demand —
it appeared unprompted when checking /usage on
the second machine. Happy to try specific
reproduction steps if the team has a hypothesis to
test.
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.208 (Claude Code)
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Reproduced again just now (July 25, ~12:42pm Africa/Porto-Novo). Same pattern: banner 'You've hit your session limit', but Total cost $0.0000, API duration 0s, 0 input/0 output/0 cache read/0 cache write. Ran with claude --debug this time — no debug output appeared, which suggests the block happens before any API request is actually sent, i.e. a client or server-side quota check reading a stale/incorrect counter rather than an actual usage-based limit."
Update: reproduced again after updating to latest version — bug persists identically
Ran npm install -g @anthropic-ai/claude-code to force-update to the latest version (was already on the auto-update channel, but a previous auto-update attempt had silently failed with install_failed). After confirming the update succeeded, reproduced the exact same bug:
Banner: "You've hit your session limit · resets 9pm (Africa/Porto-Novo)"
/usage shows: Total cost $0.0000, Total duration (API) 0s, 0 input/0 output/0 cache read/0 cache write
Current session bar: 100% used
Current week bar: only 28% used (rules out real quota exhaustion)
This confirms the bug is not version-related — same symptom before and after updating to the current latest release (v2.1.208, native install).
Also confirmed the same behavior in the VS Code extension (Claude Code for VS Code), not just the CLI terminal — the "You've hit your session limit" banner appeared immediately after a trivial one-word prompt ("yo"), same $0/0 tokens pattern. So this isn't isolated to one client surface.
Environment: Parrot OS (Linux), native install, Claude Pro plan, Sonnet 5.
Update: clarifying the actual bug — this is a display inconsistency, not (necessarily) a false quota block
After further analysis, I want to narrow down what's actually being reported here, since some of my earlier framing may have been imprecise.
What's likely NOT a bug: the session limit block itself may be legitimate. My usage pattern involved running multiple Sonnet subagents in parallel (via an orchestration skill spawning several agents at once) on a large repo, which is consistent with genuinely exhausting the ~5-hour rolling session window on a Pro plan. The weekly limit (19-28% used) and the session limit (100% used) are two independent counters, so they aren't contradictory.
What IS a bug: when the block triggers, /usage displays for the current session:
Total cost: $0.0000
Total duration (API): 0s
Usage: 0 input, 0 output, 0 cache read, 0 cache write
But: "Current session: 100% used"
This is misleading — a user hitting a legitimate limit sees stats implying zero consumption, with no indication that the block stems from background subagent usage or a prior session's consumption. This makes the block look like a false positive even when it may not be one.
Also observed: a background subagent was terminated mid-task by the same "You've hit your session limit" error — worth confirming whether subagents draw from the same session pool as expected, and whether subagent termination on limit-hit is intended behavior or should be handled more gracefully (e.g., pause/resume instead of hard kill).
Suggested fix direction: the /usage display should reflect the actual rolling-window consumption that triggered the block (e.g., total across recent subagent activity), not just the current interactive session's own $0/0-token count, which is trivially zero for a session that never got to send a request.
Environment: Parrot OS (Linux) and VS Code extension, both reproducing the same display inconsistency, Claude Pro plan, v2.1.208.
Adding related public context because this issue is another case where Claude usage/limit state and the numbers shown to the user do not reconcile cleanly. I am not saying it is the same root cause as my case.
This report describes
/usageshowing the current session at 100% used while total cost, API duration, input tokens, output tokens, cache reads, and cache writes are all zero. The follow-up comments narrow the likely problem to a quota/session-limit check or rolling-window accounting path whose result is not reflected in the visible usage breakdown.My unresolved billing case is a different surface: manual prepaid / bulk Claude usage-credit purchases fail or fail to commit, while automatic usage-credit reloads on the same paid billing setup continue charging successfully. The overlap is the owner gap: visible usage counters, session-limit evaluation, subagent attribution, usage-credit ledger state, auto-reload/payment events, and support routing can disagree while the user is still blocked or charged.
Requested triage path: please route this class of issues to an owner who can reconcile session/weekly counters, subagent consumption, model entitlement, usage-credit ledger state, and billing/support records together, instead of treating each surface as an isolated display bug or generic top-up problem.
Privacy-sanitized public evidence hub for the related billing/ledger case:
https://coolak.github.io/anthropic-claude-billing-incident/
Owner/reconciliation matrix:
https://coolak.github.io/anthropic-claude-billing-incident/reconciliation-matrix.html
I am intentionally not posting card details, bank names, payment IDs, invoice IDs, support IDs, screenshots, raw logs, payment URLs, or private support-thread text here.
Same here https://github.com/anthropics/claude-code/issues/81684
And technical support isn't responding!
It's outrageous to pay so much for a service and get no support.