What is a reasonable spend cap for an AI agent?

There is no single number, because a sane cap is derived from your own measured run cost rather than copied from someone else. The rule we start from is a per-run cap of roughly ten to twenty times the median cost of a normal run for that agent. Below ten times you spend your life clearing false alarms; above twenty times a runaway agent can burn a lot of money before anything trips. You cannot set this number until you have measured what a normal run costs, which is why observability comes before limits.

Why is a monthly AI budget not a real guardrail?

Because it is a lagging control. By the time a monthly cap trips, the money is already spent and the damage is already done. A monthly budget tells you the size of the bill you are willing to receive; it does not stop the run that caused it. The limits that actually protect you are the per-run cap, which bounds the blast radius of one bad task, and the per-window cap, which catches retry storms where each individual run looks fine.

Should I build my own AI agent cost controls?

Almost certainly not. The mechanism is commodity and mostly free: LiteLLM does per-key and per-team budgets and rate limits, Langfuse and Helicone do cost tracing per step, and Portkey adds routing and guardrails on top. What is not commodity is deciding what limits to set, for which agent, and who gets woken up when one trips. Buy or adopt the mechanism; spend your scarce engineering time on the judgment.

What stops an AI agent from looping and burning budget?

A step or iteration limit, not a dollar limit. Most runaway agent costs come from loops rather than from a single expensive call, and a dollar cap only trips after the spend has happened. A hard ceiling on tool calls or iterations per run stops the loop while it is still running. Dollar caps are the backstop; step caps are the actual control.

Which AI agents cost the most to run?

Agents with an unbounded tool loop and no natural stopping point — research, browsing and coding agents — carry by far the widest cost variance, because nothing in the task itself tells them when to stop. Single-call agents such as classifiers and triage bots are cheap and predictable per run, so their risk is volume rather than blast radius. The two need different limits, which is why one global budget across all of them protects neither.

All of Pulse

What a sane agent spend cap actually looks like

ExponenLabs30 August 20267 min read

The most common question we get about agent cost is "what should our monthly AI bill be". It is a reasonable question and it is the wrong control. The bill is an outcome. By the time you are looking at it, every decision that produced it has already been made.

The useful question is narrower: what is the most a single run of this thing can cost, and how many times can it run before somebody finds out.

One budget is not a guardrail

Almost every team we look at has exactly one limit in place: a monthly cap, usually set at the provider or on the company card. It feels like a guardrail because it has a number in it. It is the one limit in the whole stack that cannot save you.

A monthly cap is a lagging control. It trips after the money is gone. It tells you the size of bill you are willing to receive, which is a budgeting decision, not a safety one. The failure it is supposed to prevent — an agent that got stuck in a loop on Friday night — has already fully played out by the time the cap does anything at all.

There are three caps worth having, and the monthly one is the least useful of them.

The per-run cap bounds the blast radius of one bad task. This is the limit almost nobody sets and the one that matters most, because it is the difference between a single wasted run and an open-ended one.

The per-window cap — per hour or per day — catches the case where every individual run is perfectly reasonable and there are suddenly four thousand of them. Retry storms and queue replays look completely healthy at the level of a single request.

The per-month cap is the backstop. Keep it. Just stop believing it is protecting you.

Deriving the per-run number

The per-run cap is the one people find hard, because there is no published number to copy and the honest answer is that it depends on what the agent does. But the method is straightforward.

Measure what a normal run costs first. Not the average across all your agents — the median for this agent, doing its actual job, on real inputs. You cannot set a meaningful limit on a number you have never looked at, which is why observability has to come before enforcement. If you skip this step you will end up picking a round number, and a round number is how you get a cap that either fires constantly or never fires at all.

Then set the cap above the legitimate worst case and below the number that would make you angry. The rule we start from is ten to twenty times the median run cost. Under about ten times, normal variance — a longer document, a harder ticket, a customer who writes an essay — trips the limit often enough that somebody will quietly raise it and stop reading the alerts. Over about twenty times, a genuinely stuck agent has room to do real damage before anything notices.

