AI Agent Cost Black Hole: One-Third of Calls Go to Crash Recovery, Yet No Dashboard Tracks It

A developer running a phone Agent inside a Linux container has revealed an industry blind spot using his own real data: one-third of all AI Agent message calls are spent on crash recovery, and every mainstream cost tool on the market turns a blind eye to it.

The Metric Named by Standards Bodies, Yet Skipped by Every Dashboard

In the AI tool cost guidance published by the FinOps Foundation, a key metric is explicitly called out: developers should force attention onto cost per use case (not total spend), Token consumption breakdowns, GPU utilization, and error and retry rates.

Cost per use case—not per request, not per thousand Tokens, but cost per result produced.

The problem is that almost every cost tool counts Tokens, because that's the number a machine can see directly. But "result produced" is invisible: judging whether a research task truly succeeded requires human judgment, and nobody wants to write that function deciding "done."

So the metric that standards bodies consider central gets skipped by every dashboard on the market. Not because it's technically impossible, but because it's the only number in the entire stack that requires someone to admit "which runs produced nothing at all."

The FinOps Foundation is a non-profit under the Linux Foundation dedicated to developing industry standards and best practices for cloud and emerging-technology cost management. Its guidance such as FinOps for AI has been widely adopted by enterprises as a cost governance framework. The core idea of FinOps is breaking down barriers between finance, engineering, and business so that cost data is attributable and accountable. In AI scenarios, it particularly emphasizes "unit economics"—binding costs to business outcomes rather than merely counting infrastructure consumption. This is why the guidance lists "cost per use case" as the top metric: it asks teams to answer "how much does it cost to generate one report," not "how many Tokens did we burn this month." This shift looks minor, but it actually pulls cost governance from the infrastructure layer up to the product and business layer—and it's the institutional backdrop for the "skipped denominator" discussed in this article.

164 Messages vs. 18 Messages: The Truth Hidden by the Tail

Over 56 days and 64 sessions, the developer recorded every message of his Agent—19,090 message fragments in total, all stored in a single SQLite file. His median session was 18 messages, while the largest session had 1,327—a classic heavy-tailed distribution.

What genuinely surprised him was that after classifying sessions by their actual purpose:

• Crash-recovery sessions: 10 sessions, 1,636 messages total
• "Publication" sessions that actually produced content: 3 sessions, 536 messages total

The average crash-recovery session length was 164 messages, an order of magnitude above the median of 18. This means that even if the classification has a small margin of error, the ratio won't shift much. In the end, one-third of all messages went to recovering from failures.

One important limitation is worth noting: these classifications come from title keyword matching, and the titles were written by the developer himself in a selection menu—not system fields. But the tail data is solid enough—11% of "publication" sessions produced 24 articles, while the rest of the spend bought a system that could keep running.

A heavy-tailed distribution is a statistical concept referring to a probability distribution whose tail decays much more slowly than a normal distribution, meaning extreme values occur far more often than intuition suggests. In the Agent scenario, the median session has only 18 messages, but the maximum reaches 1,327—a gap of more than two orders of magnitude. The danger of such a distribution is that the average gets significantly pulled up by a few extremely long sessions, and cost estimates based on averages systematically underestimate real spend. More critically, the tail of a heavy-tailed distribution is often dominated by failures and retries rather than normal output, so teams that "budget using the average" typically miscalculate both the total and the cost structure. Recognizing heavy tails is a prerequisite for reporting costs using quantiles (such as P50, P95, P99) rather than means—and it's the statistical root of this article's diagnosis that teams "can state their monthly bill but can't see the distribution."

Why Cost Tools Will Never Tell You This

The author has a spend dashboard that accurately shows: 63% of the context is bash output, and a single web search consumes 27,000 characters. These numbers genuinely changed his writing strategy.

But it never showed that one-third of the spend was used to buy back his own mistakes.

This isn't a problem with the tool—a crashed session also produces Tokens, and Tokens are precisely what the tool counts. Wasted work leaves no debit record; what it leaves is a blank.

