What a runaway agent actually costs
Public incident reports from developers who left an agent running. The pattern is not the size of the bill — it is how long it takes anyone to notice.
Runaway agent stories get told as horror stories, which makes them easy to dismiss as someone else's carelessness. Read enough of them and a duller, more useful pattern appears: the bill is rarely the interesting part. The interval before anyone noticed is.
Twenty minutes
One developer's account, posted to Hacker News:
A few weeks ago I left an AI agent running, walked away for 20 minutes, and came back to a bill I didn't expect.
They went looking for a tool that would stop an agent at a dollar limit, found none, and built one. Twenty minutes is not negligence. It is a coffee.
Overnight, 47 times
A dev.to author described the mechanism plainly:
One of my agents decided to call the same tool 47 times in a loop. In production.
Their OpenAI bill went from $80 to $400 overnight. A 5× increase is small in absolute terms and enormous as a signal — and nothing in the stack raised it until the invoice did.
The dashboard is not the alarm
The same OpenAI forum thread that developers keep rediscovering describes the mechanism generically:
An agent gets stuck in a loop and burns through API credits before anyone notices.
The poster had already tried account-level caps, logging, and try/except wrapping. None of it prevented the charge. Their question at the end is the honest state of the art for most teams: "is everyone just setting account caps and hoping?"
Why aggregate spend hides it
A runaway job is a spike in one agent against a background of normal traffic. Watching a single org-wide number is the one view guaranteed not to show it — by the time a 5× jump in one agent moves the total enough to be obvious, it has been running for hours.
A developer who instrumented their own middleware put the fix in one line:
this agent + this task = this cost was a big relief
That is attribution, and it is the prerequisite for detection. You cannot flag an anomalous agent until spend has an owner.
The part that generalises
From the forecasting thread on Hacker News, the sharpest framing of the whole problem:
The unpredictability is worse than the absolute cost. Our billing model broke several times not because costs were high, but because we couldn't bound them.
Teams can plan for an expensive month. They cannot plan for a month whose ceiling is the card on file.
What actually shortens the interval
Three things, in the order they pay off:
- Attribution first. Every call tagged with an agent, team, and customer. Nothing else on this list works without it.
- Anomaly detection on the per-agent series, not the org total, so a 5× move on one agent surfaces the same day rather than at invoice time.
- A hard ceiling that rejects the call, so the worst case is bounded even when nobody is watching — which, at 3am, is the normal case.
Capsera does all three from one init() call. The detection matters most for
the incidents above: every one of them was discovered by a human, late.
Give every agent an identity, a budget, and hard limits.
One line of code. Anthropic, OpenAI, and Google Gemini.
See pricing