Skip to content
Journal / pricing

Spend caps for AI agents: budget safety before the loop runs away

Agents can burn API budget at machine speed. How spend caps, low-balance alerts, and worst-case price gates keep a runaway loop from becoming a bill.

An agent stuck in a loop is not like a human refreshing a page too often. It is a program firing paid API calls at machine speed, around the clock, with no boredom threshold and no gut feeling that something is off. Run the arithmetic once and it stays with you: an agent looping on Exa searches at $8.40 per thousand queries routed, one query per second, burns about $30 an hour. Leave it over a weekend and that is a $1,500 incident from a single while-loop with a bad exit condition. Swap in a video generation call at $0.048 per clip-second and the numbers get worse faster.

I run a tool router, which means other people’s runaway loops can become my support tickets, so I have strong opinions about budget safety. The good news: this is a solved problem in structure, if not in most people’s setups. You need layers, and each layer catches what the previous one missed.

Layer one: a hard ceiling on total exposure

The foundation is making unbounded spend impossible, and prepaid balances do this by construction. If the account holds $50 of credits, the worst possible incident costs $50. A card-on-file subscription with usage billing has no such property: the meter runs until someone notices. This is the core argument I made in prepaid credits vs subscriptions, and it is why route.tools is prepaid, starting from the $2 of free credits every account gets at signup. The ceiling is not a feature you configure; it is the shape of the billing model.

The objection writes itself: what if the balance runs out mid-workload and legitimate traffic fails? That is a real cost, and it is the tradeoff you are explicitly choosing. For agent workloads I will take “the agent stopped and paged me” over “the agent kept going and billed me” every single time.

Layer two: caps scoped to keys, not accounts

An account-level ceiling protects the account, but it lets one misbehaving agent starve every other workload sharing the balance. The fix is scoping: give each agent, environment, or customer its own key with its own monthly cap. A runaway staging agent should exhaust its own small allowance and die quietly, not drain the production budget.

Scoped caps also turn budgeting into documentation. When each key carries a number, you have written down what each workload is supposed to cost, and drift becomes visible: the agent that used to fit in $10 a month and suddenly does not is telling you something changed, usually a prompt edit that doubled its tool calls.

Layer three: alerts before the wall, not at it

A hard cap that fires with no warning converts a budget problem into an outage problem. Low-balance alerts exist to give you the interval between “this is trending wrong” and “this is now down”, and the alert threshold should be set from your burn rate, not a round number: if your agents spend $5 a day, an alert at $10 gives you two days; an alert at $1 gives you an anxious evening.

The prerequisite for any of this is knowing what things cost at the moment they happen. Every response from our router includes the exact price of that call, which sounds mundane but is precisely what makes burn-rate math possible without waiting for an end-of-month invoice. Per-call prices are also how you find the loop: sort your recent calls by key and the runaway is the one with ten thousand identical rows.

Layer four: worst-case price gates

The subtlest layer is checking prices before calls happen, not after. Tool categories span four orders of magnitude in per-call cost: a routed Serper query is about $0.0012, a code sandbox burns $0.0000168 per vCPU-second, and a 10-second video clip runs about $0.48. An agent authorized to call all of them should not treat those as interchangeable actions.

A worst-case price gate is a rule of the form “no single call above $X without escalation”. Because our routed prices are deterministic (provider list plus 20%, published at /docs/pricing), the worst case per call is knowable in advance: the most expensive provider in the category’s failover chain. Cheap categories can run ungated; expensive categories get a confirmation step, a tighter loop counter, or a human in the loop. Related and worth knowing: per-request wall-clock budgets cap how long a failover chain can run (search gets 20 seconds; video, being async and slow, gets 330), so a single request cannot hang forever accumulating attempts either.

The checklist

Prepaid ceiling so unbounded spend is structurally impossible. Per-key caps so blast radius stays scoped. Alerts calibrated to burn rate so caps do not become surprise outages. Price gates on the categories where one call costs real money. None of these require a router, but they do require your provider to expose the primitives: per-call pricing, scoped keys, and caps that actually halt traffic.

Start by finding out what your expensive categories even cost: the per-unit prices for everything we route are side by side on the search API comparison page and its siblings.