The cap that didn't hold: why a built-in limit misses a runaway
By The Lucidrail Team · 2026-07-03
In late 2025 an operator posted a simple problem to the CrewAI community forum. Their agents had fallen into an infinite loop, and the token count was climbing. They wanted a way to put a ceiling on the spend before it got out of hand.
This infinite loop can cause an insane high token usage. — Raja_Speet, CrewAI community forum, asking how to cap a runaway crew
They asked for a setting to limit the total token usage of the crew and, in their own words, save a lot of unnecessary costs. It is a reasonable ask. The frustrating part is what came next.
The framework did offer a limit. CrewAI has a max_iter setting meant to stop an agent from running past a set number of steps. A separate report on the project's issue tracker describes that cap failing to hold — the loop kept going anyway. The built-in stop did not stop it.
The cap and the runaway share a runtime
This is the quiet problem with a limit that lives inside your agent framework. The runaway is happening inside the very thing you are asking to stop it.
A max_iter counter or a token budget check is just lines of code the same process runs between steps. It fires only if the loop hands control back to it. If a step never returns cleanly, or the loop takes a path the counter does not see, the check never runs. You end up trusting the thing that is misbehaving to cooperate with its own shutdown.
Frameworks add these settings as a convenience, not a guarantee. They help with the ordinary case. They are not built to survive the exact failure — a wedged, looping process — that you most need a cap for.
A bill is not a cap
Notice what the forum poster actually wanted: to save unnecessary costs. That framing is the tell. By the time most people find the problem, they are reading a number after the fact, not preventing it.
The same shape shows up across very different setups. An engineer publicly described two agents stuck talking to each other for eleven days, running up a $47,000 bill before anyone pulled the plug. Another operator watched an agent spin up duplicate CloudFormation stacks on every error until the cloud bill reached $6,531.
i have stopped the agent, the cost too high and much charges on card. — an operator describing a runaway agent's AWS bill
Different frameworks, different clouds, same ending. The stop arrived after the money was already gone.
Where a cap has to sit to hold
A limit that holds has to sit outside the agent's own process — at the layer that meters and bills the work, not the layer doing it. It counts every call as the call happens, and it can cut the agent off even when the agent's own logic never checks back in.
It is the same reason a circuit breaker lives in the electrical panel, not inside the appliance. You do not ask the thing that might fail to also be the thing that saves you from it. The cap belongs one level down, where a runaway cannot reach in and disable it.
In practice that means a budget you can watch move in real time and a hard limit that trips on its own — no human paged, no cooperation required from the loop you are trying to stop.
This is one reason we put hard budget caps at the infrastructure layer of Lucidrail, not the application layer. Every company gets a live-metered budget and a hard cap that stops a runaway before it bills — enforced at the dispatch seam the agents run through, rather than inside any one agent's loop. A cap only helps if it can hold when the thing it is limiting stops behaving.