AI Agent Cost Overruns: Essential Guide to Avoid Risk

AI agent cost overruns happen when an autonomous system spends far more on model inference than anyone planned, and they have become the most common way an otherwise successful AI project loses its budget. A chatbot costs roughly what its users ask it to cost. An agent decides its own workload: it chooses how many steps to take, how many tools to call, how much history to carry forward and how many times to try again. Every one of those decisions is a purchase, and none of them arrives with a purchase order attached.

What makes this dangerous is not the size of the numbers but the shape of the failure. An agent that loops does not crash. It keeps working, politely and expensively, producing plausible output the whole time. There is no error page, no alert, no red dashboard tile. The first evidence of an AI agent cost overrun is usually a finance question three weeks later, by which point the money is spent and the logs that would explain it have rotated away.

This guide is about prevention rather than post-mortem accounting. It covers the specific failure modes that make agents overspend, how to model the unit economics of a single run before you build anything, the design-time and runtime guardrails that cap the damage, how to test for cost the way you test for correctness, and how to detect a problem within hours instead of at month end. If you are setting organisation-wide policy on budgets and model routing, our companion guide to AI cost governance covers that layer; this article is about preventing AI agent cost overruns inside the agents themselves, which is where the sharpest surprises live.

Table of contents

Why AI agent cost overruns happen and why they hide
The seven failure modes behind most AI agent cost overruns
Model the unit economics of one run before you build
Design-time controls that prevent AI agent cost overruns
Runtime guardrails: budgets, breakers and kill switches
Test for cost before production, not after
Detect an AI agent cost overrun in hours, not at month end
A worked example: the invoice agent that tripled its bill
Governance: deciding who owns the number
Common mistakes that keep AI agent cost overruns alive
Frequently asked questions about AI agent cost overruns
References

Why AI agent cost overruns happen and why they hide

Every team that suffers an AI agent cost overrun has the same reaction: the design looked cheap on paper. It was cheap on paper. The gap between the paper and the invoice comes from four structural properties of agentic systems that traditional software cost models simply do not have.

An agent decides its own workload

A conventional API call does one unit of work for one unit of money. An agent receives a goal and determines the work required to reach it, which means the cost of any single request is a function of how difficult the agent believes the task to be. Two requests that look identical to a user can differ by a factor of thirty. Capacity planning built on average request counts has no way to represent that, so it silently assumes the cheap case, and an AI agent cost overrun is simply the gap between that assumption and the real distribution.

The context grows with every single turn

Most agent frameworks resend the accumulated conversation, tool outputs and scratchpad on every step. A ten-step run therefore does not cost ten times one step; it costs closer to the sum of a growing series, because step ten carries the output of steps one to nine with it. This quadratic drift is the single most underestimated contributor to AI agent cost overruns, and it is invisible in any diagram that draws each step as an identical box.

Retries multiply rather than add

Retry logic at three layers is normal: the HTTP client retries, the agent framework retries a failed tool call, and the orchestrator retries the whole run. Three retries at three layers is not nine attempts of equal cost, because each retried run re-enters the loop with its own accumulated context. A transient outage on a Tuesday afternoon can produce a day of spend in twenty minutes, with nothing in the logs marked as an error to explain the AI agent cost overrun afterwards.

Nothing in the system reports failure

The core problem is the absence of a natural failure signal. A runaway virtual machine trips an alarm; a runaway agent produces correct-looking answers. Every individual call is legitimate, well-formed and successful. Because no component is broken, no monitoring rule fires, and the AI agent cost overrun accumulates through a system that reports itself as entirely healthy.

Property	Chat assistant	Autonomous agent
Calls per user action	One, predictable	Between one and hundreds
Who sets the workload	The person typing	The model itself
Context growth	Linear with turns	Compounding across steps
Failure signal	User complains	None, output looks fine
Worst realistic case	A long conversation	An unbounded loop
Time to notice	Minutes	Weeks without controls

The seven failure modes behind most AI agent cost overruns

Prevention is easier when you stop treating overspend as one problem. In practice almost every AI agent cost overrun traces back to one of seven mechanisms, and each has a different control. Naming them makes an AI agent cost overrun review far quicker, because the question becomes “which of the seven can this architecture do?” rather than “does this feel expensive?”.

The reflection loop that never converges

