Cost anomaly detection for an AI agent means watching a handful of spend signals, cost per task, tokens per run, tool calls per run, and daily burn, and raising an alert the moment one of them breaks out of its normal range. Done well, it catches a runaway agent within minutes. Done poorly, or not at all, the first sign of trouble is a bill at the end of the month that is several times what the work was worth. The difference is whether you are watching the shape of spend over time or only the final total.
This matters more for agents than for ordinary software because an agent controls its own workload. A traditional service does a fixed amount of work per request, so its cost is predictable. An agent decides how many steps to take, and a bug can make it decide to take thousands. With token-based pricing, where cost scales directly with calls and tokens, that decision turns straight into money. A cost ceiling, covered in agent cost control, bounds the worst case; anomaly detection is what tells you the worst case is happening while there is still time to stop it.
What a cost anomaly looks like
An anomaly is not just high spend. It is spend behaving differently from how it normally behaves. A busy day with twice the usual traffic might cost twice as much and be entirely healthy. An anomaly is when the relationship breaks: the same number of tasks suddenly costs three times as much, or one task that always cost a cent starts costing a dollar, or spend keeps climbing after the workload that drives it has gone home.
That distinction is the whole game. If you alert on absolute spend alone, you drown in false alarms every time legitimate volume rises and you miss the quiet anomalies that hide under the ceiling. The useful detector watches ratios and rates, cost per unit of work and how fast spend is changing, so it can tell the difference between "busy" and "broken." Building that view is part of the same instrumentation that powers monitoring and observability, with cost treated as a first-class signal alongside latency and errors.
Why agents produce spend spikes
Knowing the common causes tells you what your signals need to catch. Agent cost spikes cluster into a few recognizable patterns.
- The retry storm. A tool keeps failing and the agent keeps retrying. Each attempt costs a call, and without a retry cap the loop can fire hundreds of times. This is why rate limiting your agent and cost detection are close cousins: the cap slows the storm, the detector tells you it happened.
- The planning loop. An agent that re-plans instead of acting can circle indefinitely, each loop spending tokens to reconsider the same problem. The task never completes and the cost never stops.
- Context bloat. An agent that accumulates history can let its context grow until every single call is large and expensive. Cost per run creeps up even though the number of runs is unchanged, the kind of quiet cost covered in hidden agent costs.
- The misfiring schedule. A trigger configured to run hourly that fires every minute, or a webhook that double-delivers, multiplies the number of runs without anyone intending it. Total spend climbs while each run looks normal.
The pattern across all four is that none of them announces itself. The agent does not error out; it works, just far more than it should. That is exactly why you need a detector watching the shape of spend, because nothing else in the system is going to complain.
The signals worth watching
You do not need a large metrics catalog. Four signals cover the great majority of cost anomalies, and watching them together tells you not just that cost moved but why.
- Cost per task. The most sensitive early signal. It isolates the cost of a single run from how many runs you did, so it spikes the instant individual tasks get more expensive, well before the daily total reacts.
- Tokens per run. When cost per task rises, tokens per run tells you whether the cause is context growth. A steady climb here points to bloat; a sudden jump points to oversized inputs.
- Tool calls per run. The signature of a loop or a retry storm. A run that normally makes five calls suddenly making fifty is the clearest fingerprint of a runaway loop.
- Daily burn rate. The backstop that catches what per-run signals miss, like a misfiring schedule that keeps each run cheap but multiplies their number. Plotted across the day, a creeping burn is visible long before it reaches any ceiling.
The reason to watch all four rather than just total spend is diagnosis. Total spend tells you something is wrong; the per-run signals tell you which failure mode you are in, which is the difference between an alert you can act on in a minute and one that sends you hunting through logs. Attributing the spend to a specific agent, task type, or tenant, the subject of agent cost attribution, narrows it further.
Static thresholds vs dynamic baselines
There are two ways to decide that a number is anomalous, and a good setup uses both because each covers the other's blind spot.
A static threshold is a fixed line: alert if daily spend passes a set amount, or if cost per task exceeds a set figure. Its virtue is simplicity and predictability. You know exactly when it fires and it needs no history. Its weakness is that it is blind to anything under the line, so a spike that doubles your cost while staying below the ceiling sails through, and it cries wolf whenever legitimate volume rises to meet the fixed number.
A dynamic baseline learns the agent's normal range from its recent history, the typical cost per task for this hour and day, and alerts when the current value departs from that range by more than expected variation. It catches the subtle anomalies a static line misses and adapts as normal usage grows, so it does not nag. Its weakness is that it needs enough history to know what normal is, and a baseline trained on already-broken behavior learns the wrong normal.
The reliable arrangement layers them. The static ceiling is the backstop that guarantees a hard stop no matter what, and it doubles as the budget. The dynamic baseline is the early-warning system that catches the quiet spikes the ceiling never sees. A rate-of-change check sits usefully alongside both: alert when spend accelerates sharply, because a sudden steepening of the curve is often the earliest visible sign of a loop, ahead of any absolute number.
From alert to action
An alert that no one can act on is noise with a timestamp. The value of cost anomaly detection is realized only if the alert leads to a fast, specific response, which means designing the alert and the response together.
Make the alert diagnostic. It should arrive carrying the context that turns it into an action: which agent, which task type, which signal moved, and by how much against its baseline. "Spend is high" forces an investigation. "Agent X cost per task is four times baseline, driven by tool calls per run jumping from five to sixty" points straight at a retry loop and a fix.
Wire the alert to a control. The fastest response to a confirmed runaway is not a human reading a dashboard but an automatic cap that the alert can trigger: pause the offending agent, or throttle it hard, while a person investigates. This is the cost equivalent of a kill switch, and it belongs to the same family of controls as agent safety and guardrails. When a cost anomaly turns out to be a genuine incident rather than a blip, the structured response in agent incident response keeps the cleanup orderly.
Finally, tune the threshold from the misses and the false alarms. Every alert that fired on nothing argues for a looser baseline; every spike that slipped through argues for a tighter one. The detector is never finished, because the agent and its workload keep changing, and a detector you stop tuning slowly drifts into either silence or noise.
Anomaly detection vs budgets vs attribution
Three cost practices get blurred together, and separating them clarifies what each is for.
A budget is a ceiling. It bounds the absolute worst case by stopping work when total spend reaches a fixed limit. It is essential, but it is a blunt, late instrument: it only acts once a lot of money is already spent, and it says nothing about whether spending is healthy below the line.
Anomaly detection watches the shape of spend and alerts on unusual change, often long before any ceiling is near. It answers "is spending behaving strangely right now," which the budget cannot.
Cost attribution answers "where is the money going," breaking spend down by agent, task, or tenant. It does not detect or stop anything; it is what makes an anomaly actionable by pointing at the source. The three work as a stack: attribution shows where, detection shows when something is off, and the budget guarantees a floor under the worst case. Skipping detection leaves a gap exactly where it hurts, the window between "spending started going wrong" and "the budget finally stopped it."
How Gravity handles cost
Gravity is an AI agent platform, and the cost-control machinery this article describes is built into how the platform runs agents rather than left to each user to assemble. The agents are expert-built and run with pacing and recovery in place, so the retry storms and planning loops that drive cost spikes are bounded by the runtime instead of by a detector you have to wire up.
The pricing model also removes much of the anomaly surface by design. You pay per use: $1 equals 1,000 credits, and you are billed only when an agent actually runs. There is no always-on meter to spike, no idle drain, and consumption maps directly to work delivered, so the gap between "what the task was worth" and "what it cost" stays small. The daily-burn worry that you would otherwise watch yourself is handled by metering that bills for completed work.
For the user, that means you describe what you need in plain words and an expert-built agent returns the result in about 60 seconds, while the cost monitoring, the signals, baselines, and caps, lives inside the platform. To understand the underlying ideas first, what is an AI agent sets the foundation and the glossary defines the terms used here.
FAQ
What is cost anomaly detection for an AI agent?
Cost anomaly detection for an AI agent is the practice of watching the agent's spend signals, cost per task, tokens per run, calls per run, and daily burn, and alerting when one of them departs sharply from its normal range. The goal is to catch a spend spike within minutes rather than at the end of a billing cycle, so you can stop a runaway loop or a misconfigured task before it becomes an expensive surprise.
Why do AI agents produce sudden cost spikes?
Because an agent decides its own next step, a single fault can multiply work. A retry that never succeeds, a planning loop that keeps re-planning, an oversized context that inflates every call, or a schedule that fires far more often than intended can each turn a steady cost into a spike. Token-based pricing means cost scales directly with calls and tokens, so more steps means more spend, and the agent will not stop on its own unless something caps it.
Should I use a static threshold or a dynamic baseline?
Use both. A static threshold, a hard ceiling on daily spend or cost per task, is simple and catches the worst case, but it misses a spike that stays under the cap and fires false alarms when normal volume rises. A dynamic baseline learns the agent's typical range and alerts on departures from it, catching subtler anomalies, but needs history to be reliable. Run a static ceiling as the backstop and a baseline alert as the early signal.
What is the best early signal of an agent cost problem?
Cost per task is usually the most sensitive early signal. Total daily spend can look normal while individual runs quietly get more expensive, and cost per task exposes that before the daily total catches up. Watching tokens per run and tool calls per run alongside it tells you why the cost moved: more tokens points to context growth, more calls points to a loop or retry storm.
How is cost anomaly detection different from a budget?
A budget is a ceiling that stops work when total spend reaches a fixed limit. Anomaly detection watches the shape of spend over time and alerts on unusual changes, even when the total is far from any ceiling. A budget answers have we spent too much in absolute terms; anomaly detection answers is spending behaving strangely right now. They are complementary: the budget bounds the worst case, the detector catches the problem early.