A spend cap will not stop a runaway agent. Bound the loop.

Here is a bill that does not make sense until you look at what the agent did. You put an agent on your support queue. Most days it costs a few dollars. Then one Tuesday it costs two hundred, on the same queue, doing the same job. Nothing changed in the workflow. The model did not get more expensive. The agent just had a bad day, and on a bad day it does not fail cleanly. It keeps going.

This is the part of the cost story nobody is fixing. The Financial Times reported on June 19 that Uber now limits employees to $1,500 a month in token spend, and that Amazon, Walmart, Cisco, and Meta are all capping internal AI budgets. Microsoft canceled most of its internal Claude Code licenses over bills that stopped making sense at scale. The reaction everywhere is the same: put a cap on everyone and move on. A cap is worth having. It is also the wrong tool for this job, because it treats a runaway agent like a spending habit. The cause is almost never a person spending too freely. It is a loop with no hard stop.

An agent does not spend like a chatbot

A chat is one question and one answer. The token cost is known before you send it, and it cannot surprise you. An agent is a loop. It reads the task, calls a tool, reads the result, decides what to do next, and repeats until something tells it to stop. Every pass spends tokens, and every pass also re-reads the growing pile of context it has built up along the way. Reporting this month put a single agent run at roughly fifty times the tokens of one chat message. That multiplier is the whole story. A chat cannot run forty times when you expected four. A loop can.

Three bugs drive almost all of the surprise

Trace a runaway bill back and you usually land on one of three things.

No step ceiling. The loop has no hard cap on how many times it can run. On a clean task it stops on its own after a few passes. On a confusing one it never decides it is done, so it keeps calling tools and burning tokens until it hits a timeout or someone notices the graph.

A vague done condition.You told the agent to "resolve the ticket" or "finish the task" without defining finished. The agent cannot tell when it has succeeded, so it keeps trying to do better. A loop with no clear exit runs as long as you let it.

A retry path that reaches for the expensive model. Someone set the fallback so that when the cheap model is unsure, the agent retries on the expensive one to be safe. On a hard task the agent is unsure on every pass, so every pass escalates. The most expensive run you will ever pay for is the one that retries ten times on the top tier.

Put two of these together and you get the Tuesday bill. A vague done condition keeps the loop running, and an eager retry path makes every extra pass cost the most it possibly can.

The cap catches it too late, and aims at the wrong target

A dollar cap fires after the money is spent. By the time a workflow trips its monthly ceiling, the bad run already happened. The cap just stops the next person's good work to pay for it. It also lands on the wrong thing. It limits the person, not the loop. The developer who got cut off at $1,500 was not the problem. The unbounded workflow was, and it is still sitting there, ready to do it again next month.

A step ceiling fires before. An agent capped at eight passes cannot run forty. When it hits the ceiling it stops and hands the task to a human instead of spending into the dark. You lose one task to a person. You do not lose the budget. That is the difference between a bill you read after the fact and a limit that holds in the moment.

The bounded-loop checklist

Four controls. None of them require a new platform.

A hard step limit on every agent. Pick the number of passes a healthy run takes, add a small margin, and make that the ceiling. A run that exceeds it stops and pages a human. This single control removes most of the tail.

An explicit done condition.Define finished in terms the agent can check. "Ticket has a reply that answers the question and a status of resolved" beats "resolve the ticket." An agent that knows when it is done stops when it is done.

One defined escalation path.Decide in advance when a run is allowed to reach for the expensive model, and make it a specific condition, not a default. Log every time it happens. "Use the big model just in case" is how a workflow that should cost cents starts costing dollars a run.

A cost line per run. Log the token or dollar cost of each completed run next to what it accomplished. This is one field, not a data project. When the number creeps, you see it in days instead of in the quarterly bill, and you can point at the workflow that changed.

Where the cap still belongs

Keep the spend cap. Use it as the backstop, the smoke alarm behind the real controls, set low enough that hitting it means something is wrong rather than that work got busy. The mistake is using the cap instead of bounding the loop. The cap tells you the house is on fire. The step limit and the done condition are what keep it from catching.

The companies in the news are reaching for caps because a cap is the fastest thing to roll out under pressure. It buys time. It does not fix the thing that spent the money. The workflow that blew the budget will blow the next one too, one step at a time, until someone bounds the loop.

If you are trying to figure out which of your agents can spiral and what the ceiling should be, reach out. We bound the loop and add the cost tracking before the bill does the teaching.