An agent asked to critique and improve its own work will happily do so forever if nothing stops it. Each cycle re-reads the previous draft, produces a new one, and adds both to the context. Without a convergence test or a hard iteration cap, quality plateaus after two passes while cost carries on climbing linearly. This is the classic AI agent cost overrun and the cheapest one to eliminate.

The retry storm

A downstream API returns a 500 for ten minutes. The agent treats each failure as a signal to try a different approach, generating fresh reasoning for every attempt across every concurrent run. This is the fastest-moving of all AI agent cost overruns, capable of turning a monthly budget into an afternoon.

Tool-call fan-out

Give an agent a search tool and it will search. Give it five tools and a vague instruction and it will call all five, sometimes repeatedly, because calling a tool is cheap in its own reasoning and expensive on the invoice. Fan-out is particularly costly when each tool returns a large document that then lives in the context for the rest of the run, which is how a modest fan-out becomes a substantial AI agent cost overrun.

Sub-agent recursion

Multi-agent designs where a planner spawns workers can multiply spend without any single component behaving badly. If each worker may itself delegate, the cost of a run becomes a tree rather than a line, and a depth limit is the only thing standing between you and an exponential AI agent cost overrun.

Context accumulation

Carrying the entire history forward is the default in most frameworks because it is the simplest correct behaviour. It is also the reason a long run costs far more per step at the end than at the start. Research on long-context behaviour suggests the model is not even using most of that material effectively, so the resulting AI agent cost overrun buys almost nothing.

An over-capable model on trivial steps

Agents frequently use one model for everything, including steps that are pure formatting, classification or routing. Paying frontier prices to decide whether a string is a date is a permanent tax on every run, and it is the easiest of all AI agent cost overruns to remove.

Evaluation runs nobody budgeted

Testing an agent means running it, and a serious evaluation suite of two hundred scenarios executed nightly is a production workload wearing a test badge. Teams routinely forecast live spend accurately and then create a second AI agent cost overrun in continuous integration.

Where excess agent spend concentrates, by failure mode (illustrative model)

Context accumulation across steps 31%

Loops and non-converging reflection 22%

Over-capable model on simple steps 18%

Tool fan-out and repeated calls 14%

Retry storms and failed runs 9%

Unbudgeted evaluation and replay 6%

Model the unit economics of one run before you build

The cheapest possible prevention is arithmetic done before any code exists. Most teams that avoid an AI agent cost overrun did one thing differently at the start: they costed a single run, in a spreadsheet, including the bad cases.

Cost per run is the only number that scales

Total monthly spend tells you nothing you can act on, because it moves with volume, and a rising cost per run is the definition of an AI agent cost overrun in progress. Cost per completed run is the number that survives growth, supports a business case, and makes a regression visible. Fix the denominator on business outcomes rather than API calls: cost per invoice processed, per ticket resolved, per document reviewed.

Count steps, not requests

Estimate the median number of steps a run will take, then the ninetieth percentile, then the worst case your step cap allows. Multiply each by the average tokens per step, remembering that later steps carry more context than earlier ones. A model that assumes constant cost per step will understate the total by a factor of two or more on any run longer than about six steps.

Build a range, not a point estimate

Present three numbers to whoever signs off: expected, plausible-bad, and capped-worst. The third is the one that prevents an AI agent cost overrun becoming a governance incident, because it is a promise the architecture can actually keep. If you cannot state the capped-worst case, the design has no cap, and that is the finding.

Set the walk-away threshold up front

Agree the cost per run at which the automation stops being worth it, before anyone is emotionally invested. If a human handles the task for four pounds and the agent costs three, a forty per cent AI agent cost overrun erases the case entirely. Writing that threshold down converts a future argument into a pre-agreed trigger, and it pairs naturally with the discipline in our guide to enterprise AI ROI.

Scenario	Steps	Avg tokens per step	Relative cost per run
Design assumption	4	3,000	1.0x baseline
Median real run	6	5,200	2.6x baseline
Ninetieth percentile	11	9,400	8.6x baseline
Capped worst case	15 hard cap	12,000	15.0x baseline
Uncapped loop	Unbounded	Growing	Unbounded

Design-time controls that prevent AI agent cost overruns

Guardrails added after launch are repairs. Guardrails designed in are free. These five controls cost almost nothing to implement at build time and remove the majority of AI agent cost overruns before they can occur.

