[BUG] Hung Cowork scheduled task silently consumed full Max 20x Fable allowance + $1,031.92 in 48h with no alert or spend cap

Status Open
Maintainer reply None cached
Activity 2 comments · opened Aug 11, 2026

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:

  1. A resumed persistent session can spend without bound.
  2. There is no per-task or per-session spend cap available to set.
  3. There is no threshold alert — not at 50% of a weekly allowance, not at 100%, not at $500 of overage.
  4. 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 — /model shows Fable 5 as credits-only on Max while /usage shows 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_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