Stop a Runaway AI Agent From Burning Your Budget

A runaway AI agent is a loop that never reaches its stopping condition, and the fix is not a bigger provider spending cap. Cap each run inside your own orchestration with two limits at the same time: a step limit, meaning the maximum number of turns the agent may take, and a per-run token or dollar budget you accumulate on every turn and check before the next call. The two catch opposite failures. A step limit stops a fast loop where the agent makes many cheap calls in a row, and a token budget stops a slow bleed where the turn count stays low but the context grows every turn until each call is expensive. Set only one and you are protected against half the ways an agent runs away.

The reason this matters more for agents than for a fixed workflow is the same reason agents are useful. An agent picks its own path at runtime, looping over its tools until it decides it is done, which we walked through in AI agent vs workflow. A workflow you drew cannot run 40 times by accident, because you drew how many times it runs. An agent can, because "how many times" is a decision the model makes while nobody is watching. Anthropic's own agent guidance is blunt about this: a task "often terminates upon completion, but it's also common to include stopping conditions (such as a maximum number of iterations) to maintain control." An open loop with no stopping condition is how a small mistake becomes a large invoice.

Why a provider spending cap will not save you

The first instinct when an agent overspends is to set a spending cap in the provider dashboard. That is worth doing, but it is the wrong layer to rely on, and understanding why is the whole point. There are three places you can bound an agent's cost, and they fire at three very different moments with three very different blast radiuses.

Limit	What it caps	Where it lives	When it fires	What it misses
Provider spending cap	Total dollars, monthly, across your whole org	OpenAI or Anthropic dashboard	After a monthly threshold across all usage	One run. It is org-wide and monthly, so a single loop can burn a day of budget first, and when it trips it stops every automation you run
Framework step limit	Number of turns in one run	Your agent framework (max_turns, max_iterations)	After N LLM calls in that run	Cost. N turns carrying a huge context can be expensive, and the default N is picked for capability, not safety
Per-run token or dollar budget	Dollars in one run	Your own loop, checked each turn	Mid-run, the moment the budget is crossed	Little. This is the only limit denominated in the thing you care about, but you have to build it yourself

Read down the "when it fires" column. The provider cap is the last to react and the widest in effect, so leaning on it means you find out about a runaway when it has already spent real money and taken your other automations down with it. It is the smoke alarm in the parking lot. The limits that actually contain a single run live inside the run, in your framework and in your loop, and those are the two most people never set.

This is a close cousin of the point in does a spending cap stop your AI spend: a provider budget is containment for the account, not control for the run. An agent needs both, and the per-run controls are the ones that stop the bleeding in seconds.

A step limit and a token budget catch opposite runaways

Here is the part most "set max_iterations and move on" advice skips. A step cap and a token budget do not overlap. They protect against runaways that fail in opposite directions, and neither one covers the other's case.

A step cap catches the fast ping-pong. The agent calls a search tool, gets a result, decides to verify it, calls another tool, decides to search again, and repeats. Each call is small and cheap, so the dollar cost climbs slowly, but the turn count climbs fast. A step limit of 12 or 20 stops this cleanly because the failure shows up as raw turn count. A token budget is slow to react here, because 30 cheap turns might still be under your dollar limit when the real problem is that the agent is obviously stuck.

A token budget catches the slow bleed. The agent takes only 8 turns, well under any sane step cap, but on every turn your orchestration re-sends the full running transcript plus the last tool's output. The context grows each turn, so turn 8 might carry 25,000 input tokens where turn 1 carried 3,000, and the cost per call rises even though the turn count looks fine. A step cap never trips, because 8 turns is normal. Only a running token total sees the cost climbing and pulls the plug. This growing-context runaway is the one that surprises people, because the agent looks well-behaved by every count except the one that bills you.

That is why you set both. They are not redundant. A step cap without a token budget lets a fat-context run get expensive under the turn limit, and a token budget without a step cap lets a cheap loop spin longer than it should before it trips. The wall-clock timeout is a useful third bound for the same reason we covered in AI automation timeouts: LangChain exposes max_execution_time alongside max_iterations precisely because time, turns, and tokens are three different ways to run away.

The five reasons agents loop, and the fix for each

