Anatomy of a $6,000 night

The confession at the top of the r/ClaudeAI post is one sentence: “I accidentally burned ~$6,000 of Claude usage overnight with one command.” The command ran 46 times over 26 hours, unattended. The usage dashboard had a multi-day reporting lag, so the number was history before it was visible. The thread reached 1,291 points, which for a billing story tells you how many readers recognised their own setup in it.

It would be easy to file this under user error and move on. The author left a loop running; loops loop. But read the mechanics slowly and the incident stops being about one person’s night. Every piece of that setup performed to its spec, and stopping was in none of the specs. The bill was papercuts, stacked 46 runs high.

Where the money leaked

Two systems touched that spend, and both did what they were built to do:

• The loop started work. That’s its job. Run 46 looked no different to it than run 1.
• The meter measured. The number just showed up days after the money was gone. Usage reporting runs behind the spend, and days behind is normal.

What the setup didn’t have was a third thing: machinery whose job is to refuse, to say this run has spent enough, stop and ask. That’s the gap the $6,000 fell through. A spend alert wouldn’t have closed it either: an alert tells you, it doesn’t stop anything.

The moment that mattered

Somewhere in the first hour or two, the night’s total crossed whatever the author would have set as a limit if anything had asked. Call it $20. The design question is what should happen at that moment, and most systems give one of two answers.

Nothing happens. The budget is a dashboard number, not an enforcement point. That’s the incident as it played out.

The run gets killed. Enforcement is real, and the price is the work in flight. Nobody wants a cap that throws away half a night’s work, so caps like that get set high enough to never fire.

There’s a third answer, and it’s the one we built:

On Sumn the cap is enforced mid-run. At the number you set, the run checkpoints, keeps every finished stage, and parks in your attention inbox with its receipt so far: what the money already bought, and the choice in front of you. Grant more and it resumes where it paused. Decline and you keep what’s done. Set the cap at $20 and the night costs $20, then a question.

The shape of the work changes too. On Sumn, work that repeats is a stage set to retry inside one run, with its own internal budget, and every retry counts against the run’s grant. The author’s 46 starts had nothing above them; the night’s structure lived inside a model-driven loop instead of being written down where something could enforce it.

The same night, twice:

Why the cap holds when it matters

Two rules make the cap mean what it says, both enforced by the platform, not the prompt:

• Costs roll up. When a run fans out into parallel stages or spawns children, every descendant’s spend counts against the same grant. Nothing dodges its cap by delegating.
• Grants flow down. A stage can hand work onward with less budget than it holds, never more. The cap you set at the top is the cap.

The 46-run night is the failure mode where instructions stop helping: a loop doesn’t reread its guidelines between iterations, and whatever the model wants next, the platform declines the call.

Account-level provider limits, spend alerts and per-run enforcement are three different tools, and teams usually discover the differences during an incident. The spend budgets guide walks the full comparison, including where each one belongs.