We could track every model call and still couldn't price one useful agent result

I have been working through cost tracking for TokenAir. The first version of the problem looked simple: collect token usage, attach a price, and compare models.

That gives you a clean provider report. It does not tell you what one useful job cost.

Take a refund agent as a simple example. One request can trigger a policy search, a billing call, two model attempts, a fallback, and ten minutes of review. The provider bill splits that work into separate charges. The support team sees one request, and may still reject the result.

The part I had missed was the acceptance decision. A run can finish without producing something the owner will use. If I count completed API calls, the failed draft looks productive. If I only count the final call, the retries disappear from the economics.

The smallest cost record that now makes sense to me has one parent run for the requested job. Every model call, tool call, retry, fallback, and review step becomes a child event. The parent closes as accepted, rejected, abandoned, or pending review.

The model comparison got messier too. The route I expected to be cheapest can lose its advantage after repairs. I do not think one metric settles every routing decision, but cost per accepted outcome is a better place to start than price per token.

I am still unsure how teams handle outcomes that arrive late. A support reply may look acceptable today and reopen the ticket tomorrow. A coding patch can pass review and fail after deployment. I would like to hear where other founders draw that boundary.

I wrote the technical version, including the event fields and sources, here:
https://tokenair.ai/blog/ai-agent-cost-tracking?utm_source=indie_hackers&utm_medium=community&utm_campaign=agent_cost_tracking