Runaway agent loop

Loops are the catastrophic tail of agent cost risk: spend is bounded not by the size of the task but by how long the loop runs unnoticed. Provider dashboards can lag by hours or days, and provider spend limits are alerts rather than hard stops — so the bill when someone finally looks is the detection delay times the burn rate.

An agent whose tool call fails retries it, and the retry fails identically — 47 invocations of the same tool in one production incident quoted in public reports. Left overnight, a loop like this burns whatever the detection lag allows; the pattern in public post-mortems is that nobody noticed for hours.

By call-rate anomaly detection per agent (a loop looks like a vertical line on a call-count chart) and, preventively, by a budget whose block action bounds the worst case: a loop inside a $50 envelope costs at most $50.

Why did my crew run up a huge bill overnight?

Almost always a retry or re-invocation loop with no terminating condition: a tool call fails, the agent retries it, the retry fails identically, and nothing outside the loop stops it. Spend is then bounded only by how long the loop runs unnoticed, and provider dashboards can lag by hours. The bill is the detection delay multiplied by the burn rate, which is why a ceiling matters more than an alert.

How do I stop a runaway agent loop?

Bound it in two places. Give the agent or run a budget whose action is block, so the pre-call check refuses the next call once the ceiling is hit — a loop inside a $50 envelope costs at most $50. Then add a call-count or iteration limit in the framework itself, so the loop terminates rather than merely stopping at the budget.

How do I use max_iterations to prevent runaway costs?

max_iterations caps how many reasoning steps an agent may take, which bounds the number of calls but not their cost — a small number of very large-context calls can still be expensive. Use it as the first line of defence and a spend ceiling as the second, because they fail differently: an iteration cap bounds the loop's length, a budget bounds its price. Neither alone is sufficient.

• Pre-call enforcement — Pre-call enforcement is a budget check that runs before an LLM request is sent to the provider, so an over-budget call is stopped before it costs anything rather than reported after it has.
• Multi-agent amplification — Multi-agent amplification is the compounding of LLM costs that occurs when agents invoke other agents, so one task multiplies into a tree of calls whose total is far larger than any node suggests.
• Per-agent budget — A per-agent budget is a spending envelope scoped to one named agent, rather than to the API key, project, or account the agent shares with everything else.