Cost Control for AI Agents: Three Layers and What Each One Misses

An agent ships on a Friday. It enters a retry loop. By Monday a meaningful share of the month's model budget is gone, and the agent never malfunctioned — it did exactly what it was written to do, at a volume nobody had bounded.

The interesting part is not the incident. It is what happens the next time that vendor sits in a bank's operational-resilience review and is asked what stops it happening again.

How the cost question actually arrives

Cost rarely appears in a vendor-risk pack as a cost question. It appears as a resource-management question, because DORA obliges the financial entity to understand how its providers bound the consumption of the systems it depends on. The form it takes is: what limits exist, at what scope, who is told when one is approached, and show me the last time one fired.

A team that has controls but no record of them operating can answer the first half of that and not the second. That gap is the whole subject of this post.

The most expensive agent is not the one on the most capable model. It is the one whose spend nobody has bounded, because nobody knew it needed bounding.

Why agent spend resists prediction

Conventional software cost is roughly linear in the work: a query costs about what the last one cost. An agent deciding between approaches may make a handful of model calls or many more, depending on how the task unfolds. Tool-calling compounds it — an agent invokes another agent, which invokes a model, which triggers a retrieval step. The cost of a task is a tree, not a line, and its depth is decided at runtime.

Retries are the part that hides. When a model returns something malformed, many frameworks retry automatically and silently. The application log shows a task that succeeded. The bill shows a task that succeeded several times. Nothing in between reports the difference unless something is counting.

Layer 1 — budgets, scoped

A budget is a spend limit and a period, attached to a scope: an organisation, a workspace, or an individual agent. Spend accumulates against it and an alert fires at a configurable threshold, 80% by default. It is a single threshold, not a ladder — worth knowing before you design an escalation path around it.

Setting the number is an observation problem rather than a modelling one. Run the agent, measure what it actually consumes across the range of tasks it gets, and set the limit above the observed spread by enough that ordinary variation does not trip it. A budget derived from a theoretical maximum is either so high it never fires or so tight it fires constantly, and a control that cries wolf gets switched off.

The honest bound: a budget cannot stop the run that first exceeds it. An LLM call's cost is not knowable before the call is made, so what a budget does is learn the spend from real runs and stop the next one before the overage grows. Any vendor claiming their cost control prevents overspend outright is describing something that cannot be built.

Layer 2 — provider quotas

Budgets are per-scope; a set of individually well-behaved agents can still add up to more than the organisation meant to spend with a given provider. Provider quotas are the ceiling that catches the aggregate. They are org-scoped, because that is where provider keys and billing actually live.

Usage against a quota is kept current by one of three mechanisms, and the difference matters for what the number means. Internal tracking aggregates from recorded gateway requests. Cloud-monitoring sync pulls from the provider's own metrics. Manual is an administrator typing in a figure. A quota on manual sync is a planning aid, not a measurement, and it should not be presented to a reviewer as one.

Layer 3 — model restrictions

Not every task needs the most capable model available. Restrictions express that as policy: a list of models an agent is permitted to use, enforced when the call is routed rather than left to whatever the code happens to request. A null list means no restriction.

The failure this actually prevents is less glamorous than cost optimisation and more common. A developer raises an agent to a more expensive model while debugging, gets the result they wanted, and ships without lowering it again. A policy-level restriction makes that a rejected call instead of a line item discovered six weeks later.

How much any of this saves depends entirely on your workload mix, and anyone quoting you a percentage has not seen your traffic. Measure your own before and after; the ratio between two models on your tasks is the only number that means anything here.

Where the layers stop

Two limits are worth stating plainly, because both change what a cap means in a questionnaire.

The first is that measured token volume is not always billed money. A flat-rate subscription agent generates real tokens whose marginal cost is zero. Blocking live traffic against a bill nobody owes is a worse outcome than allowing the call, so metered spend at or above the limit blocks, while spend that only crosses the line once unbilled volume is counted allows — and says explicitly that the cap was not enforced for that call, rather than passing silently.

The second is that the check fails open. A cache miss, a slow query, or a malformed budget row lets the call through. Cost control causing an availability incident is a bad trade, so that is deliberate — but it means a budget is a strong control under normal conditions and no control during a specific class of outage. Say so before a reviewer finds it.

The evidence this leaves

What a reviewer can be handed is not the dashboard. It is the budget rows showing which limit applied at which scope, an append-only trail of when limits were changed and by whom, the alert and block events showing the controls operating against real traffic, and per-call records tying spend to the agent and run that caused it.

The change trail is the piece most teams do not have. Without it, a statement about what the cap was is only ever a statement about today, and a reviewer asking what applied during the quarter under review has nothing to read.