[BUG] Excessive Max plan usage drain from session restart storms and agent tool-loops (v2.1.216, Opus)
Environment
- Claude Code version: 2.1.216
- Model: opus[1m]
- Plan: Max (flat-rate, resets Jul 29)
- OS: macOS 26.4
- Shell: zsh
- Plugins: frontend-design, clangd-lsp
- MCP: BlenderMCP (uvx/blender-mcp)
- Editor mode: normal
Summary
Since July 23, Claude Code has been burning through the Max plan's usage allocation at an abnormal rate due to repeated session restarts and long-lived agent tool-loops. Usage cap resets July 29 but the remaining 3 days are at risk of being consumed by the same buggy behavior before any productive work can be done.
Bug Pattern A: Session Restart Storm
On July 26 alone, 20 sessions were spawned in the same project directory (renders), many within minutes of each other:
00:01:51 renders (first)
00:03:19 renders +88s gap
00:06:49 renders +210s gap
00:08:39 renders +110s gap
00:21:46 renders +787s gap
00:45:45 renders +1439s gap
01:00:49 renders +904s gap
01:29:58 renders +1749s gap
02:01:05 renders +1867s gap
02:59:12 renders +3487s gap
03:36:40 octobot +2248s gap
05:08:02 renders +5482s gap
07:57:57 renders +10195s gap
08:08:43 renders +646s gap
10:35:53 octobot +8830s gap
11:53:35 renders +4662s gap
11:54:33 renders +58s gap
13:41:51 renders +6438s gap
14:27:08 renders +2717s gap
14:42:27 renders +919s gapEach restart incurs a full context load overhead (system prompt, tool definitions, conversation history replay). With Opus-4-8 pricing, even a single wasted restart burns significant token overhead.
Bug Pattern B: Long-Lived Broken Agent Loops
Session a1c85daf spanned 3 days (Jul 23 12:44 to Jul 26 14:39 = 4,435 min) with only 206 messages (2.8 msgs/hr). Other examples:
| Session | Duration | Messages | Msgs/hr |
|---------|----------|----------|---------|
| a1c85daf | 73.9h | 206 | 2.8 |
| f3420e2b | 61.7h | 192 | 3.1 |
| cf4b2abf | 41.8h | 63 | 1.5 |
| 9a9ebf59 | 41.6h | 61 | 1.5 |
| d62b1d5a | 32.2h | 61 | 1.9 |
These are characteristic of agent tool-loops: the model keeps calling tools and consuming tokens, but the user is only sending occasional messages. The agent is generating significantly more output than the user's input warrants.
Bug Pattern C: Repeat-Fail-Restart Cycle
The agent repeatedly failed to fix the same issue across sessions, each time requiring a full re-contextualization:
22:10 "I was trying to play but its bugged, kairo is totally bugged"
00:23 "omg its not the best... the robes are bugged"
00:46 "no its not working correctly..."
01:16 "restart, delete what is there and start over"
05:10 "do the process again its still bugged"
11:00 "we have the same bug still, she is lying face down, gigantic"Usage Impact (Last 7 Days: Jul 19-26)
| Metric | Value |
|--------|-------|
| Sessions | 59 |
| Est. token consumption | 6,927M tokens |
| Est. list-price value | ~$6,069 |
| Avg daily burn | ~$867/day |
| Peak single day | $2,179 |
| Renders project share | $3,012 (50%) |
| Today burn | $1,492+ |
Tool-Call Volume Imbalance
On high-volume days, the tool-call-to-message ratio is excessive:
| Date | Messages | Tool Calls | Ratio |
|------|----------|------------|-------|
| Jul 13 | 2,907 | 2,110 | 0.73 tool/msg |
| Jul 18 | 3,111 | 1,169 | 0.38 |
| Jul 20 | 6,327 | 2,169 | 0.34 |
Each tool call generates input tokens (call arguments) + output tokens (tool results). With Opus-4-8 pricing, excessive tool calling amplifies burn significantly.
Request
- Usage credit or cap reset for the July cycle -- the majority of consumption was from buggy agent looping, not productive work
- Investigation of the tool-loop pattern in long-lived sessions -- sessions running 40-70 hours with <3 msgs/hr should not consume the full monthly allocation
- Session restart cost optimization -- each restart reloads the full system prompt and tool registry (100K+ context tokens), burning significant overhead on every restart
Evidence Available
All data collected from local Claude Code session logs, history, and cost tracking. Can provide raw logs on request.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Fully agree, have been using Max 20x for months without ever reaching limits and suddenly, I reach the full limit in one afternoon?
this is a regression and it makes, even a Max 20X unable to work for more than a few hours. Its a disaster.
Agree. It is incredible how such a smart system can burn tokens without reason, invalidating the cache even when it would need very little effort to avoid it.
The restart-storm + tool-loop combo is exactly how Max allocation dies without productive work.
What I've seen cut the same bleed on macOS fleets:
If you still have the Jul 26 session list (20 in one project), the timestamps of session starts vs tool-loop bursts usually show whether restarts or loops burned more of the remaining days before Jul 29.
Adding related Billing Platform / cost-control context from another paid Claude billing path, kept public-safe.
This report is important because it separates productive user work from paid allocation drain caused by restart storms, long-lived tool loops, and repeated re-contextualization. That is the same owner boundary my case keeps hitting from a different angle: paid account state, usage-credit / allocation state, charge triggers, and support routing do not reconcile cleanly.
My direct case is manual prepaid / bulk Claude usage-credit purchases failing or failing to commit cleanly, while automatic usage-credit reloads on the same paid billing setup continue charging successfully. That split does not behave like an ordinary card decline. This issue adds the runtime-cost side: paid plan allocation can be consumed by restart/tool-loop behavior with little or no productive outcome, and the remedy needs more than generic support guidance.
Requested triage path: please route this class of reports to a human Billing Platform / cost-control / agent-runtime owner who can inspect session restart overhead, agent loop detection, per-project/session spawn patterns, cache/context reload accounting, paid allocation debits, and support/credit-adjustment policy together.
Concrete guardrails that would help paid users:
Public, privacy-sanitized evidence hub for my related billing case:
https://coolak.github.io/anthropic-claude-billing-incident/
Billing reconciliation matrix / owner map:
https://coolak.github.io/anthropic-claude-billing-incident/reconciliation-matrix.html
I am intentionally not posting card details, bank names, private payment IDs, invoice IDs, support IDs, raw logs, screenshots, payment URLs, one-time codes, or private support-thread text here.