This is the crux of the problem: cost accounting can only see what happened, while most of an Agent's spend goes to what didn't happen. The FinOps guidance also notes that observability tools are "often the last to get budget," and that budget controls and iteration limits are "not optional safeguards."

Observability refers to the ability to infer a system's internal state from the outside through logs, metrics, and tracing. In AI Agents, observability typically covers three dimensions: model calls (Tokens, latency, error codes), tool execution (network requests, file operations), and orchestration logic (retries, branches, termination conditions). Yet traditional observability tools focus on "is the system healthy" rather than "did this run produce value." The difference between the two creates the blind spot this article points out—crashed sessions look completely normal on the metrics (Tokens consumed, calls returned, errors masked by retries), yet not a single metric records that it "produced nothing." The FinOps guidance specifically notes that observability tools are "often the last to get budget" precisely because their returns are indirect and defensive, hard to quantify in quarterly reports—so the cost black hole keeps getting deferred.

Three Signals to Tell If You're Also in an "Uncounted" State

If any of the following applies to you, you have a "cost per output" problem—regardless of whether you've ever used that term:

You can state your monthly bill, but not your most expensive week. Everyone reports totals, but almost nobody looks at the distribution—and the distribution is where the story is. A month with a run that costs eight times the normal amount, and a month where every run stays steadily in the middle, are two entirely different months, yet the invoice looks the same.

Nobody on the team can say which task is most expensive. Spend that can't be attributed to specific work produces no accountability mechanism. This is the most common failure mode: the dashboard exists, the numbers are right, but the numbers point to no one's decision.

The most expensive run is the one you remember least. You remember the successful publication, but not the four attempts before it, the two dead branches, the retry that doubled the context. Memory is shaped by outcomes—so the cost of abandoned paths disappears from your perception of the workload.

How to Build That Skipped Denominator

This metric can't be bought—you have to define "done" yourself. The author's advice is to start with a small slice rather than everything:

1. Name the output in a machine-verifiable form. Not "good research," but "a file exists at this path containing the query that generated that number."
2. Count both halves. Spend is the easy numerator, and run count is the easy denominator. The output result is the only genuinely difficult number here—and the one everyone skips.
3. Let the ratio hurt. If you ran 200 times and published 4 results, your cost per output is fifty times the cost per run. That's not a measurement defect; that's the measurement result—and the number the next architecture discussion should revolve around.

People will question step one, always with the reasoning that it "feels like over-engineering" and that "a wrong heuristic is worse than no heuristic." Both points are correct, so the first slice should be small enough for a human to verify manually. Verify 20 yourself, and you'll know whether your definition of "done" can withstand reality—then automate.

The author's own experience: the iteration speed of defining "done" far exceeded expectations. He initially defined it as "published an article," and within four days made three misjudgments, because it counted corrections as wins. Adding "and no one found an error afterward" made the criterion stricter and more accurate. A denominator that needs tuning isn't a weakness in measurement—it's a signal that measurement has started working.

Unresolved Questions

The author admits this isn't a complete solution. He can locate the crash-recovery slice, but still can't put a dollar figure on it—because he's on a subscription rather than paying per Token. The next step is to price runs and see whether one-third of messages also corresponds to one-third of spend.

Tools excel at the easy half to count, yet stay silent on the expensive half. This is a problem worth every team running Agents facing seriously.

One-line Summary

Real-world data shows one-third of AI Agent message calls go to crash recovery, while mainstream cost tools ignore it entirely.

Paragraph Summary

Based on real records spanning 56 days, 64 sessions, and 19,090 messages, the author found that crash-recovery sessions averaged 164 messages—an order of magnitude above the median of 18—accounting for roughly one-third of all messages, while sessions that actually produced content totaled only 536 messages. The root cause: the FinOps Foundation lists "cost per use case" as a key metric, but judging whether a run is "done" requires human judgment, so all cost tools count only the directly observable Token number, skipping this denominator. Wasted work leaves no debit record—just a blank. The author therefore proposes a path to building "cost per output": start from a small, manually verifiable slice, define "done" in a machine-verifiable form, count both spend and output, and accept the stinging ratio that results.