[BUG] Hung Cowork scheduled task silently consumed full Max 20x Fable allowance + $1,031.92 in 48h with no alert or spend cap
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?
[BUG] Hung Cowork scheduled task silently consumed 100% of Max 20x Fable allowance + $1,031.92 in auto-recharges in 48h — no spend cap, no alert, no way to terminate the session
Summary
A Cowork scheduled task bound to a persistent session hung and continued consuming tokens with no scheduled task remaining in my account, no visible session, and no alert of any kind. It consumed 100% of my included Fable allowance on day one of my billing cycle and generated eleven usage-credit auto-recharges totaling $1,031.92 in 48 hours, against a normal baseline of one ~$85 recharge per active day.
The first and only notification I received was the stack of charge emails I woke up to.
I am filing this as a product issue rather than a billing complaint because the billing outcome is downstream of four defects that I think affect every Max subscriber using scheduled tasks:
- A resumed persistent session can spend without bound.
- There is no per-task or per-session spend cap available to set.
- There is no threshold alert — not at 50% of a weekly allowance, not at 100%, not at $500 of overage.
- There is no way to see or force-terminate a resumed persistent session from the app. Nine days later I still cannot confirm whether the session is running.
Environment
- Plan: Max 20x
- Surface: Cowork scheduled tasks (
send_later/ cron triggers via the Claude Code Remote MCP) - Billing cycle: 2026-08-01 → 2026-08-08
- Account email: available on request (omitted from a public issue)
What happened
Between 2026-07-17 and 2026-07-30 I ran a chain of ~49 one-shot send_later scheduled tasks. 46 of the 50 tasks in my account were bound to a single persistent session (persist_session: true), so each firing resumed that session rather than starting fresh, replaying a context that had been accumulating for two weeks.
The last task fired 2026-07-30 at 17:50 UTC. Its prompt instructed it to schedule a successor if its work was incomplete. No successor was ever created. list_triggers (50 records, complete list, no pagination cursor) confirms no scheduled task in my account was due to fire at any point after 2026-07-30. The only still-enabled trigger is a daily read-only watchdog running ~15 lines of SQL.
Two days later, on August 1 — day one of a fresh billing cycle — the account began burning:
| Date | Charges | Total |
|---|---|---|
| Aug 1 | $200.00, $82.57, $82.01, $80.40 | $444.98 |
| Aug 2 | $82.07, $89.38, $86.25, $83.13, $80.01, $85.24, $80.86 | $586.94 |
| Aug 3 | $80.91 | $80.91 |
| Aug 6 | $80.95 | $80.95 |
| Aug 7 | $94.57 | $94.57 |
| | 14 charges | $1,288.35 |
I did not use Fable interactively on August 1 or 2. I began using it knowingly on August 3. Eleven auto-recharges fired in those first two days — roughly six times my normal daily rate — with no interactive session of mine open.
I discovered it on the morning of August 3 when I woke to a stack of charge notifications on my phone. There was no in-product warning at any point.
Why the remaining charges also trace to the defect
Per published policy, Fable 5 is included on Max at up to 50% of weekly usage limits at no extra cost.
At the point I captured my usage page on Aug 7:
- All models: 59% used
- Fable: 100% used (i.e. the full included 50% of the weekly pool)
So roughly 50 of the 59 points consumed that cycle were Fable I did not use, and ~9 points were everything I actually did. I had 41% of my all-models pool remaining and was nowhere near my plan limits — yet every Fable call from Aug 3 onward billed at API rates, because the included allowance had already been spent by the hung task.
I was on vacation that week with unusually light usage. Absent this, I would have finished the cycle with zero overage.
Expected behavior
- A scheduled task, or a session resumed by one, should not be able to consume an entire weekly model allowance and then $1,000+ in metered credits without a single alert.
- Users should be able to set a spend ceiling for background/scheduled work.
- Users should be able to see and terminate a running persistent session.
- Exhausting an included per-model allowance should notify the account holder before metered billing begins, not after fourteen charges.
Actual behavior
Silent, unbounded spend. First notification was the charges themselves. No mechanism existed — and still does not — to observe or stop it.
Possibly related
- #79337 — Fable 5 prompts "usage credits required" on Max, from the 2026-07-20 rollout
- #79412 —
/modelshows Fable 5 as credits-only on Max while/usageshows it plan-covered
My usage page currently displays: "Fable 5 is still included with your Max plan. If you see a prompt to set up usage credits for it, restart Claude Code." — which suggests the Fable/credits classification path on Max is known to be unreliable. I have asked support to check whether any of my 14 charges were incurred while included allowance still remained. No answer.
Support status
Opened via the in-app support messenger on 2026-08-02. Escalated to a human queue the same day. Followed up 2026-08-07 with full diagnostics, invoice detail, and screenshots.
As of 2026-08-11 — nine days — I have received no human response.
I also asked support to preserve per-model usage records for the cycle before it rolled over on Aug 8, since the usage page retains no prior-week history. I have no confirmation that was done.
Identifiers for engineering
- Persistent session:
session_01J9Y3J1tJu7LbGHL2wFxENK(46 of 50 tasks bound to it) - Last-fired trigger:
trig_01Fy1wCqNKTqJipK4MBuG5PF— 2026-07-30 17:50 UTC - Only enabled trigger:
trig_012dnNEsyShqzXtmQhRXq84a(daily, read-only)
Happy to provide the full trigger export, invoice detail, and usage screenshots to anyone who can act on this.
<img width="1568" height="1119" alt="Image" src="https://github.com/user-attachments/assets/e5b4aa1b-9bb8-466b-bc5a-11607dbac688" />
<img width="1439" height="1083" alt="Image" src="https://github.com/user-attachments/assets/fd8b1958-a3c0-43ea-98b9-4ffd0b5dc815" />
What Should Happen?
four numbered fixes: a settable spend ceiling, an alert before metered billing starts, a way to see and kill a running session, and tasks that stop when their chain ends.
Error Messages/Logs
This is a bug where the system produced no error, no warning, and no notification.
Steps to Reproduce
I can't hand a deterministic reproduction for a server-side session that hung.
Claude Model
Other
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
N/A — Cowork (Claude desktop app), not Claude Code CLI
Platform
Other
Operating System
Windows
Terminal/Shell
Other
Additional Information
_No response_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