The $6,531 CloudFormation loop: why an error is never free
By The Lucidrail Team · 2026-07-07
In a public write-up, an operator described an AI agent that was supposed to manage cloud infrastructure. The agent hit an error. So it tried again. And each time it retried, it spun up another duplicate AWS CloudFormation stack — a fresh copy of billed cloud resources — stacked on top of the last.
Nobody was watching the meter. By the time the operator stepped in, AWS had charged $6,531. The note they left was short:
i have stopped the agent, the cost too high and much charges on card. — The operator, in a public postmortem of the incident
The number is smaller than some runaway-agent stories, and that is the point. This bill was not one dramatic loop. It was an ordinary error, repeated — each retry quietly leaving a real, billed resource behind.
An error is not a free action
It is tempting to assume that when an agent fails a step, nothing happens. The step just didn't work, so it costs nothing, and the agent moves on. That assumption is exactly where the money leaks out.
Every retry is a real call. Every duplicate stack is real infrastructure that keeps billing until someone deletes it. When an agent is wired to try again on failure, an error is not the end of a cost — it is the start of one that compounds. A loop that never once succeeds can still run up a large bill, because the cost is in the attempts, not the result.
The agent cannot be trusted to stop itself
The obvious fix is a limit inside the agent: a maximum number of iterations, or a token ceiling for the run. Operators reach for these first, and they are worth having. The problem is that the same broken loop that runs up the bill is often the very thing meant to enforce the limit.
Users of one popular agent framework have hit this directly. One described the failure plainly:
This infinite loop can cause an insane high token usage. — Raja_Speet, on the CrewAI community forum, asking for a way to cap total token usage
They asked for a setting to cap the crew's total token use and “save a lot of unnecessary costs.” Others reported the framework's own max-iteration cap failing to stop the loop at all. A limit that lives inside the runaway is only ever as reliable as the runaway.
The stop has to live outside the agent
For a cap to be trustworthy, it has to sit somewhere the agent cannot reason its way past or crash through — outside the loop, close to where the money is actually spent. That is the layer most people don't have. One operator went looking for it after a much smaller surprise bill:
I searched for a tool that could just stop the agent when it hit a dollar limit. Nothing existed. — sahiljagtapyc, after an unexpected bill from an agent left running (Hacker News)
That is the gap. Not a smarter agent — a hard stop, at the infrastructure level, that trips before the card is charged rather than after the statement arrives.
The big blowup and the small leak are the same shape
You do not need a $6,531 stack loop to feel this. Another engineer pointed out that the failure people actually hit day to day is smaller and quieter:
retries a failed payment 5 times… The damage is $20 of wasted API credits, not $10k — but the lesson is the same. Budget guardrails matter. — novachen, on the everyday cost of agent retries (Hacker News)
Whether the number is $20 or $6,531, the mechanism is identical: an action that fails, a retry that costs, and no outside limit to catch it. The size of the bill only decides how loud the lesson is.
This is one reason we built Lucidrail as a control plane that sits outside your agents. Per-company budgets with live metering and hard caps mean a retry loop trips a limit before it bills, not after — and every action traces back to the goal that set it off, so a duplicate-stack spiral is visible while it is happening, not a surprise on next month's invoice.