Stop AI agents burning your budget in a runaway loop

A chat completion costs you a few thousand tokens. An agent working the same task can cost fifty times more, because it plans, calls tools, reads the results, and calls the model again. When one of those loops fails to make progress, it does not stop on its own. It keeps calling the API until something outside the loop kills it, or the invoice arrives.

This is the failure mode that surprises teams shipping their first autonomous agent. The demo ran on a linear prompt and cost cents. Production runs a tool-call loop, and a single stuck task can burn six figures of tokens before anyone notices. Below is where the cost comes from and the specific runtime controls that cap it.

How one task goes from 2,000 to 120,000 tokens

A single-shot LLM call has a fixed cost: your prompt in, one completion out. An agent is a loop. Each turn appends the previous tool output back into the context, so the input grows on every iteration. Reported production benchmarks put the spread between a linear call and a planning-heavy agent at roughly 70x, with individual tasks climbing from about 2,000 tokens to 120,000 on a bad run.

Three things drive that growth:

• Context accumulation. Every tool result, every intermediate reasoning step, and every retry gets carried forward, so later turns re-send everything the earlier turns produced.
• Retries and self-correction. When a tool errors or the model rejects its own output, the agent tries again, often with a longer prompt than before.
• No-progress loops. The agent repeats the same tool call, gets the same unhelpful result, and repeats again, with nothing detecting that it has stopped advancing.

If you are also running a reasoning model or a high reasoning-effort setting inside that loop, each turn is more expensive again. We covered that tradeoff in reasoning effort and its effect on LLM cost and latency. Stacked together, these multipliers explain how per-task cost can 10x before the monthly bill reflects it.

Budget alerts are not budget enforcement

The most common mistake is treating monitoring as protection. A dashboard that emails you when spend crosses a threshold tells you what already happened. By the time the alert fires, the API calls have executed and the money is spent. In one widely reported incident, a set of agents entered an infinite loop, ran for eleven days, and rang up roughly $47,000 before anyone shut it down. The root cause was not a missing alert. It was a missing cap.

Enforcement is different from alerting. Enforcement is a runtime control that terminates or pauses the agent the moment it crosses a token or cost threshold, before the next model call is placed. Alerting is a notification after the fact. You need both, but only enforcement bounds the worst case.

This distinction matters because most off-the-shelf agent frameworks ship the weaker version. LangChain, for example, provides middleware that caps the number of model calls and tool calls, but as of the v1 middleware suite nothing in the built-in limiters bounds total token consumption. A call-count cap helps, yet a handful of calls with a runaway context can still be expensive. You have to add the token budget yourself.

The controls that actually cap agent spend

A hard token or cost budget per session

Give every agent run a fixed budget, measured in tokens or dollars, and check cumulative usage before each model call. If the next call would exceed the budget, stop and return what you have. This is the single control that turns an unbounded worst case into a bounded one. It is the same principle we apply at the tenant level in per-tenant LLM cost caps for multi-tenant SaaS, pushed down to the individual task.

Loop and no-progress detection

Track the last several tool calls and their results. If the agent issues the same call with the same arguments twice, or produces no new information across a window of turns, break the loop. Infinite agentic loops almost always show this signature first: repetition without progress. Catching it early saves the bulk of the wasted spend.

Iteration, depth, and time limits

Cap the maximum number of turns, the recursion depth for sub-agents, and the wall-clock time per run. These are cheap to add and they backstop the token budget. A maximum-turns limit alone would have ended the eleven-day loop on day one.

Per-span cost tracking

Attach token and cost data to every span in the trace: each model call, each retrieval step, each tool invocation. When a run blows its budget, span-level data shows you which step is the culprit, because the expensive call is often buried deep in the trace. This is the same instrumentation we describe in attributing LLM cost per feature, applied inside a single agent run rather than across your product.

A concrete budget envelope for a production agent

Here is a starting point we use for a customer-facing agent that calls two or three tools per task. Set a per-run hard cap of 40,000 tokens. Set maximum turns to 12 and recursion depth to 3. Add no-progress detection over a window of 3 turns. Log token counts per span and alert on any run that reaches 75 percent of its budget, so you see near-misses before they become breaches.

Those numbers are not universal. A research agent that reads long documents needs a higher token cap and a longer timeout. A classification agent that calls one tool needs far less. The point is that every run has an explicit envelope, checked before each call, rather than an open-ended license to spend. Pair the envelope with model routing to send cheaper turns to smaller models and you cut both the ceiling and the average.

If you want tighter control over the output side of each turn, controlling output token cost covers the max-tokens and stop-sequence settings that keep individual completions from ballooning.

Frequently asked questions

Why do AI agents cost so much more than a normal chat call?

Because an agent is a loop, not a single call. It re-sends the growing context on every turn, retries on errors, and can repeat steps. Reported benchmarks show agents using roughly 50x the tokens of a comparable chat interaction, and up to 70x for planning-heavy tasks.

Will a maximum tool-call limit stop runaway spend?

Partly. A call-count cap prevents an infinite number of calls, but it does not bound the tokens per call. A few calls carrying a huge accumulated context can still be expensive. Add a token or cost budget on top of the call-count limit.

What is the difference between a budget alert and budget enforcement?

An alert notifies you after spend has occurred. Enforcement terminates or pauses the agent before the next model call when a threshold is reached. Only enforcement bounds your worst-case cost, so treat alerts as a supplement, not the safeguard.

How do I find which step in an agent run caused a cost spike?

Instrument every span with its own token and cost data: model calls, retrieval, and each tool invocation. When a run exceeds its budget, the span-level breakdown points to the exact step, which is usually a repeated tool call or a retry loop deep in the trace.