An unbudgeted agent loop can burn fifty thousand dollars in thirty days. Not because AI is expensive, but because the failure mode is a design pattern rather than a bug. This article walks through the pattern, why the native cloud controls miss it, and the three concrete controls that stop it before the credit card statement lands. The answer, front-loaded so you can decide whether to keep reading, is a per-agent budget enforced at the model gateway, a per-cycle limit on tool calls and tokens inside each agent invocation, and independent cost telemetry that does not rely on the provider dashboard. Any one of the three helps. All three together turn the fifty thousand dollar surprise into a hundred dollar alert on a Tuesday afternoon.
The pattern that produces the fifty thousand dollar month is common enough that treating it as a single-team accident misses the point. Publicly discussed industry incidents describe the same shape repeatedly. An agent given the ability to invoke tools, review its own output, and re-enter the reasoning loop can spend all night on a bug that would have taken a human ten minutes to catch. The team wakes up in the morning to a bill notification, not a system alert, because the billing pipeline reports faster than the internal observability pipeline. The teams that build the discipline to catch this pattern before it happens are the teams that treat it as a workload class problem rather than a specific incident to postmortem.
The pattern that costs fifty thousand dollars in thirty days
The failure mode has three moving parts. The first part is that the agent can invoke itself, directly or through a tool chain, without a hard budget on total invocations. The second part is that the observability signal that would tell an operator the agent is looping runs slower than the loop itself. The third part is that the credentials the agent runs under do not have a spending ceiling that would stop the loop when it drifts.
Take a specific case. A team ships an agent that summarizes tickets and posts the summary back to the ticket. Simple use case. The agent is wired to check its own output for accuracy and rewrite the summary if the check fails. On day one of production, everything works. On day fourteen, a new type of ticket comes in that the accuracy check flags as ambiguous. The agent rewrites. The check flags the rewrite. The agent rewrites again. The check flags again. There is no exit condition on the check, only a target confidence score the agent cannot reach for this particular ticket class, so the loop runs for two hours before the rate limit at the model provider slows it down enough to notice.
Two hours of a single loop at the observed rate of a few dollars per minute is a few hundred dollars. That is the small case. The large case is what happens when the pattern goes undetected across many sessions in parallel, day after day. A hundred users. Each triggering an average of three tickets per day. Three percent of tickets fall in the class that triggers the accuracy loop. Each looping session runs an average of forty minutes before a session timeout or a rate limit intervenes. The daily cost of the loop pattern across the deployment lands somewhere between one and two thousand dollars per day. Multiply by thirty days. The bill lands at fifty thousand dollars, plus or minus the exact assumptions.
The reason the pattern is expensive rather than the model call is expensive is that the loop pays for both sides of every cycle. The request grows because the previous cycle's output is now part of the next cycle's input. The response is charged at the growing context, not the base rate. The compounding is silent from the outside because each individual call still returns a valid response in a reasonable time. Nothing errors. Nothing crashes. The loop just keeps spending.
Why the native cloud controls miss it
The reflexive engineering response, once the pattern is described, is to point at cloud budgets or provider dashboards and say we already have controls for this. The response is understandable and wrong. The native cloud controls are calibrated for a workload class that does not match the agent workload class.
The billing lag is the first mismatch. Every major cloud provider updates their billing dashboard on a delay. The delay is measured in hours for the fastest providers and can exceed twenty four hours for the slower services. A loop that starts at nine in the morning and burns two thousand dollars by three in the afternoon shows up on the dashboard the next day at the earliest. By then, six more hours of the loop have run, or a similar loop in a different session has repeated the pattern. The dashboard is a lagging indicator of a leading problem.
The granularity mismatch is the second problem. A cloud budget alert triggers when total spend on the account or the project exceeds a configured threshold. It does not know which agent identity is responsible. It cannot distinguish the runaway loop from a legitimate spike. It cannot enforce a stop without also stopping every other workload sharing the account. The engineering conversation after the first serious incident is usually the same conversation. We had a budget. The budget alerted. By the time it alerted, the money was gone. We can lower the threshold. Lowering the threshold produces more false positives on legitimate spikes and does not actually stop the loop from spending up to the new threshold before the alert fires.
The incentive mismatch is the third problem, and the most awkward to say out loud. The model provider makes revenue on the loop. The billing team at the provider is not incentivized to build the tool that stops the loop early. The tools they do build tend to focus on visibility after the fact rather than enforcement before the burn. This is not a claim of bad faith. It is a claim about where in the stack the enforcement layer sits. The provider is the wrong place. The enforcement has to sit inside the customer boundary.
The three controls that stop the loop
Three controls, in the order you should implement them.
The first control is a per-agent budget enforced at the model gateway. The gateway is any proxy or middleware layer that sits between the agent code and the model provider. Every request routes through the gateway. The gateway checks an agent identity carried in the request headers or the auth context. The gateway keeps a rolling counter of tokens billed per identity for the current UTC day. When the counter passes the configured daily cap for that identity, the gateway rejects the request with a hard error. The agent code catches the error, logs it, and fails closed. The mechanism is a hundred lines of middleware code. The effect is that the worst case burn per identity is bounded by the daily cap, not by whatever budget alert eventually fires at the cloud level. If the cap is a hundred dollars per agent per day, the worst case is a hundred dollars per identity per day. Fifty thousand dollars in thirty days becomes three thousand dollars in thirty days across the same fleet, at a floor that is not the target but the ceiling.
The second control is a per-cycle limit inside each agent invocation. The limit is enforced by the agent runtime rather than by the gateway. A configured maximum number of tool calls per invocation. A configured maximum number of tokens the agent can spend inside a single user request. When the invocation hits the limit, the runtime returns whatever the agent has produced so far and stops. This control catches the class of loops that the gateway control does not catch, which is the loops that stay within the daily budget in aggregate but destroy the responsiveness of a single session. It also catches the specific failure mode of recursive self-review, where the agent keeps rewriting its own output. The per-cycle limit is the exit condition the accuracy check did not have.
The third control is independent cost telemetry that does not rely on the provider dashboard. Every request that goes through the gateway is logged with the agent identity, the token counts, the model, and the timestamp. The logs are written to a cost store that the engineering team controls. The store is queryable in near real time, ideally within minutes rather than hours. The queries the team should be running are cost per session, cost per agent identity per hour, and the p95 of cost per session over a rolling window. These queries are the leading indicators the billing dashboard cannot provide because the billing dashboard runs on the batched pipeline. The independent store runs on the streaming path. This control is what catches the drift before the loop fires. The first two controls stop the loop once it fires. This one prevents it from firing in the first place.
The three controls are cumulative. The first control is the hard floor. The second control is the runtime exit. The third control is the leading indicator. Any of the three helps. All three together move the worst case from a headline incident to a Tuesday afternoon alert.
The thirty minute audit
If you are reading this and you run agents in production, the audit that surfaces whether you have this exposure takes about thirty minutes.
The first fifteen minutes are questions. Do your agents run under distinct identities that the model gateway can distinguish? If yes, does the gateway enforce a per-identity daily cap? If yes, what is the cap for each identity, and would you be comfortable if any single identity burned that cap every day for a month? If no, the exposure is unbounded until you add the identity layer.
The second ten minutes are queries. Pull the model provider bill for the last thirty days. Group the spend by day. Look for days where a single day accounts for a disproportionate share of the month. Look for patterns of consecutive days where the day-over-day spend grew without a corresponding growth in active users. Any pattern that does not match a business-side reason is a candidate loop.
The last five minutes are a rehearsal. Pick one agent identity. Pick a plausible failure mode for that agent. Trace on paper what would happen if that failure mode fired at three in the morning on a Saturday. How would you know? How would you stop it? How much would it cost between the failure and the stop? If any answer starts with we would find out when the bill arrives, you have found your gap.
The audit is not a solution. It is a diagnostic. The three controls above are the solutions. What the audit does is convert the abstract worry about agent loops into a concrete inventory of where you are exposed and where you are covered.
Where this fits Brain Agents AI
Brain Agents AI is building multi-cloud AI cost intelligence for teams running production workloads across GCP and AWS. Join the beta waitlist for early access.