Controlling AI agent costs before they control your bill

The first time an agent runs up a surprise bill, it's rarely a slow drift. It's a loop. An agent decides it hasn't finished, calls itself again, retries a failing tool, expands its context on every turn, and does that a few thousand times before anyone notices. A workflow that costs a fraction of a cent per run becomes a five-figure line item overnight. Chat apps don't do this — a human sends one message and waits. Agents plan, act, and re-plan on their own, which is exactly what makes their cost profile so much harder to predict.

This post is about making agent spend observable and controllable before it shows up on the invoice.

Why agent costs are different

Three properties of agents make naive cost tracking useless:

Non-determinism in step count. The same input can take 3 steps or 30 depending on what the model decides. Your unit cost has a long tail.
Fan-out. Multi-agent systems and parallel tool calls multiply spend in ways that don't show up in a single request/response metric.
Silent retries. Framework-level retries and self-correction loops are often invisible at the application layer but very visible on the bill.

A monthly total from your provider's dashboard tells you that you spent too much, never where or why. You need cost broken down along the same dimensions you debug: per run, per model, per project, per step.

Attribute cost to the span

If every span already records its token usage and model, cost is a deterministic function of that data and a price table. Compute it at ingestion and store it on the span:

{
  "span_id": "01J8...",
  "trace_id": "01J8...",
  "model": "claude-opus-4-8",
  "tokens": { "prompt": 4120, "completion": 380 },
  "cost_usd": 0.0729,
  "project": "support-agent",
  "run": "01J8..."
}

Roll those up and every cost question becomes a group-by:

Per run — the true unit economics of a workflow, tail and all. Sort runs by cost and the runaway loops jump straight to the top.
Per model — where an expensive model is doing work a cheaper one could handle.
Per project / team — chargeback and accountability.
Per step name — which tool or planning step dominates a run.

The single most valuable view is cost distribution per run. The mean lies; the p99 is where your money goes. A workflow averaging $0.01 with a p99 of $4.00 is telling you a small fraction of runs are looping, and those are the runs to go fix.

Budgets and alerts: catch it in hours, not on the invoice

Analytics tell you what happened. Budgets stop it from happening again. Set spend thresholds at the dimension that matters and alert when they're crossed:

budgets:
  - scope: project=support-agent
    limit_usd_per_day: 50
    alert_at: [0.8, 1.0]        # warn at 80%, page at 100%
  - scope: model=claude-opus-4-8
    limit_usd_per_month: 2000
    alert_at: [0.9]

The point of a daily budget is time-to-detection. A monthly limit lets a runaway loop burn for weeks; a daily one catches it the same afternoon. Wire the alert to the same channel as your other on-call signals so cost is a first-class operational metric, not a finance afterthought.

Gate the runaways at the source

Alerts are reactive. For the loop problem specifically, add hard stops in the agent loop itself:

Per-run step and token ceilings. If a run exceeds N steps or M tokens, halt it and mark the trace. Almost no legitimate run needs 200 steps; the ones that do are bugs.
Cost circuit breaker. Track spend within a single run and abort past a per-run cap. A $5 ceiling on a workflow that should cost pennies turns a $10,000 incident into a $5 one.
Model routing. Send cheap, high-volume steps (classification, extraction, routing) to a smaller model and reserve the frontier model for the steps that actually need it. This is usually the single biggest structural saving.

Optimize with the data, not by guessing

Once cost is attributed per span, optimization stops being folklore:

Find the expensive step. Group by step name, sort by total cost. It's often one over-stuffed context or one chatty tool.
Trim context. Agents accumulate history every turn; much of it is dead weight. Measure the token count per turn and cap what you carry forward.
Cache. Repeated system prompts and stable context are prime candidates for prompt caching — often a large discount on the prompt tokens that dominate agent spend.
Downshift models where evaluation shows quality holds. Prove it with your regression suite so you're trading cost for measured quality, not vibes.

Every one of these is measurable before and after, because the cost is on the trace. You ship a change and watch p99 run cost drop — or not — instead of waiting a month to read the invoice.

Cost is an observability signal

The theme across all of this: cost isn't a separate finance concern bolted on at the end. It's a signal that belongs on the same trace as latency, quality, and risk. When it lives there, "why did spend spike on Tuesday?" is a query, not an investigation — filter to Tuesday, sort by run cost, and the looping run is right at the top with its full execution trace attached.

Agents will keep getting more autonomous, which means more steps, more fan-out, and more chances to loop. The teams that stay in control are the ones who made spend visible per run, put budgets on the dimensions that matter, and gated the runaways at the source — before the bill ever arrived.