The scariest line item on an AI coding agent's bill is not the work it finished. It is the work it never finished. An agent that gets stuck, on a wrong assumption, a flaky test, or a task it simply cannot complete, does not know to quit. It keeps trying, and every retry is another paid round trip to the model. Left uncapped, a single confused task can cost more than a hundred clean ones.
That is why LLM cost controls and a real budget are not a finance afterthought bolted on at the end. They are part of what makes an agent safe to run at all. This is a guide to the controls that actually bound the bill, and to the one caveat most people miss about what a cap can and cannot promise.
Where the money actually goes
Agent spend is not spread evenly across tasks. It concentrates in the tail: a small number of tasks that spiral while the rest finish cheaply. The usual causes are familiar. An ambiguous spec sends the agent in circles. An environment problem it cannot fix (a missing dependency, a broken test harness) makes every attempt fail the same way. A test that never passes turns into an infinite fix-and-retry loop.
The most expensive pattern is the loop itself. Each turn of an agent typically re-sends the growing conversation history, so later turns cost far more than early ones. A long session does not cost ten times a single call, it can cost many times that, because the context keeps expanding with every step. The median task is cheap. The runaway task is where budgets die. So your controls should be designed to catch the tail, not to shave a few percent off the average.
Cap the iterations, not just the tokens
The single most effective control is an iteration cap. Decide the maximum number of attempts an agent gets at a task, across plan, implement, test, and fix, and stop when it reaches the ceiling. Token limits help, but iterations are the lever that actually stops the grinding, because grinding is measured in attempts, not tokens per attempt.
An agent allowed unlimited retries will use them. An agent allowed three will either succeed within three or surface that it is stuck. Both outcomes are useful. What you never want is the third state: an agent quietly burning attempt forty on a task that was never going to resolve. Set the ceiling based on the kind of work. A small, well-scoped change should need very few attempts; if it is on its fifth, something is wrong and more attempts will not fix it.
Give every task a budget before it starts
Alongside iterations, give each unit of work a spend budget and a maximum number of review rounds, declared before the work begins. When the task reaches its limit, it stops. Tie the budget to the task's value: a trivial change gets a small allowance, a gnarly migration a larger one. Treat it as a risk decision, the same way you would scope any expensive operation.
The important property is that the limit is set up front, not discovered on the invoice. No single task can consume an unbounded amount, because you decided the maximum before pressing go. That turns cost from something you react to after the fact into something you shape in advance.
Escalate at the cap, do not silently fail
Hitting a cap should route the task to a human, not drop the work on the floor. A stuck task is a signal worth reading: the spec was unclear, the codebase resisted, the chosen approach was wrong. A person can look, decide, and either raise the budget deliberately or fix the underlying cause so the next run is cheap.
This is the difference between a budget that protects you and one that just wastes work. Escalation converts a hard cost limit into a feedback loop. Over time, the tasks that keep hitting their caps tell you where your specs, your tests, or your estimates need work, which is worth more than the money the cap saved.
Make spend visible while it is happening
You cannot control what you cannot see. Track spend per task, per project, and per period, and surface it live rather than at month end. An alert on unusual spend catches a runaway while it is still cheap to stop, which is the whole game with tail costs.
Visibility also makes your other controls smarter. When you can attribute cost by task type, by stage, and by model, you learn where to tighten caps and where your model routing is sending work to the wrong tier. Caps are the emergency brake. The steady-state savings come from keeping the baseline low with prompt caching and batching, so that even the tasks that run long are running cheap per step. Caps and efficiency are complementary: one bounds the worst case, the other lowers the whole curve. Both belong in any serious read of the economics of AI coding agents.
The honest limitation
Here is the caveat that most cost-control write-ups skip. A cap inside your orchestrator bounds what your system decides to dispatch. It does not directly bound the model provider's bill, because inference runs on the model account, and the authoritative number lives on that provider's invoice, not in your internal estimate. Your caps are a dispatch guardrail: they stop your orchestrator from spending past a limit and escalate instead. Treat your internal cost figures as estimates for forecasting and alerting, and reconcile them against the provider's actual bill (and verify current rates, which move). Anyone who tells you a software cap is a hard spend limit on someone else's metered account is overselling it.
Caps also carry a cost of their own. Set them too tight and they block work that would have succeeded on one more attempt, and a human spends time unblocking tasks that did not need it. The right limit is a judgment calibrated on real data, not a number you set once and forget. Start conservative, watch what actually hits the ceiling, and adjust.
The stance worth taking
Uncapped agents are a bill waiting to happen. The fix is unglamorous and reliable: cap the iterations, budget each task before it runs, escalate to a human at the ceiling instead of grinding, and watch spend as it happens rather than after.
This is the posture we hold in Loopsfinity. Every unit of work carries a budget and an iteration ceiling, a task that hits the limit stops and asks a person rather than spending on, and cost is visible per task so the limits get tuned against reality instead of guesswork. The details of how we meter and enforce that are ours. The principle is yours to use on any agent you run: decide the limit before the work starts, because after it starts, the only thing standing between a stuck task and a large invoice is the cap you set.