Runaway AI Agent Costs: How Retry Loops, Fan-Out and Recursive Tool Calls Burn Budget

A chatbot costs roughly the same every time someone sends it a message. An agent does not. It decides for itself how many model calls and tool calls a task needs, and that number has no natural ceiling.

Most of the time the number is sensible. When it isn't, nothing inside the agent will tell you. A run that should take eight steps can take four hundred, and the first sign is often the invoice.

OWASP lists this as LLM10:2025 Unbounded Consumption, and names one of its forms Denial of Wallet: initiating a high volume of operations to exploit the cost-per-use model of cloud AI services. OWASP describes it as something an attacker does. An agent can do it to you on its own.

How AI agent costs run away

There are three common mechanisms. What makes them dangerous is that each one looks reasonable from the inside.

Retry loops

A tool returns an error. The agent tries again, sometimes with the same arguments, sometimes with a rewording that fails the same way. Underneath it, the agent framework retries the model call on a timeout, and the HTTP client retries the tool call.

Each layer is sensible on its own. Together they multiply. Google's SRE book, in its chapter on addressing cascading failures, shows a single user action creating 64 attempts on a database because three layers each retried. Amazon's Builders' Library works through a five-layer example where independent retries at every layer raise the load on the database 243-fold. An agent adds one more layer, and that layer can reason its way into trying again.

Fan-out

Suppose a planner splits a task into ten subtasks. Each subagent runs its own loop of tool calls, and one of them runs a search, gets twenty results and opens every one. The cost is the product of those numbers, not the sum, and because the branches run in parallel, the whole tree can finish before anyone looks.

Recursive tool calls and hand-off cycles

Agent A delegates to agent B, which decides it needs A. A tool turns out to be another agent that calls back. A graph has an edge back to an earlier node and no condition that ever stops it. LangGraph's own documentation says that hitting its recursion limit is "often due to an infinite loop". In Cemri et al.'s taxonomy of multi-agent failures, step repetition and being unaware of termination conditions are two of the fourteen failure modes.

The multiplier underneath: a growing context

Each step usually re-sends the conversation so far. Suppose every step adds 2,000 tokens. Step 50 then sends about 100,000 input tokens on its own, and the run as a whole sends about 2.55 million, against 100,000 if each step sent only its own share. In a loop, cost grows faster than the step count. Caching can lower the price of the repeated part. It does not stop the loop.

How to detect a runaway AI agent

The model in a loop is the last component that will notice it is in one. Detection has to sit in the orchestrator or the gateway, where every step is visible. The useful signals are mechanical:

None of these needs a model to evaluate. Hash the tool name and arguments, count, and compare against a baseline.

Six controls that cap AI agent spend

1. A spend ceiling per agent, per run and per day. Enforce it where the API key lives, in the gateway or proxy, not in the prompt. That requires each agent to have an identity of its own; a shared key gives you one budget for everything. OWASP's mitigations for LLM10 include rate limiting and resource allocation management, which is the same idea.

2. Step and depth limits. Use the one your framework ships with. The OpenAI Agents SDK's max_turns caps the number of agent-loop turns and raises MaxTurnsExceeded when a run passes it; LangGraph has recursion_limit. Then add the limits a framework may not: delegation depth, number of subagents, concurrent tool calls. OWASP's list includes limiting queued actions.

3. A retry budget. Retry at one layer, not every layer. Cap retries per request, and per process too: the SRE book's example is 60 retries a minute. Classify errors before retrying them. A permission denial or a validation error will fail the same way on the fifth attempt.

4. Loop detection that stops the run. Turn the signals in the table into rules with thresholds you have chosen in advance: for example, three identical calls in a row, or ten steps with no change of state, ends the run. A warning in a log is not a control.

5. A deadline per run. Set a wall-clock limit when the run starts and pass it down to every call, so a subagent cannot outlive the task that spawned it. The SRE book recommends setting a deadline high in the stack and propagating it; OWASP lists timeouts and throttling.

6. Alerts on spend rate, not just totals. A monthly budget alert arrives after the money has gone. Alert when one agent's spend per minute, or tokens per run, moves well above its own baseline.

What should happen when a cost limit trips

Stopping is a result, not a crash. Record it as one, for example: stopped at step 37, budget exceeded, last tool called, actions already taken. A stopped run must never be recorded as a success.

Then decide, in advance, what happens to the work in flight. A run that only read and drafted can be discarded. A run that had already sent half a batch of payments needs a person. That is the same per-action decision as choosing fail-open or fail-closed for a guardrail, and it belongs to whoever owns the risk.

Two rules hold throughout. The agent never raises its own limit. And the stop path lives outside the agent it stops, because a component stuck in a loop cannot be relied on to break it.

Where Syntrox fits

Spend ceilings, step limits and retry budgets belong in your orchestrator and gateway, where the agent cannot argue with them. Syntrox sits outside the agent and evaluates what it produced, recording per evaluated trace the score, confidence and judge version. Read alongside your cost telemetry, that tells you not only which runs were expensive, but whether the expensive ones were any good.