AI agent unit economics: why cost per successful run is the metric

Total spend hides the truth about an AI agent. The number that does not is cost per successful run, because it counts the retries and loops that burned money for nothing. Here is how to think about agent unit economics.

Matt King
July 21, 2026 6 min read

If you run AI agents in production, someone will eventually ask what they cost to operate, and "the OpenAI bill was $9,000" is not an answer to that question. It is a total with no denominator. The useful version is a unit cost, and for agents the right unit is the successful run. The reason is specific to how agents fail.

Why the average lies

A normal request either works or throws. An agent can do neither: it can retry, loop, partially complete, and produce nothing useful while still spending money on every model call along the way. Average cost over all runs quietly absorbs that waste. Picture an agent where most runs cost two cents, but one run in twenty falls into a retry loop and burns four dollars before giving up. The average looks fine. The truth is that one in twenty of your runs is a small fire, and the average is the thing hiding it.

Cost per successful run does not hide it. Divide total spend by the runs that finished cleanly, and the cost of every loop and failure is folded into the price of the successes they were trying to produce. Now the fire shows up as a number going the wrong way.

The three cuts that matter

Once you price per run, three attributions turn cost into a decision:

  • Per agent. Which agent spends the most, ranked, over any window. This is where you find the one agent quietly costing more than the rest combined.
  • Per customer. Tag the customer at run start and spend attributes retroactively. Now you can tell a cheap account from one you are losing money to serve, which is the difference between pricing that works and pricing that does not.
  • Per feature. See which AI feature has poor margins before you ship it wider. A feature that delights users and loses money on every use is a problem you want to find in the dashboard, not the board deck.

None of these are visible in a provider console, because the console knows API keys, not agents, customers or features.

Priced where it cannot lie

One implementation detail decides whether the numbers are trustworthy: price on the server, not the client. The SDK should send tokens and the model, and the cost should be computed server-side from a maintained rate card, cache aware, so prompt-cache reads are not counted as fresh input. A client-side cost estimate drifts from the invoice the moment a price changes or a cache hit lands. A server-side price, cache aware, lines up with what you actually pay.

What to watch

Three signals, and they compound:

  1. Cost per successful run, per agent, over time. A prompt change that adds tokens shows up as a step change on the day it ships.
  2. Failed and retried run cost. The money spent on runs that produced nothing, surfaced rather than averaged away.
  3. An anomaly alert on the per-agent baseline, so a runaway agent pages you before the invoice does, not after.

Get those three and AI cost stops being a mystery line item and becomes a unit economic you can manage like any other.

AgentPing prices every run server-side, cache aware, and rolls cost up per agent, customer and feature, with cost-per-successful-run as the headline and anomaly alerts on each agent's baseline. See Spend, or get started free.

What is cost per successful run?
Total cost divided by the number of runs that finished cleanly, rather than divided by all runs. It is the unit economics metric for an agent because it folds the cost of retries, loops and failed runs into the price of the successes they were trying to produce. A low average cost with a high failure rate is an expensive agent wearing a cheap number.
How do I attribute AI cost to a customer or feature?
Tag the run with a customer and feature at the start, and price every model call server-side. From then on spend rolls up by customer and feature, so you can see which accounts are expensive to serve and whether a feature pays for itself. Done client-side or after the fact it is guesswork; done per run on the server it matches the invoice.
Why not just read the provider dashboard?
The provider dashboard shows tokens by API key. It cannot tell you which agent, customer, feature or run spent them, and it cannot separate the runs that succeeded from the ones that looped and failed. It is an accurate total attached to none of the questions that decide whether the agent is worth running.
Quality

How to evaluate AI agents in production

Offline evals tell you a model is good on a fixed set. Production tells you whether it is still good on real traffic. Here are the layers of agent evaluation, from deterministic checks to LLM-as-judge, and how to run them without an eval pipeline.

July 16, 2026 · 7 min
 Observability

OpenTelemetry for AI agents: what it gives you, and where it stops

OpenTelemetry can carry your agent telemetry, and the GenAI semantic conventions standardise it. Here is what OTel covers for AI agents, what it deliberately leaves to you, and how to turn traces into operational answers.

July 11, 2026 · 6 min
 Observability

The best AI agent monitoring tools in 2026

A straight comparison of the tools teams use to monitor AI agents in production, what each is built around, and when to reach for which. Covers AgentPing, LangSmith, Helicone, Langfuse, Braintrust and Datadog.

July 7, 2026 · 7 min