AI Agent Cost Monitoring

AI agent cost monitoring is the continuous measurement of what your agents spend — per call, per run, per config version — with detection when spend diverges from its baseline. It is not cloud cost management. Cloud FinOps watches infrastructure bills; agent cost monitoring watches the call path: tokens, cache economics, tool results, loops. The bill is where you find out last. The call path is where the money actually moves.

This page defines the discipline, the metric set, and the failure mode most teams meet first: agent cost drift.

Why agents need their own cost discipline

Quality got a discipline. Teams write evals, run them in CI, monitor for regressions, and re-tune. Cost never got the same treatment — most teams discover cost problems from the invoice, reactively, the way teams discovered quality problems from angry users before evals existed.

Agent cost has three properties that make “check the bill monthly” fail:

It’s objective but composite. A run’s cost is tokens × price, but the tokens come from moving parts that interact: prompt prefix, cache reads vs writes, tool-result bytes re-sent every turn, loop length. A 10% change in one part can move the total 2×.
It drifts silently. A quality regression usually shows up fast — bad output, user complaint. A cost regression is invisible for weeks. A prompt tweak that breaks the cache doesn’t error. A model swap that doubles spend doesn’t warn. Context bloat creeps a few KB per week. Nothing fails; the invoice just grows.
Nobody is watching the expensive ones. The agents that spend the most are increasingly autonomous — scheduled jobs, background loops, coding agents on long leashes. There is no human in the session to notice it re-reading a 180KB file forty times. For unattended agents, the alert is not a convenience. It is the only safety net.

Agent cost drift, defined

Agent cost drift is a sustained divergence between an agent’s cost-per-run and its own established baseline — caused either by a configuration change (a deploy made it more expensive) or by traffic change (the work got heavier while the config stayed the same).

The two flavors matter because they have different fixes:

Config-change drift. The agent’s configuration — system prompt, tool set, model — changed, and cost-per-run rose against the previous version. Common causes: a prompt edit that invalidated the provider’s prefix cache (cache reads bill at roughly a tenth of full input price; losing that discount on every turn can double a bill on its own), a tool added mid-stream, a model swap. The fix is comparing versions: since config v2, cost per run rose 2.4× — here’s the diff. This requires fingerprinting the config so every run is stamped with the version that produced it. Without the fingerprint, you can see cost rose but never when it started or what changed.

Same-config drift. The config didn’t change; the traffic did. Inputs grew, tool results got fatter, loops run longer. The fix is different — cap the tool output, compact the history, add a loop guard — and the signal that distinguishes it from config drift is precisely that the config fingerprint is stable while cost rises.

The industry data says drift is the norm, not the exception: Datadog reports token use per request doubled year-over-year at the median and quadrupled at p90 — and notes that spikes usually signal bugs (loops, misfiring retrieval, maxed context), not demand. A cost spike is a behavior alert wearing a billing costume.

The cost lifecycle

The workflow mirrors evals, with the weight in a different place:

Baseline. When an agent ships, record its config fingerprint and its cost-per-run distribution. This is cheap — no datasets, no judges. Cost needs no labeling ceremony, which is why the dev-time phase is light.
Monitor continuously. Meter every model and tool call in the path — tokens split into fresh, cache-read, and cache-write; tool-result bytes; loop vs leaf calls; context composition. Averages hide everything; per-run and per-config resolution is the point.
Detect drift. Compare recent runs against the per-config baseline. Alert on sustained divergence — conservatively, so that when the alert fires it’s real. Route it somewhere a human actually looks (for us: the daily digest email), because the whole premise is that nobody is watching the dashboard.
Reoptimize. The catalog of fixes is well documented across the industry: stabilize the prompt prefix, cap and paginate tool results, compact history, route cheap-shaped calls to cheap models, batch the latency-tolerant work. The monitoring data tells you which fix applies — a low cache-hit rate with a churning prefix is a different problem than a fat tool result re-read every turn.
Verify. The receipt: since the fix, cost-per-run moved from X to Y at the same quality. Config fingerprints make this a comparison, not a vibe.

One coupling to respect: cost and quality trade off. The cheapest config can tank quality, so the real objective is cost per quality point — which is why this lifecycle should ingest whatever quality signal you already have (evals, user feedback) rather than optimize cost blind.

The metric set

Cost per run, per config version — the drift detector’s raw material.
Cache-hit rate — cache-read tokens ÷ total input tokens. Define it carefully: counting cache writes as hits overstates it, and double-counting cached tokens in the denominator understates it (we’ve made that mistake ourselves; a real 96% rate reported as 50% sent us chasing a problem that didn’t exist).
Context composition — what share of input is system prompt vs history vs tool results. Tool results past ~a third of composition usually means an uncapped tool.
Loop share — orchestration re-reads vs leaf work. The loop re-pays the whole history every turn; one early fat result compounds across every turn after it.
Spend rate vs budget — the hard backstop, per agent identity, with warn-then-stop semantics so a runaway loop is a bounded incident, not a $2,000 morning.

How ACP does this

Agentic Control Plane sits in the agent’s call path — governing tool calls and proxying model calls — so the metering is a property of the position, not an SDK you instrument. What that position yields for cost:

Config fingerprints on every run: the prompt prefix, tool set, and model are hashed at call time, so every run knows which config produced it — and prefix churn, the classic cache-killer, is detected directly.
Drift detection, both flavors: per-config baselines with config-change comparison (“since scout changed config v1→v2, cost per run rose 2.4×”), delivered in the daily digest — the alert reaches you; you don’t have to go looking.
Pattern suggestions with evidence: when the data shows a known cost pattern applies — an uncapped tool result, compaction-worthy context growth — the finding arrives as one line with the numbers inline, tailored to the harness you run (an agent whose harness already compacts natively gets different advice than a raw SDK loop).
Budgets that end runs safely: per-identity caps with warn-then-stop, plus tools agents can call to check their own budget and pace themselves.
The same plane controls the agent — cost monitoring and action governance share one identity, one policy, one audit trail. A cost spike that turns out to be a misbehaving loop is one click from the policy that stops it.

Free for individuals — sixty seconds to first data. If you run agents nobody watches, that’s the case it was built for.

FAQ

What’s the difference between AI agent cost monitoring and LLM cost tracking? Tracking reports what you spent, usually per request. Monitoring compares spend against a baseline over time and alerts on divergence. A token counter can’t tell you your Tuesday deploy raised cost-per-task 40% — that requires per-run metering keyed to config versions.

What causes AI agent cost drift? Most commonly: prompt or tool changes that invalidate the provider’s prefix cache; model swaps; growing tool-result payloads re-sent every turn; lengthening loops; and retry storms. Roughly split between “the deploy did it” (config drift) and “the traffic did it” (same-config drift).

Do I need this if I set budget caps? Caps bound the damage; they don’t explain it, and they fire after the money is spent. Drift detection tells you what changed and when, usually while the number is still small. Use both.

Does this apply to agents on subscription plans rather than API keys? Yes — token waste consumes subscription quota the same way it consumes API budget, and the drift mechanics (cache breaks, context bloat) are identical. Metering at the call path sees both.