Building a Cost-Anomaly Alerting System for Agent Spend

Table of Contents

• Why Total-Spend Alerts Fail for Agents
• The Signals Worth Watching
• Cost Per Completed Task
• Retries and Fan-Out
• Token Velocity and Run Duration
• Choosing a Detection Method
• Setting Thresholds Without Drowning in Noise
• The Architecture: From Trace to Alert
• Killswitches and Automated Response
• A Minimal Build You Can Ship This Week
• Insights Most People Overlook
• References

Why Total-Spend Alerts Fail for Agents

Most teams start the same way. They wire a daily spend alert to the model provider's billing dashboard, set it at some round number, "tell me if we cross $500 a day", and call it done. Then they get burned anyway.

The problem is that a total-spend threshold conflates two completely different events. Spend can rise because the business is healthy and you're running more tasks. Spend can also rise because each task is suddenly costing three times what it should. The first is good news. The second is a fire. A flat dollar threshold can't tell them apart, so it either fires constantly during normal growth (and you mute it) or it's set so high that the actual fire is already raging by the time it trips.

This is the same reasoning behind why GaaS needs a per-task unit metric in the first place rather than borrowing SaaS's recurring-revenue framing. If you're charging and reasoning per completed task, your monitoring has to live at that grain too. An anomaly is best defined as a change in cost per unit of work, not a change in the bill.

There's a second failure mode that's sneakier. Provider billing data is delayed, often hours, sometimes a full day, and it's aggregated. By the time a runaway loop shows up on the invoice, it has been burning for hours. For agents that can recursively call tools and spawn sub-agents, hours is enough to turn a rounding error into a five-figure surprise. You need detection that runs on your own telemetry, in near-real-time, upstream of the invoice.

The Signals Worth Watching

A good alerting system tracks a small set of ratios, not a pile of raw counters. Ratios normalize for volume automatically, which is exactly what total-spend alerts fail to do.

Cost Per Completed Task

This is the anchor metric. Sum the model, tool, and infrastructure cost attributable to a task, divide by completed tasks, and track the distribution over time. Note the word completed, dividing by attempted tasks hides the worst failures, because a task that burned $4 in retries and then errored out still cost you $4 but produced nothing.

Watch the shape of the distribution, not just the mean. Agent cost is heavy-tailed: the median task might be perfectly stable at twelve cents while the 99th percentile quietly creeps from eighty cents to four dollars. A mean-based alert sleeps through that. A p95 or p99 alert catches the exact tasks that are eating your margin. If you're tracking cost-per-completed-task as your core unit already, anomaly detection is mostly a matter of putting a control limit around a number you compute anyway.

Retries and Fan-Out

Retries are where agent bills go to die. One logical task can quietly become fifty model calls when a tool fails intermittently and the agent keeps re-trying, or when a planning loop never converges. The hidden cost of retries is one of the most underappreciated line items in agent economics, and it's also one of the easiest anomalies to detect: track model calls per completed task and alert when it deviates from baseline.

Fan-out is the cousin problem. When agents spawn sub-agents, cost can grow super-linearly, a parent that dispatches five children, each of which dispatches three more, is a branching factor waiting to explode. Instrument the spawn depth and total descendant count per root task. A sudden jump in average fan-out is frequently the leading indicator of a runaway scenario, visible minutes before total spend reacts.

Token Velocity and Run Duration

For long-running agents, wall-clock time and token-burn rate are early-warning signals in their own right. An agent that normally finishes in ninety seconds and is now at eleven minutes is either stuck or looping. You don't need to wait for it to finish and bill you, duration crossing a percentile band is itself an anomaly worth flagging. "Thinking" tokens deserve their own counter here, since extended reasoning can balloon cost without changing the visible output at all, and a regression in a prompt or a model upgrade can silently shift the reasoning-token baseline.

Choosing a Detection Method

You don't need a machine-learning platform to do this well. Match the method to the signal's behavior.

Static thresholds work for hard ceilings you never want crossed, a single task above $10, or a run longer than fifteen minutes. They're cheap, interpretable, and catch catastrophic single events. Their weakness is they don't adapt, so they're poor at catching gradual drift.