Cap steps, depth and wall-clock time at the orchestrator

Every agent needs three hard limits enforced outside the model’s control: a maximum number of steps per run, a maximum delegation depth for sub-agents, and a maximum wall-clock duration. The model must not be able to raise them, because a model asked to respect its own budget will reason its way past it whenever the task looks important, and that is precisely where an AI agent cost overrun starts.

Give every tool its own budget

Tools are where fan-out becomes expensive, so attach a call quota to each one and a size limit to what it may return. Truncating a 40,000-token document to the relevant 2,000 tokens at the tool boundary is worth more than any prompt optimisation, and it protects every subsequent step of the run at once.

Make the cheapest capable path the default

Route trivial steps to a small model, reserve the frontier model for genuine reasoning, and short-circuit entirely where a deterministic rule will do. A regular expression that extracts a reference number is not merely cheaper than a model call, it is free, faster and testable. Applying ordinary cost optimisation thinking to agent design removes more AI agent cost overrun risk than any negotiation with a vendor.

Summarise the history instead of resending it

Replace the accumulated transcript with a compact running state once a run passes a defined length. Keep the goal, the decisions taken, the outstanding questions and the last tool result; discard the rest. This single change flattens the compounding curve that drives most AI agent cost overruns on long runs.

Prefer deterministic code wherever the task is deterministic

The strongest cost control in agent design is refusing to use an agent for the parts that are not agentic. Validation, arithmetic, lookups, formatting and routing all belong in code. An architecture that uses intelligent automation for the deterministic majority and a model only for genuine judgement is cheaper, more reliable and considerably easier to test. Every step you delete is a step that can never contribute to an AI agent cost overrun.

Runtime guardrails: budgets, breakers and kill switches

Design-time controls assume the future behaves as expected. Runtime guardrails assume it will not. These are the mechanisms that convert an unbounded AI agent cost overrun into a bounded, logged, recoverable incident.

A hard cost ceiling for every run

Track spend inside the run itself and abort when it crosses a threshold, exactly as you would enforce a memory limit. The ceiling should be set from the ninetieth-percentile figure in your unit-economics model rather than from a round number, and a breach must be logged as an incident rather than swallowed. A run that stops at its ceiling has done its job even when the answer is incomplete, because a bounded AI agent cost overrun is a manageable one.

Circuit breakers on repeated identical work

If an agent issues the same tool call with the same arguments three times, it is stuck. Hash each call and break the circuit on repetition. This one rule kills the reflection loop, the retry storm and most sub-agent recursion, which is three of the seven AI agent cost overrun mechanisms, and it requires no understanding of the task whatsoever.

Concurrency and rate caps per agent identity

Give each agent its own credential and its own quota. Shared keys make attribution impossible and let one misbehaving workload consume the capacity of every other, turning a single AI agent cost overrun into a platform-wide one. Per-identity rate limits also give you an instant containment tool: throttle one agent to zero without touching anything else.

A kill switch and a named person who may pull it

Every agent needs a documented way to be stopped immediately, tested at least once, and a named owner authorised to use it without escalation. In practice the delay in stopping a runaway agent is almost never technical; it is the twenty minutes spent deciding who is allowed to decide, and those twenty minutes are pure AI agent cost overrun.

Guardrail	Failure mode it stops	Enforced at	Cost if missing
Step cap	Reflection loop	Orchestrator	Unbounded per run
Depth cap	Sub-agent recursion	Orchestrator	Exponential per run
Tool quota	Fan-out	Tool layer	High and repeatable
Cost ceiling	All of them, eventually	Gateway or runtime	Whatever the loop costs
Duplicate-call breaker	Retry storm	Tool layer	Fastest-moving overrun
Kill switch	Everything unforeseen	Platform	Hours of unchecked spend

Test for cost before production, not after

Teams test agents for correctness and safety and almost never for cost, which is why the first true measurement often happens in production with real money. Cost is a testable property, and treating it as one is the highest-return habit in AI agent cost overrun prevention.

Build a cost regression suite

Run a fixed set of representative scenarios on every meaningful change and record tokens, steps and cost per run for each. Fail the build when the median moves more than an agreed percentage, so that an AI agent cost overrun arrives as a failed build rather than as an invoice. A prompt edit that adds four hundred tokens to every step is invisible in review and obvious in a regression suite, and the same discipline that governs testing AI agents before production applies directly to spend.

