[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.
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.