Blog · ← All posts
The Runaway Tool-Call Loop: How a $4,000 API Bill Happens
By the Ingenious AI team · Last updated: October 13, 2026 · 7 min read
Illustrative scenario: the incidents in this post are a composite of real failure patterns, with names, numbers, and details changed. No real company, customer, or agent is depicted.
The bill arrived on a Tuesday. $4,132.77 for one night of API usage from a single agent, a lead-research bot a 12-person marketing agency had built to find prospect companies and draft outreach. Their normal daily spend was around $40. The agent had done the work of a hundred nights in 41 minutes. Nobody had watched it happen, because it happened at 3:19 AM.
Runaway tool-call loops are the most common expensive failure in agent production. Not the scariest (an agent issuing refunds it shouldn't is scarier), but the most common. And the mechanics are almost embarrassingly simple once you see them.
How the loop works
The agent's job: "Find 50 qualified SaaS companies in the logistics space and draft a personalized opener for each." It had a search tool, a company-enrichment tool, and a draft generator. On a normal run it made 60 to 90 tool calls over 15 minutes, then stopped at 50 prospects.
That night, the search tool returned its 50th prospect at call #61, and the enrichment tool flagged it as a duplicate of #12. The agent discarded it, searched again, got another duplicate, discarded that one, and kept going. Each iteration burned roughly 2,300 tokens: read the search results, compare against the existing list, decide, retry.
It never found prospect #50. It kept finding near-duplicates and rejecting them. 214 tool calls later, 41 minutes of wall-clock time, the loop broke only because the enrichment API started rate-limiting and the agent's error handler gave up. The invoice: 214 iterations × ~2,300 tokens × blended model pricing, plus the enrichment API calls. $4,132.77.
The moment someone noticed? 7:55 AM, when the agency's founder opened the usage dashboard to check something unrelated and saw the overnight spike. The agent had finished at 4:00 AM. It sat there for four hours, bill already burned, before a human looked.
Why loops are so hard to see coming
Loops don't look broken from the inside. Every individual step is reasonable: search, compare, reject, search again. There's no error, no exception, no crash. The agent is working exactly as designed. It's just that "exactly as designed" includes no definition of done and no definition of enough.
Three ingredients show up in nearly every runaway loop we've seen:
- A success criterion the agent can't verify. "Find 50 qualified prospects" sounds precise. But the agent couldn't reliably tell a duplicate from a near-duplicate, so it could never confirm it had 50. Vague goals ("find the best," "keep looking until it's perfect") are worse.
- A tool that always returns something. Search tools rarely say "there's nothing more." They return the 11th-best result, the 40th, the 200th. An agent that keeps asking gets kept answers. The loop only ends if the agent decides to stop — and agents are bad at deciding to stop.
- No one watching the counters. Iterations, tokens, and dollars are the cheapest signals in the whole system. In this incident, per-step token counts were being logged, but nobody had an alert on them. The data existed. The attention didn't.
The three guards that actually stop this
After that Tuesday, the agency rebuilt their agent with three guardrails. Total implementation time: an afternoon. None of them is clever.
1. A hard iteration cap. The agent gets 120 tool calls per run, full stop. Hit the cap and it must return what it has, with a note on what it couldn't finish. This is the seatbelt. It doesn't prevent the loop. It bounds the damage. Their worst-case bill is now calculable before the run starts: 120 calls × worst-case tokens × price per token. About $90. They can live with $90.
2. A per-run budget in dollars, enforced by the harness. Not by the agent: the agent can't be trusted with its own budget, for the same reason you don't ask a toddler to monitor their own candy intake. The harness tracks cumulative spend and kills the run at $50. The agent gets a message explaining why it was stopped, which goes into the ledger.
3. An anomaly alert on action bursts. Their recorder flags any agent whose action rate exceeds three standard deviations above its own baseline. A research agent making 214 calls in 41 minutes is roughly 8 sigma off its normal pace. The alert fires at 3 sigma — about 90 calls in, which would have paged the on-call engineer around 3:40 AM, roughly $2,800 before the actual total. Not zero damage, but not $4,132 either.
Would any of these have prevented the loop? No — and that's worth saying plainly. The loop is a reasoning failure, and no guardrail fixes reasoning. What the guards do is convert an unbounded failure into a bounded one. The difference between a $90 incident and a $4,132 incident is three afternoon's worth of guardrails.
Do the math on your own agent
The arithmetic is what makes this sting, so run it for your own setup. Take the composite loop above: roughly 2,300 tokens per iteration. At illustrative flagship-model pricing — say, $3 per million input tokens and $15 per million output — one iteration costs a couple of cents. A couple of cents sounds like nothing. Two hundred fourteen iterations of nothing is $4,132.77. (Provider rates shift constantly; run your provider's current pricing through the same multiplication.)
Then multiply by the thing teams forget: the tool calls themselves cost money. The enrichment API in this story charged per lookup. Every loop iteration burned tokens and paid a third-party fee. Double-exposure loops — where the model and the tool both meter you — are where five-figure bills come from. And loops aren't only an overnight problem: a daytime agent looping through a rate-limited API can burn a day's budget before lunch, and nobody panics about a dashboard at noon the way they panic about one at 3 AM. Quieter, slower leaks are easier to miss.
The cheapest math you can do today: one multiplication on a sticky note. (Worst-case calls per run) × (worst-case tokens per call) × (your price per token) × (tool fees). That number is your maximum exposure. If it scares you, the guardrails above take an afternoon.
What a good alert actually looks like
The agency's anomaly alert fired on action rate, but here's the specific rule they shipped — because "watch for weirdness" is not a rule. Any agent whose tool-call rate over a rolling 10-minute window exceeds its trailing-7-day median by 3× pages the on-call. A concrete threshold a runbook can encode, not a vibe. Median, not mean, because one bad night shouldn't move the baseline. Ten minutes, because that's long enough to catch a loop before the third digit of the bill changes. They tested it against a month of normal runs first and tuned the false-positive rate to roughly one page per two weeks — the level where engineers keep the pager on instead of muting it.
And when the alert fires, the responder's first move is always the same: open the ledger, filter to the last ten minutes, read the reasoning column. The alert tells you something is wrong. The ledger tells you what the agent thinks it's doing. That combination is what turns a 4 AM panic into a ten-minute kill-and-review.
The number that matters most
Here's the part teams get wrong: they instrument everything except cost. Tokens per step, actions per minute, cumulative spend per run: these are the cheapest telemetry you have, and they're the first thing anyone looks at when the bill lands. Log them from day one. Set the alerts before the first production run, not after the first surprise invoice.
One more observation, because it tells you how normal this is: among teams running agents in production, runaway-loop war stories are extremely common — the bills range from a few hundred dollars to five figures. The $4,000 incident above is a composite, but the failure pattern behind it is one of the most frequently reported expensive agent failures in the industry. The outlier isn't the team that got the big bill. It's the team that never logged the counters and found out from their card statement.
Start logging your agents free → Action-burst anomaly alerts and per-step token tracking are built into the ledger from the first run: the signals that would have paged someone at 3:40 AM instead of 7:55.