That is a starting point, not a law. It is deliberately a ratio rather than a dollar figure, because a dollar figure copied from an article about somebody else's workload is worth nothing.

Different agents, genuinely different profiles

The reason a single global budget protects nothing is that the shape of the risk changes completely depending on what the agent is.

Single-call agents — classifiers, routers, triage bots, extraction jobs — have tight, predictable per-run costs. Input size is bounded, there is no loop, and variance is low. You can cap these close to the median, perhaps three to five times. Their risk is not blast radius, it is volume: the danger is ten thousand invocations, not one expensive one. Rate limits do more for these than spend limits.

Conversational agents sit in the middle. Cost per turn is modest, but context accumulates over a session, so a long conversation costs disproportionately more than a short one. The thing to bound is session length, not just spend.

Tool-loop agents — research, browsing, anything that decides for itself when it is finished — are where the money actually goes. Cost variance is enormous, because nothing inside the task tells the agent to stop. A question that resolves in three lookups and a question that spirals into forty are the same request as far as your budget is concerned.

Coding agents are the extreme case: long loops, large context, and retries that compound. A failing test that the agent keeps trying to fix is the single most reliable way we have seen to turn a small task into a large invoice.

The limit that actually stops a runaway

Here is the part that gets missed. For anything with a loop, the control that saves you is a step limit, not a dollar limit.

Most runaway costs are not one expensive call. They are a cheap call repeated far more times than anyone intended. A dollar cap can only react to that after the spending has happened — it is a tripwire at the end of the corridor. A hard ceiling on iterations or tool calls per run stops the loop while it is still looping.

Set both. Treat the step limit as the control and the dollar limit as the backstop, not the other way round. As starting points, a research task that cannot answer itself within roughly ten to twenty-five tool calls is usually not converging, and a coding agent that has gone past fifty to a hundred iterations on one task has almost always stopped making progress. When an agent hits that ceiling it should stop and say so, loudly, rather than quietly trying again.

An alert nobody owns is not a control

The last piece is unglamorous and it is where most of these setups actually fail.

Every limit needs a name attached to it — a person, not a channel. An alert that fires into a busy engineering channel at 2am on a Saturday is not a guardrail; it is a log entry with ambitions. The question to ask about every cap you set is: when this trips, who specifically finds out, on what device, and what are they empowered to do about it at that moment.

If the honest answer is "it goes to Slack and someone will see it Monday", then for everything that happens between Friday and Monday you do not have a limit. You have a record.

And you need to be able to stop it. Revoking a scoped key is a perfectly good kill switch, which is one of the better arguments for routing agent traffic through a gateway rather than letting each service hold its own provider credentials. What matters is that stopping a misbehaving agent is something one person can do in under a minute without a deploy.

You do not need to build any of this

Worth saying plainly, because it saves people money: the mechanism here is a solved, commodity problem, and most of it is free.

LiteLLM does per-key, per-team and per-user budgets with rate limits, and virtual keys you can revoke. Langfuse traces cost per step across a whole agent run, including the retrieval and embedding calls that people forget to count. Helicone is close to a one-line drop-in for cost and latency logging. Portkey layers routing, budgets and guardrails on top of a large model catalogue. The major providers all expose workspace-level spend controls of their own.

Building your own version of this is a bad use of a small team's time. There is nothing left to invent in the enforcement layer.

What none of these tools will do is tell you what number to put in the box. They ship the mechanism, correctly and for free. The judgment — which agent gets which cap, what a normal run costs here, which loops need a step ceiling, who gets woken up and what they can do at 2am — is the part that is specific to your business, and it is the part that is actually load-bearing.

That is the reliable pattern with AI infrastructure generally. The mechanism commoditises fast and gets cheaper every quarter. The decisions about how to use it do not commoditise at all, and they are where the money is either saved or quietly lost.