How to put a spending cap on an AI automation

The "monthly budget" setting in the OpenAI dashboard does not stop your spend. As of June 2026 it is a soft threshold that only sends an alert: OpenAI's own help center says that when usage passes the budget, API requests keep being processed without interruption. Anthropic does enforce a real per-workspace monthly spend limit in the Claude Console, but it is monthly and shared, so a single runaway loop can still drain the whole month's budget before the cap trips, and it takes every other automation in that workspace down with it. The control that actually stops one bad run is a per-run token and step budget enforced inside the automation, with a daily kill switch sitting above it.

This matters because the failure mode is not gradual. An automation that quietly works for months can run up a month's spend in twenty minutes when a filter breaks or an agent gets stuck. The provider dashboard is the wrong place to catch that, and most "limit your AI costs" guides point you straight at it.

Why the provider budget setting won't stop a runaway loop

There are two different controls people confuse. One is the provider's account-level limit. The other is a guard inside your workflow. Only the second one stops a specific bad run, and the two providers behave differently enough that you have to know which you are dealing with.

On OpenAI, the project "monthly budget" is an alert. You set a number and a notification threshold, and when spend crosses it the owners get an email while the requests keep flowing. This is a real change from the old behavior, where a hard monthly cap would block calls. OpenAI removed that hard cap, so if your mental model is "I set $50 and it stops at $50," it is wrong. It stops nothing.

On Anthropic, a per-workspace spend limit in the Claude Console does cap monthly spending for that workspace. That is a genuine ceiling. But it is coarse in two ways that matter for a runaway loop. It is monthly, so it does nothing to slow a loop that burns the whole budget in one afternoon. And it is per-workspace, so when it finally trips, every API key and every automation in that workspace stops at once, including the ones that were behaving. You also cannot set or adjust it through the API, only in the Console, so it is not something a workflow can tighten on its own.

Control	OpenAI	Anthropic	What it actually does
Dashboard monthly budget	Soft alert only	Per-workspace hard cap	Monthly, account-wide; will not stop a single fast loop in time
Rate limits (RPM, TPM)	Yes	Yes, per workspace	Slows throughput, does not bound total cost
Per-run budget in your workflow	You build it	You build it	The only thing that stops one specific run mid-flight

The takeaway: treat the provider control as a backstop for the catastrophic case, not as your spend control. It is the smoke detector, not the thermostat.

The three places automation cost actually runs away

Spend rarely spirals from normal traffic getting a little heavier. It spirals from a small number of structural mistakes that multiply. There are three common ones.

The first is an unbounded loop over a list. Your workflow pulls rows from a sheet or a CRM and calls a model on each. It worked when the query returned 40 rows. Then a filter changes, the query returns 6,000, and the loop dutifully calls the model 6,000 times. Nothing errored. The automation did exactly what you told it.

The second is retries that re-call the model. A failing step gets retried, and the step it retries includes an expensive model call. Now combine that with the loop above: a transient API hiccup on a large batch can re-run hundreds of model calls. This is the same idempotency problem that creates duplicate records, applied to cost. Before you turn on auto-retry for a step that calls a model, read when an automation should retry a failed step, because the no-code retry toggle re-runs the whole step with no guard.

The third, and the most expensive, is an agent that re-plans in a loop. An agent calls a tool, reads the result, decides what to do next, and calls again. If a tool keeps returning an error the agent does not know how to handle, it keeps trying, re-sending the growing conversation each time. A task that should take three model calls can hit sixty before anyone notices.

Put rough numbers on that last one. Say a single agent step costs about two cents in tokens, which is a fair estimate for a few thousand tokens of context plus tool output on a mid-tier model. Three steps per ticket is six cents. Sixty steps is over a dollar a ticket, and if the same bug hits a queue of 500 tickets overnight, you wake up to a 600-dollar surprise instead of a 30-dollar day. The per-call price is small. The multiplier is what gets you.

The guard that stops one bad run: a per-run budget

The fix for all three is the same shape: a hard ceiling that the run itself checks and respects. Two numbers do most of the work.

A maximum step or iteration count. For an agent, set the max number of tool-call cycles, commonly 8 to 15 for a focused task, and stop when it is reached. For a loop over a list, cap the number of items a single run will process, and if the list is longer, either split it deliberately or alert instead of grinding through all of it. Most agent frameworks have a max-iterations or max-steps setting. If yours does not, keep a counter and break the loop yourself.

A per-run token budget. Track input plus output tokens as the run proceeds and abort when it crosses a ceiling set from real usage, not a guess. If a normal run uses 10,000 tokens, a 30,000-token cap catches a loop early while leaving room for a heavy but legitimate case. When the budget is hit, do not silently drop the work. Route it to a human or a dead-letter queue so you find out a record needed attention.

Here is how that lands in the common tools:

• In code, wrap the loop or agent call in a counter and a running token total, and throw when either exceeds the limit. This is the cleanest place to enforce it.
• In n8n, use a counter variable plus an IF node to break a loop, and cap the items going into a Split In Batches node. The agent node exposes a max-iterations setting; use it.
• In Zapier or Make, the model is more linear, so the practical guard is limiting how many items enter the run and not stacking model calls inside a loop without a counter path.

If you are building agents rather than linear workflows, the step cap is not optional. An agent without a maximum is a loop without a maximum. We design these guards into every agent and custom AI system we build, because the cost of forgetting one is paid in a single bad night.

Add a daily kill switch above the run

A per-run budget stops one bad execution. It does not stop a thousand mediocre executions, or the same bug firing on every record in a queue. For that you want a cheap circuit breaker one level up.

Keep a small counter somewhere your workflow can read and write: a database row, a key-value store, a single cell. Increment it on every run, or add up estimated cost per run, and reset it on a schedule. Before a run does any expensive work, it checks the counter. If today's runs or today's estimated spend are over your ceiling, the workflow short-circuits and sends one alert instead of doing the work. You decide whether to lift the limit or fix the cause.

This is the layer that would have caught the 600-dollar night. The per-run cap keeps any single ticket from spiraling. The daily counter notices that something is firing far more often than normal and pulls the plug before the queue drains your month. It costs you one extra read at the top of the workflow. Build this into the same place you handle logging and alerting, alongside what you log in every automation, so the run that gets stopped also leaves a record of why.

How to start

Do it in three passes, cheapest first.

Set the provider backstop today. On Anthropic, put a per-workspace monthly spend limit in the Console and a spend notification below it. On OpenAI, set the project budget alert and accept that it only warns you, then wire that alert to something you actually read. This is ten minutes and it is the floor, not the plan.

Next, add a per-run step and token budget to your highest-spend automation, the one with an agent or a loop over a list. Measure a week of real runs first so your ceiling reflects reality instead of a guess. Then add the daily counter above it.

If you are not sure which of your automations can run away, the tell is simple: any workflow with a loop over a variable-length list, an auto-retry on a model step, or an agent with no step cap. Those are the three. If you want a second set of eyes on where your stack is exposed, tell us what you are running and we will point at the spots that need a guard. The goal is not to spend less on AI. It is to make sure a broken filter at 2 a.m. costs you a stopped run and an alert, not a month's budget.