Include adversarial and pathological inputs

Your median scenario will never produce an AI agent cost overrun. Deliberately test the cases that will: an empty document, a hundred-page attachment, a contradictory instruction, a tool that times out, a question with no answer. These are the inputs that reveal whether the caps actually hold, and they belong in the suite permanently.

Shadow-run at realistic volume

Before launch, run the agent against real traffic without acting on its output, and measure. Shadow running is the only way to discover the true distribution of run lengths, and it routinely finds a long tail that nobody modelled. It also gives you the ninetieth-percentile figure your cost ceiling should be set from.

Budget the evaluation itself

Give the test suite its own cost line and its own limits, because an AI agent cost overrun in testing spends exactly the same money as one in production. Nightly runs of a large scenario set can quietly exceed live spend, and a suite that expands with every bug fix will grow without anyone reviewing the arithmetic. The metrics discussed in our guide to AI agent evaluation metrics should carry a cost column alongside every quality column.

Detect an AI agent cost overrun in hours, not at month end

Prevention will not be perfect, so the second objective is compressing the time between a problem starting and somebody knowing. The difference between four-hour and four-week detection of an AI agent cost overrun is usually two orders of magnitude of money.

Alert on cost per run, not on the total

A total-spend alert fires only after the AI agent cost overrun has finished, and it cannot distinguish growth from waste. Cost per run is normalised against volume, so a step change stands out immediately even in a week when traffic doubles. Set the alert on a rolling median rather than a mean, because a handful of extreme runs will drag a mean around and train everyone to ignore it.

The four signals worth paging on

Watch cost per run, steps per run, tokens per step and the proportion of runs terminating at their cap. The last one is the most valuable and the least used: a rising share of capped runs is the earliest possible warning of an AI agent cost overrun, and it appears before the money does. The alerting philosophy in the Google SRE workbook transfers directly here.

Tag every call with a run identifier

Attribution is what turns a number into an action. Every model call should carry the run id, agent name, environment, tenant and version of the prompt and toolset. Without those tags you can see that spend rose but never which change caused it, and every AI agent cost overrun investigation becomes archaeology. Standard conventions exist for exactly this, and adopting them costs a day.

Run a daily burn-down against the monthly envelope

Compare spend to date against the linear path through the monthly budget, every morning, in a place people already look. A daily burn-down catches an AI agent cost overrun on day two rather than day thirty, and it makes the conversation about a forecast rather than an apology. This is the same telemetry discipline covered in our guide to AI agent monitoring in production.

Money at risk before detection, by monitoring maturity (illustrative, 30-day view)

Invoice review only, ~30 days 100%

Weekly finance report, ~7 days 23%

Daily burn-down, ~1 day 4%

Cost-per-run alert, ~2 hours 1%

A worked example: the invoice agent that tripled its bill

Abstract advice is easy to nod at, so here is a composite example built from the pattern this failure usually follows. The figures are illustrative, but the sequence is not.

The starting position

A finance team deploys an agent that reads supplier invoices, matches them against purchase orders, flags discrepancies and drafts a response. It uses natural language processing to interpret unstructured invoice layouts, calls three tools, and was costed at roughly eighteen pence per invoice across four steps. Volume is 20,000 invoices a month, so the forecast is about £3,600.

What went wrong

Month one landed at £11,400, an AI agent cost overrun of more than three times the forecast. Nothing was broken. Attachments were larger than the sample used for costing, so each tool call returned more text; that text stayed in context for every subsequent step. Ambiguous invoices triggered a clarification loop with no iteration limit, and roughly six per cent of runs exceeded twenty steps. A weekend outage at the purchase-order system produced retries on every run for eleven hours. One model served every step, including a formatting step that could have been a template.

The five changes

The team truncated tool output at the boundary and kept only matched line items. They summarised the run state after step four instead of resending the transcript. They capped runs at eight steps with a duplicate-call breaker. They routed classification and formatting to a small model and kept the frontier model for discrepancy reasoning. They added a per-run cost ceiling and an alert on the share of capped runs.

The result

Cost per invoice settled at eleven pence, below the original estimate, with match accuracy unchanged in paired sampling. The capped-run share sat at 0.8 per cent and became the team’s leading indicator. Crucially, the worst-case AI agent cost overrun was now bounded: the same weekend outage repeated two months later and cost £40 instead of £2,000, because the breaker stopped each run after three identical failures.

