What are the three levels of spend control?
A runaway bill usually follows the same script: an agent loops or a scheduled job keeps firing while nobody’s watching, and the dashboard that would show it lags by hours or days. One Claude user’s $6,000 night came from a single command that re-ran 46 times over 26 hours, and the billing dashboard still hadn’t caught up days later when the total surfaced. We’ve written up the full anatomy of that run separately; the provider meter recorded every dollar, and nothing at the run level could pause the loop.
- The account boundary. Most providers give you some way to cap what a key or account spends. They work differently. Some stop requests at a prepaid balance or a spend limit; others only fire an alert you still have to act on, so check which one you actually have. Either way, it covers the whole account. Hit it and every job sharing that key stops at once, even the ones behaving fine. It limits the total bill, but it can’t stop just the job that’s the problem.
- Reporting meters. Token dashboards, per-request cost logs, the month-end spreadsheet. They tell you what got spent and who to bill for it, which is how you notice a cost creeping up and learn what a job really costs over time. The catch is that a meter only reports after the money’s already spent. For a run nobody’s watching, that delay is when the bill runs up.
- Per-run enforcement. A cap on one job, checked by whatever’s running it while it spends. Hit the cap and only that run stops; the account and every other run keep going. Because the budget lives with the job and not the key, one looping run stops without dragging anything else down with it.
Use all three, at the scope each one covers. Per-run enforcement has to live inside whatever runs the job. An account cap or a dashboard sits outside the run, so it can only react to money the run already spent.
What should happen at the cap?
What happens at the cap is a choice you declare in the playbook, and the run enforces it. A hard stop ends the run the moment it hits the cap: the right call when the ceiling is non-negotiable or the partial work isn’t worth keeping, and nobody has to be awake for it. A warm pause keeps the run alive instead. It stops spending, holds the work it has, and parks in an attention inbox with its receipt: what it cost so far and what’s left to do. A person then makes one decision: grant more, or keep what’s already done. Reach for the pause when the work in flight is the expensive part. Reach for the stop when it isn’t.
Two things decide whether the cap actually holds. The check has to happen while the run is going, right before the next model call. Checking the numbers overnight is too late, because by then the money’s already gone. The cap also has to be something the platform enforces, because a prompt can only ask. An agent told to “keep costs low” can’t refuse its own next paid call. Something outside the model has to hold the budget and check it before each call.
How do you attribute spend to each job?
Provider billing groups spend by account or key. What you usually need is narrower: what one job costs each time it runs, and whether that number is creeping up.
The same counter that stops the run also tells you what it spent, because every model call is logged against its run: retries and delegated child stages included. A stage that retries draws from the same run grant, so nothing spends off the books. On Sumn the receipt is the first thing you see when a run finishes: every call, every stage, what it read, wrote and cost. It’s the same number the cap was watching the whole way. Each receipt shows the cost of one run. Several similar runs give you the process’s normal range.
What about multi-model workloads?
Spend control gets harder the moment a job uses more than one provider, which is common in real work: a cheap open-source model for the bulk pass, a frontier model for the judgment call. Now each provider caps and meters only its own slice. A dashboard can add the slices up later. But to catch an overspend that spans providers, you need the running total while it’s still climbing. Whatever’s running the job can keep that one total live across every provider, instead of waiting for each provider’s bill to land.
That’s why you budget at the run level. A per-run cap covers claude-opus-5 and deepseek-v4-pro in the same envelope, whichever keys they ride on.
Two rules keep that total honest once a run fans out into stages or delegates to a child run. Costs roll up: whatever a child stage spends counts against the parent run’s grant, so nothing dodges the cap by handing work off. Grants only flow down: a stage can pass a child less budget than it holds, but it can never pass along more. The run’s cap stays the real ceiling no matter how many stages or models sit underneath it.
What’s the minimum viable setup?
Do these four things, in order:
- List every account and key, then turn on the strongest limit each provider actually enforces. Where a provider only offers an alert, set the fastest one and treat it as reporting rather than a cap.
- Give each stage its own short-lived credential. Instead of one long-lived key that every job shares, each stage gets a credential scoped to its job that expires when the stage does.
- Log per-job cost even crudely. Once a job has a few successful runs behind it, set the cap just above their normal range. You can’t pick a sane number for spend you’ve never measured.
- Add per-run enforcement for anything scheduled, unattended, or able to touch money or production. Build it into your own harness, or use a platform where every run comes with a budget.
If your agents only run while you’re watching, you can stop at step three. Per-run enforcement earns its place the moment a run goes unattended, whether it’s on a schedule or just left going after you close the laptop. For everything else an unattended run needs, the production checklist covers approval and the record.