[Bug] Scheduled routine consumes entire token quota in single execution without safeguards

Hi, following up on this — any update on whether this token usage was expected for this kind of routine config, or whether a per-run budget cap for Claude Code Remote scheduled triggers is being considered? Happy to provide more details if useful. Thanks!

The detail that makes this a design problem rather than a surprise is in your own diagnosis: a single session cloning 32 repos with no context isolation doesn't cost 32×N, it costs closer to Σ(growing context) — every task after the first carries the accumulated context of all prior repos, so the token curve is superlinear in the number of sources. That's why the cost was unforeseeable from the config: the config lists 32 sources and 3 tasks, but the actual spend is a function of how context accretes across them, which isn't written anywhere in the config.

Two things address it, at different layers:

1. Make a dry run actually dry. A validation pass should resolve the fan-out (32 sources × 3 tasks = 96 units) and estimate — even crudely, tokens-per-unit × units — without executing a single model call. "Does this config parse, and how big is it" is answerable statically; you shouldn't have to spend the quota to discover the quota.

1. Isolate context per source, then cap at the unit boundary. One session for 32 repos is the root of the superlinear cost; a fresh context per (repo, task) makes cost linear and cappable. Then a hard ceiling that refuses to start the next unit once a run crosses N — rather than one that only reports after the fact — means "validate the config" can never silently become "spend everything."

The general trap is that the only number that mattered — total cost — was emergent from the run, not declared by it. The enforcement that survives that has to sit outside the run and fail closed at a clean boundary; a limit the run reports to itself is one it has already blown past by the time it notices.

Thanks for the thoughtful breakdown, @deemwario — the superlinear-cost framing (Σ of growing context rather than 32×N, because context accretes across sources in a single un-isolated session) matches exactly what I observed, and the "dry run should estimate statically without a single model call" / "cap at the unit boundary, fail-closed outside the run" distinction is the right way to put it.
▎
▎ For what it's worth, I've since restructured my own setup away from the single-session fan-out, so this is no longer an active pain point on my end. Leaving the issue open as it still points at a real design gap — hoping for an official take on whether a per-run budget cap for scheduled triggers is on the roadmap. Appreciate you taking the time.

Glad restructuring to per-source isolation fixed it in practice — that's the load-bearing change, and it's telling that the fix was architectural rather than a config flag.

Agreed on leaving it open for an official take. The one thing a per-run cap alone won't cover: the cap has to fail closed at the unit boundary, i.e. refuse to start unit N+1 once cumulative spend crosses the ceiling, not just abort mid-unit or report after. A cap the run enforces on itself is one it can already have blown past by the time it checks; the enforcement that survives sits outside the run and gates each unit before it begins. A static dry-run estimate (units × tokens-per-unit, zero model calls) is the other half — it turns 'discover the cost by paying it' into 'see the cost before you commit.' Both are cheap to state and, from experience, the difference between a scheduled routine you can trust unattended and one you can't.