Rolling statistical baselines are the workhorse. Compute a trailing mean and standard deviation (or, better, a median and median-absolute-deviation, which the heavy tail doesn't poison), and flag points that sit several deviations out. MAD-based bands are far more robust for cost data than classic three-sigma rules, because a couple of genuinely expensive tasks won't blow out your variance estimate the way they do with standard deviation.

Seasonal / time-of-day models matter if your traffic has rhythm. Cost per task can legitimately differ between a batch overnight job and interactive daytime use. A flat baseline will false-positive every night at 2 a.m. A simple approach, compare each hour to the same hour over the prior couple of weeks, removes most of that noise without any heavy modeling. AWS's writeup on building anomaly detection with CloudWatch is a decent primer on the band-around-expected-value pattern, even though it's aimed at infra metrics rather than agent spend.

Resist the urge to reach for a forecasting model on day one. Most teams over-engineer the detector and under-engineer the attribution, and attribution is where the value is.

Setting Thresholds Without Drowning in Noise

A noisy alerting system gets muted, and a muted system is worse than none because it gives false confidence. Three principles keep signal high.

First, alert on sustained deviation, not single points. A single expensive task is often just a hard task. Require the anomaly to persist across a window, say, three of the last five minutes, or N consecutive tasks above the band, before paging anyone. This single change kills the majority of false positives.

Second, tier your responses. Not every anomaly deserves a 3 a.m. page. A useful ladder: a log event for mild deviation, a Slack notification for sustained moderate deviation, a page for severe or fast-moving anomalies, and an automated killswitch for the genuinely catastrophic. Google's SRE practice on alerting on symptoms with multiple severity levels translates almost directly to agent spend if you treat "burning money abnormally fast" as the symptom.

Third, make every alert attributable. An alert that says "spend is anomalous" is useless at 3 a.m. An alert that says "cost-per-task on the invoice-reconciliation agent for customer Acme jumped from $0.14 to $1.90, driven by a 6x increase in retries on the fetch_pdf tool" tells the on-call engineer exactly what to look at. That requires tagging every trace with agent name, customer, tool, and model before you need it.

The Architecture: From Trace to Alert

The pipeline has four stages, and the first one is the one teams skip and regret.

Instrumentation. Every model call, tool call, and sub-agent spawn emits a structured event: timestamp, agent id, task id, root task id, customer id, model, input/output/reasoning tokens, computed cost, and outcome. This is the foundation. If you can't attribute cost to a customer and a task, you can't do anomaly detection, you can't do cost attribution for shared infrastructure, and you can't compute margins. The emerging standard here is OpenTelemetry's semantic conventions for generative-AI spans, which give you a vendor-neutral schema for exactly these fields, adopt it rather than inventing your own.

Aggregation. Stream those events into a time-series store or a columnar warehouse and roll them up into the per-unit ratios above, bucketed by minute and by dimension (agent, customer, model, tool). This is where cost-per-task and calls-per-task get computed continuously.

Detection. Run your chosen detectors over the rolling aggregates. Keep this stateless and dumb, it reads aggregates, applies bands, emits anomaly events. The intelligence lives in the aggregation grain, not the detector.

Notification and response. Route anomaly events to the tiered channels, enriched with the attribution context so each alert is actionable.

A practical note: do the cost computation at instrumentation time using a pricing table you control, not at billing time. Provider prices change, and you want your own ground truth, particularly for multi-model agents where you're blending rates across vendors and the provider invoice won't break it down the way you need.

Killswitches and Automated Response

Detection without response is just a faster way to watch money burn. For the catastrophic tier, you want the system to act before a human reads the alert.

The cleanest pattern is a per-task and per-customer budget cap enforced at the orchestration layer. Each task carries a budget; every model and tool call decrements it; when it hits zero, the task halts and returns a graceful failure rather than looping forever. This caps worst-case spend deterministically and is far more reliable than any statistical detector for the runaway scenario. Pair it with a circuit breaker at the fleet level: if aggregate cost-per-task across an agent crosses a hard ceiling, pause new task dispatch and alert. It's better to fail a few tasks loudly than to silently torch your gross margin.

There's a real tension here. Killswitches that are too aggressive degrade the product, and customers churn quietly when their agent keeps bailing out. That's the same reason some vendors quietly cap autonomy to protect margin. The right call is usually a generous per-task cap (so legitimate hard tasks complete) combined with a tight anomaly circuit breaker (so a sudden fleet-wide regression gets stopped). Tune the cap for the product; tune the breaker for the bank account.

A Minimal Build You Can Ship This Week

You don't need the full platform to get most of the protection. Here's the eighty-twenty version.

1. Emit one structured log line per task with task id, customer, agent, total model calls, total tokens, computed cost, duration, and outcome. If you only instrument one thing, instrument the per-task summary.
2. Roll it up every five minutes into cost-per-completed-task and calls-per-completed-task, split by agent.
3. Compute a 14-day rolling median and MAD per agent, and flag any five-minute bucket where the metric sits more than, say, five MADs above the median for three consecutive buckets.
4. Add two static killswitches: a per-task budget cap and a per-task duration cap, enforced in the orchestrator.
5. Send flagged anomalies to a Slack channel with the attribution context baked into the message.

That's a weekend of work for a competent engineer, and it catches the overwhelming majority of real incidents: retry storms, fan-out explosions, prompt regressions that balloon token use, and the single runaway task. The fancy seasonal modeling and per-customer breakdowns are refinements you add once the basics are catching real problems. Ship the simple version, watch what it misses, and let the misses tell you what to build next, that's a far better roadmap than guessing at sophistication up front.

Insights Most People Overlook

The denominator is the whole game. Almost every team that gets this wrong divides cost by attempted tasks instead of completed ones. That single choice hides your worst incidents, because failed tasks are exactly the ones that burned money for nothing. Define cost-per-task on completions and your most expensive failures stop being invisible.

Your scariest anomaly is often a drop, not a spike. If cost-per-task suddenly falls, the optimistic read is that you got more efficient. The pessimistic read, usually correct, is that tasks are failing fast and cheap: a tool is returning errors instantly, an auth token expired, the agent is short-circuiting. A cost decrease with a completion-rate decrease is a silent outage. Alert on the ratio in both directions.

Provider-side anomaly detection will never be enough, by design. Cloud and model vendors bill in aggregate and report on a lag because that's what's cheap for them to produce. They have no incentive to give you minute-level, per-task, per-customer granularity, that's your job, and it's also your moat. The vendors arguably benefit from the idle-agent and retry costs they don't surface.

Anomaly detection and cost attribution are the same instrumentation problem. The tags you need to make an alert actionable, customer, agent, tool, model, are the exact tags you need to charge the right customer and compute per-segment margin. Build the telemetry once and you get monitoring, billing accuracy, and unit economics from a single pipeline. Teams that treat these as three separate projects end up instrumenting three times.

The killswitch protects margin better than the detector does. Statistical detection is probabilistic and lagging; a hard per-task budget cap is deterministic and immediate. For bounding worst-case spend, the boring budget cap beats the clever anomaly model every time. Use the detector to learn, but rely on the cap to protect.

References

• Create Amazon CloudWatch anomaly detection alarms, AWS Cloud Operations Blog
• Alerting on SLOs, Google SRE Workbook
• Semantic conventions for generative AI spans, OpenTelemetry