Caps contain a runaway. They do not explain it. If you want fewer runaways to contain, it helps to know why agents loop, because most causes have a cleaner fix than a hard cap. We see five.

A permanent error read as retryable. A tool returns a 404, a 401, or "record not found," and the model cannot tell "try again in a minute" from "this will never work." So it rewords the input and tries again. The fix is to make failures machine-clear and terminal, and to not dress a permanent error up as a transient one. This is the agent version of the retry question in when an automation should retry: retrying a permanent failure is just a loop with extra steps.

A two-tool ping-pong. The agent searches, then verifies, then searches the same thing again because it has no memory that it already ran that exact call. The fix is to dedupe. If the same tool is invoked with near-identical arguments twice in one run, short-circuit and return the earlier result, or feed the repeat back to the model as a signal that it is going in circles.

An unsatisfiable goal. You asked the agent to pull a purchase-order number, and this particular document does not have one. With no way to say "it is not here," the agent keeps hunting. The fix is a give-up affordance, an explicit tool or output that means not found or unresolvable, so the model has an exit that is not "keep trying."

Context that grows every turn. Each turn appends the full tool output to the running context, so the call gets bigger and costlier as the run goes on. The fix is the token budget above, plus trimming or summarizing tool outputs so the context does not balloon. This is the failure a step cap cannot see.

No termination affordance at all. The agent has tools to act but no tool that means "done, but I failed." So when it cannot succeed, its only available move is to act again. The fix is to always give the agent a clean way to stop and hand off. An agent that can escalate to a human will, instead of looping until a cap kills it.

The pattern across all five: a soft exit prevents the loop, and a hard cap contains the ones that slip through. The give-up tool and the dedupe are the soft exit, and they keep quality high because the agent stops cleanly and escalates. The step cap and token budget are the hard backstop, and they keep you solvent when the soft exit fails. You want both kinds, and most teams ship with neither.

What a runaway actually costs, and where the caps land

Numbers make the case. Take a support-triage agent with a knowledge-base search tool and a create-ticket tool, and a question the knowledge base has no answer for. Without a give-up tool, the agent rewords its search and tries again, and again. Assume each turn re-sends a context that starts at 3,000 tokens and grows by about 2,000 tokens per turn as tool results pile up, with 500 output tokens per turn, priced at 3 dollars per million input and 15 per million output. These are illustrative, round assumptions, not a benchmark.

Let it run 40 turns before anything stops it and the input alone across the run is roughly 1.68 million tokens, about 5 dollars in input plus a little output, call it 5.30 dollars for one stuck ticket. That looks small until you multiply. If two percent of 5,000 daily tickets hit this, that is 100 runaway runs a day at 5.30 each, about 530 dollars a day, north of 15,000 dollars a month from a single control-flow bug. The monthly provider cap does not see this until deep into the damage.

Now add the caps. A step limit of 15 stops the same run at turn 15, cutting it to well under a dollar. A per-run token budget set to roughly a quarter of a dollar trips around turn 8, before the context has grown enough to hurt. And a give-up tool would have ended most of these runs at turn 2, with the agent escalating the unanswerable ticket to a human instead of spinning. The caps turn a five-dollar runaway into a few cents and a clean handoff. This is the same discipline as treating a silent failure as a failure: when a cap aborts a run, log it as a failed run and alert on it, because a rising rate of cap-aborts is your early signal that a tool or a prompt has started looping in production.

How to bound an agent before you ship

Before an agent goes live, set the two hard caps and the soft exit, and keep the provider cap where it belongs, as the last backstop. Run the real task on your hardest cases first, count the turns it actually needs, and set the step limit just above that rather than accepting the framework default of 15. Add a running token or dollar total that you check before every LLM call and that aborts the run when it crosses a per-run budget you chose on purpose. Give the agent an explicit tool to give up and escalate, so it is never stuck choosing between succeed and try again. Dedupe repeated tool calls so a circle short-circuits instead of spinning. Then log every cap-abort as a failed run so a spike tells you something broke.

Designing those limits is most of the work in shipping an agent that is safe to leave unattended, and it is a large part of what we build into agent and assistant systems: the model decides what to do, and the loop around it decides how long, how many times, and how much it may spend before a human steps in. If you have an agent that keeps running longer or costing more than it should, tell us what it is doing and we will help you find where the loop has no floor.