[Bug] Rapid, unexplained usage limit consumption during normal usage
Bug Description
Unexpected rapid increase in both the 5‑hour usage limit and the weekly usage limit - At the start of this session, the 5‑hour context usage indicator was approximately 20%. While working normally for about 20 minutes, the usage percentage began increasing unusually fast — jumping in increments of 5–10% every ~2 minutes. Within that short period, the indicator reached 70%, despite only light interaction.
This behavior is not isolated. in the past few days, I noticed similar sudden jumps, but at the time I wasn’t paying close attention and assumed it might be normal. Today, however, I observed the increases directly and can confirm they occurred in real time.
In addition to the 5‑hour limit rising abnormally, the weekly limit has also been consumed much faster than expected. The weekly usage climbed significantly during the same period, even though my activity level did not justify such a rapid increase.
Environment Info
- Platform: win32
- Terminal: windows-terminal
- Version: 2.1.226
- Feedback ID: f1f55c4f-3fe0-4b06-9242-763f6b2ae9cc
Errors
[]Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Corroborating telemetry from a session where I could pin the cause down — in case it helps separate "unexplained" from "explained but unbounded".
Environment: Claude Code 2.1.224 (VS Code/Cursor native extension), macOS arm64,
effortLevel: "xhigh"set globally in~/.claude/settings.json, main modelopus[1m].I ran the bundled
/code-reviewskill against a self-hosted GitLab merge request. Parsed directly out of the session JSONL (main transcript + 20 subagent transcripts):| metric | value |
|---|---|
| subagents spawned | 20 (peak ~11 concurrent) |
| API calls | 786 |
| cache-read input tokens | 72,513,717 |
| cache-write input tokens | 8,296,022 |
| output tokens | 877,385 |
| wall clock, main burn window | 36 min |
| models |
claude-fable-5(743 calls),claude-opus-5(40) || mean context per subagent call | ~126k tokens (max 179,764) |
That consumed the entire 5-hour window. Roughly 72M of the ~80M input tokens are pure context re-transmission: 20 subagents × ~35 turns × ~126k context each.
Worth being precise: there was no loop and no malfunction in my case. The fan-out did what a high-effort review fan-out is designed to do. So this may well not be the same defect the OP hit. What it does demonstrate is that a single slash command can legitimately consume a full window in under 40 minutes, with:
If the OP's 5–10%-per-2-minutes jumps coincided with background subagents, that invisibility (see #84705) would make legitimate fan-out cost indistinguishable from a billing bug — which may be part of why reports in this area are hard to triage.
Two changes that would have prevented my case outright:
xhighpersists across runs with nothing in the transcript to indicate it.I encountered the same situation. After resetting on Monday morning, I checked my weekly usage that evening and found that 20% had already been used. The work I did was the same as before. Later, when monitoring usage, I found that the increase was in line with expectations. However, I don't know where that initial 20% usage came from.
I have the same issue today.
We are paying customers. What's going on here? Worked the whole week for hours without a problem, now my session limit is supposed to run out in 5 minutes? wt*