How to Put a Spending Cap and Kill Switch on an AI Agent

An agent without limits is a credit card handed to a very fast intern who never sleeps. Most of the time it’s fine. The one time a tool returns an error the agent doesn’t understand, it retries, reads the error, retries again, and keeps going until your API balance is gone.

I run a lot of agents, and the rule I follow is simple: no agent goes live until it has a spending cap, a step limit, and a kill switch. None of them is hard to add. Skipping them is the expensive choice.

Why agents overspend

A normal script does the same amount of work every time. An agent decides how much work to do, and that’s the point of using one. It’s also the risk. Four things cause nearly all runaway bills:

1. Retry loops. A tool fails, the agent tries again with a slightly different input, fails again, and repeats.
2. Growing context. Every step adds to the conversation, so each call costs more than the last. A 40-step run costs far more than 40 times a 1-step run.
3. Fan-out. The agent spawns sub-tasks, each of which spawns more.
4. A trigger that fires too often. A scheduled job or inbound webhook runs 500 times instead of 5.

If you want the numbers behind the per-call cost, I broke them down in AI agent cost math. This post is about the ceiling, not the average.

Limit 1: a hard spending cap

Set two numbers for each agent: a maximum spend per run and a maximum spend per day.

Pick them from what the job is worth. If an agent triages your inbox and saves you twenty minutes a day, it should not be allowed to spend $40 on a single run. A good starting point is five times what a normal run costs. If a typical run costs 20 cents, cap a run at $1 and a day at $10. You can raise the cap the first time it blocks legitimate work, which is a good problem to have.

Two places to enforce it:

• At the provider. Set a monthly spend limit in your Anthropic or OpenAI console. This is your backstop and takes two minutes. It stops the worst case even if your own code is wrong.
• In your own code. Keep a running total of tokens used during a run, convert it to dollars, and stop when it passes the per-run cap. Store the day’s total somewhere durable so a restart doesn’t reset it.

Limit 2: a maximum number of steps

A step cap is the simplest guard and catches loops that the dollar cap catches too late. Decide the most steps a healthy run should ever take, add a margin, and stop there.

If your longest normal run takes 12 tool calls, set the limit at 25. When the agent hits it, don’t let it quietly continue. End the run, record why, and send yourself a message. A run that hits the step cap is a bug report, and you want to read it.

The same idea works for repeated identical calls: if the agent makes the same tool call with the same input three times in a row, stop it. That’s a loop, not progress.

Limit 3: a kill switch that needs no deploy

When something is going wrong at 2 a.m., you don’t want to edit code, rebuild, and redeploy. You want to flip one switch.

A kill switch is a single flag the agent checks at the start of every step, not just at the start of a run. If the flag says stop, the agent stops. Where the flag lives matters less than the fact that you can change it from your phone: a key in a key-value store, a row in a database, or an environment variable that your platform lets you edit without redeploying.

Build in these details:

• Check it often. A flag only read at startup can’t stop a run already in progress.
• Make stopping safe. The agent should finish or roll back the action it’s in the middle of, not leave a half-sent email or half-booked appointment.
• Fail closed. If the agent can’t read the flag, it stops. A broken flag store shouldn’t mean unlimited spending.
• Test it once. Flip the switch on a staging copy and watch it stop. An untested kill switch is a hope.

I covered a related control, the approval step, in human-in-the-loop agents. Approval gates stop bad actions. Caps stop bad spending. You want both.

Add alerts so you hear about it first

Limits protect your budget, but you still need to know when they fire. Send a message at 50% and 80% of the daily cap, and every time a run is cut off by a step limit or the kill switch. Then read them. An alert you’ve learned to ignore is worth nothing, so if one fires constantly, fix the cause or adjust the limit.

If you’re also logging each step with a trace ID, you can see exactly which run burned the money. I describe that setup in how to debug an AI agent in production.

Prompt to add all three limits

You don’t need to write this yourself. Open Claude in the folder where your agent’s code lives and paste this:

Read my agent's code. Add three safety limits and show me every file you change:
1. A per-run and per-day spending cap, computed from token usage. Read the limits
   from configuration, and stop the run with a clear logged reason when either is hit.
2. A maximum step count per run, plus a stop if the same tool is called with the same
   input three times in a row.
3. A kill switch: a flag checked before every step that stops the agent safely.
   If the flag can't be read, the agent must stop.
Then list what you assumed about where the flag should live, and give me a short
checklist to test each limit on a non-production copy.

Before you trust the result, check three things: that the dollar math uses your model’s current prices (the model may guess them), that the flag is read on every step, and that you’ve run each limit once and seen it trigger. Models will happily write a cap that never fires.

Start with the strictest numbers you can live with

Set the limits tight on day one and loosen them with evidence. A cap that blocks a legitimate run costs you a few minutes. A missing cap can cost you a month of budget in a night. Put the limits in before the agent touches anything real, and the rest of the build gets a lot calmer.