Cost per processed invoice, before and after the five changes (pence)

Actual, month one 57p

After tool-output truncation 38p

After state summarisation and caps 24p

After routing simple steps 14p

Steady state with all controls 11p

Governance: deciding who owns the number

Controls without an owner decay. The governance layer is what keeps the caps current as prompts, tools and models change underneath them, and it is deliberately lightweight.

One named owner per agent

Each agent should have a single accountable owner who holds its budget, its cost per run target and its kill switch. Shared ownership reliably produces an unowned AI agent cost overrun, because everybody assumes the alert belongs to somebody else. The owner does not need to be an engineer; they need the authority to switch it off.

Change control on prompts and tools

Prompts and tool definitions are production configuration with a direct price attached. They belong in version control, in the same review as code, with the cost regression suite attached to the pull request. A one-line prompt addition that costs six per cent more per run is a small AI agent cost overrun worth seeing before it ships, and the practices in our AI agent operating model guide describe how to keep that lightweight.

A monthly review that changes something

Review cost per run and its trend, the capped-run share, the top three agents by spend, and any incident since the last meeting. The rule that keeps it useful is that every session must produce a decision: a cap raised, a route changed, an agent retired. Reviews that only note numbers stop being attended within a quarter.

Where this sits alongside risk and security

Cost is a risk register entry, not a separate discipline. A runaway agent is an availability and financial risk with the same root cause as many safety issues, which is why the same IT governance forum should see both. Treating a serious AI agent cost overrun as an incident with a written review is what stops it recurring, exactly as covered in our guide to building an AI incident response plan.

Common mistakes that keep AI agent cost overruns alive

These five errors appear in almost every programme that has already tried to fix its spend and found the problem returning.

Treating the vendor dashboard as a control

A provider console reports what you spent yesterday, in aggregate, across all workloads. That is accounting, not control. It cannot stop a run, cannot attribute cost to an agent, and cannot alert per run, so relying on it means every AI agent cost overrun is discovered after it completes.

Capping tokens but not steps

A per-call token limit feels like a budget and is not one, because an agent under a token cap simply takes more steps. A token cap on its own has never prevented an AI agent cost overrun. Caps only bind when they apply to the run as a whole, which is why the step limit and the cost ceiling matter more than any per-call setting.

Optimising the prompt before fixing the loop

Teams reliably start with prompt compression because it is visible and satisfying. Trimming two hundred tokens from a prompt that runs eighty times in an unbounded loop achieves nothing. Fix the control flow first, then the context, then the wording, in that order.

Assuming a smaller model is always cheaper

A weaker model that needs three attempts and produces longer output can cost more than one capable call, and it degrades quality at the same time. Measure cost per successfully completed run, not cost per call, or routing decisions will keep producing an AI agent cost overrun that looks like a saving.

Skipping the cost incident review

An AI agent cost overrun that gets paid and forgotten will return, because the condition that caused it is still in the code. Thirty minutes of written review naming the mechanism, the control that was missing and the owner is the cheapest insurance available against a repeat.

Frequently asked questions about AI agent cost overruns

What is a realistic contingency for a first agent deployment?

Budget the modelled expected case and hold a contingency of fifty to one hundred per cent for the first quarter, then reduce it as measurement replaces assumption. The larger figure is not pessimism; run-length distributions in production are consistently wider than any sample used at design time.

Should the cost ceiling stop a run or downgrade it?

Stop it, and log it. A downgrade path sounds gentler but hides the signal, and the capped-run share is the metric that gives you the earliest warning. Users tolerate a clear message far better than a silently degraded answer.

How do we stop an AI agent cost overrun without blocking legitimate work?

Set caps from measured percentiles rather than round numbers, and treat every breach as a defect to investigate rather than a limit to raise. If genuine work is being blocked, the data will show it within days and the cap can move deliberately.

Do we need a gateway to enforce these controls?

A shared gateway makes budgets, tagging, routing and kill switches consistent, and is worth building once you run more than two or three agents. Below that, enforcing the same controls in each application is acceptable, provided the tags and the caps match.

Who should be paged when spend spikes?

The named agent owner first, with the platform team as the escalation path. Paging finance produces a question; paging the owner produces a stopped agent, which is the only response that limits an AI agent cost overrun while it is happening.