Setting Hard Spend Caps So an AI Agent Can't Run Away with Your Bill

A basic chat feature makes one call per user message, so the worst case cost is bounded by how many messages a person can reasonably send. An agent that plans, calls tools, and evaluates its own output can call the model dozens of times for a single user request, and a bug in its stopping logic can turn that into thousands of calls before anything else in the system notices something is wrong.

Give every agent task a maximum token budget before it starts, not just a maximum number of steps. Step limits alone can still allow runaway cost if each step involves a large context window, so budget in tokens, and have the agent stop and report back once it hits the ceiling rather than silently continuing. A reasonable starting budget is whatever your most expensive successful task has historically used, with headroom, not an arbitrary round number picked without looking at real usage.

Separate the per-task budget from a per-user or per-account daily and monthly ceiling. A single task can be within budget and still be one of many that, taken together, blow past what a user or account should reasonably cost in a day, especially if something is triggering the same task repeatedly rather than looping within one run.

A circuit breaker needs three things: a hard ceiling on spend or calls per task, a kill switch that actually stops execution rather than just logging a warning, and an alert that reaches a person, not just a log file nobody's watching. The kill switch is the part teams skip most often, building elaborate monitoring that correctly detects the runaway loop and then does nothing to stop it, which defeats the purpose.

A working circuit breaker setup includes these controls:

• A hard ceiling on spend or calls per task, backed by a per-task token budget rather than a step limit alone.
• A kill switch that actually stops execution, not one that only logs a warning.
• An alert that reaches a person, not just a log file nobody is watching.
• A graceful failure with a clear message when the breaker trips, instead of letting the agent keep trying in a degraded mode.
• Enough logging at the point of tripping to show what the agent was doing, how many calls it made and what triggered the stop.
• Tracking of tasks that land close to the ceiling, since they often signal a prompt or tool change that made the agent less efficient.

Trip the breaker and the task fails gracefully with a clear message, rather than trip it and let the agent keep trying in a degraded mode, which often just delays the same runaway pattern. Log enough detail at the point of tripping, what the agent was doing, how many calls it made, what triggered the stop, that an engineer can diagnose the root cause without having to reproduce a live incident from scratch.

A well-tuned budget rarely trips, which means the interesting signal is tasks that get close to the ceiling without tripping it, since that's often an early warning of a prompt or tool change that's making the agent less efficient before it becomes an outright runaway. Track how often tasks land in the top band of their budget the same way you'd watch a burn multiple drift the wrong way before it becomes a real problem.

Review that near-miss rate on the same cadence you review spend itself, since a rising trend there is the leading indicator, and the invoice is the lagging one. By the time a budget is tripping regularly, the underlying inefficiency has usually already been costing money for weeks.

Say an agent is built to research a topic, draft a summary, then critique its own draft and revise until the critique step is satisfied. That self-critique loop is exactly the shape that produces the worst runaway cases, because the stopping condition depends on the model's own judgment of whether the output is good enough, and a model that's mildly miscalibrated can keep deciding its own work needs one more pass indefinitely.

Design the exit condition for a self-critique loop as a hard step count first, with the quality judgment as a secondary factor, not the reverse. A loop that stops after a fixed number of revision passes, keeps the best one, and ships is bounded no matter what the model decides about its own output. A loop that only stops once the model is satisfied has no such bound built in, and needs the budget and circuit breaker doing all the protective work with nothing structural helping it.

The same failure shape shows up in retry logic: an agent that retries a failed tool call is fine, but one that retries and re-plans from scratch on every failure can rebuild an increasingly expensive plan several times over for what was originally one task. Cap retries at the task level, not just at the individual call level, so a chain of failures doesn't multiply cost at every layer.