How to stop an AI agent from running up your bill

To stop an AI agent from running up your bill, give every run its own spend cap and make it a hard stop. A monthly limit on the whole account is still worth having, but it is too coarse to catch one runaway job. By the time it trips, the money is already spent, and every other agent stops with it. A per-run cap ends the one run that went wrong, close to the moment it went wrong. Add a cap on turns or time as a second limit. Use alerts as well as these limits, never in place of them.

Why are agent costs so hard to predict?

Because an agent decides how much work to do, and the price grows with every step it takes.

Anthropic measured its own systems and found that an agent uses about four times the tokens of a chat, and a multi-agent system about fifteen times. It also described early versions searching the web endlessly for sources that did not exist. That is the failure that matters for cost: an agent that cannot finish does not stop. It keeps trying.

The arithmetic makes it worse. An agent's context does not reset between turns. The full history, every tool call and every tool result, is sent again on each request. Prompt caching makes the repeated part cheaper, but the bill still grows with the length of the run. Each turn re-reads every turn before it, so a run that takes forty turns instead of ten costs more than four times as much.

Our own measurements point the same way. On runs made by our cloud agents, a failed run cost about as much as a successful one. Nothing about spending money told a run it was going nowhere.

Is a monthly spend limit enough?

No. It is the last line, not the first.

The platforms give you limits at the level of an account or a workspace. OpenAI lets you set a monthly limit per organization or per project, as an alert or a hard stop, and notes that spend can slightly exceed the cap before it is enforced. Anthropic offers spend limits per organization and per workspace. Cloud billing tools are slower still. AWS Budgets data refreshes up to three times a day, so it cannot stop a loop that is running now.

These limits have two problems for agent work. They are slow, because they are measured over a month. They are also blunt. When one hits, it stops every agent in the account, including the ones doing useful work.

Where should the cap go?

On the run, with a project default and an override on the task.

• Per run is the unit that matches the risk. One task going wrong should stop that task and nothing else.
• A project default saves you from setting one on every task, and records what normal looks like for that kind of work.
• A task override is for the job you already know is large. Raising a cap on purpose is a decision. Lacking one entirely is an oversight.

Agent frameworks are starting to support this. Anthropic's Agent SDK has a maximum budget in dollars and a maximum number of turns, and both default to no limit. A gateway such as LiteLLM can reject requests once a key, team or user is over budget. Whichever you use, check the default. A control that is off by default protects no one.

Should the cap warn first, or stop?

Stop. A warning sent to an agent is one more instruction for the agent to weigh, and an agent stuck in a loop is not weighing well. A warning sent to a person assumes someone is watching, and much agent work runs while nobody is.

Two details make a hard stop trustworthy:

• Say how far past the cap it went. Usage is reported per response, so a run can pass its cap by what one response costs. Anthropic's SDK documentation says to leave headroom for this. A good halt records both the cap and the amount actually spent, so nobody has to work out why the numbers differ.
• The stop is decided outside the agent. An agent should never enforce its own limit. The cap belongs to whatever holds the meter and can revoke the agent's access, so a confused agent cannot argue past it.

What else should limit a run?

A time or turn limit, because some failures are cheap per turn and simply never end. Anthropic's guidance on building agents recommends a maximum number of iterations as a stopping condition. Bounded retries help too. A run that has failed its checks twice should go to a person, not try a third time. We cover that in what harness engineering is.

Then measure cost per verified result, not cost per run. A cheap run that produced nothing usable cost more than an expensive one that passed. That is the number to report in a case for agent ROI.

How does Cognibl cap a run?

Every cloud agent run has a spend cap, counted in the credit you are actually charged. The default is $10 a run, because the real runs we measured cost $3 to $9, so the default catches a runaway and rarely touches normal work. A project sets its own under Settings, in Agent access, and a task can override it, anywhere from $1 to $1,000.

The halt is hard, with no warning turn. When a charge takes a run to its cap, Cognibl stops that one run the way a person's halt does: the agent's token is revoked first, then the process is stopped. The task gets a comment saying what was spent against what cap, and the card moves to Blocked so that a person decides whether to raise the cap or split the task. Each run also has a time limit set by the task's effort, and the organization's prepaid credit balance is the last stop. See how cloud agents run and are billed.