33% of my agent's messages went to recovering from crashes, and no dashboard counts it

The number I'm about to give you is unusual for my setup, and I want that caveat first. I run an agent on a phone inside a Linux container, which is a bad way to run an agent and produces failures no ordinary deployment would ever see.

The general problem underneath it isn't unusual at all. It's the part nobody has built a tool for.

The FinOps Foundation published a guide on AI tooling costs, last updated April 2026, and it names the metric that matters:

"The key metrics to insist on having visibility into are: cost per use case (not just total spend), token consumption breakdown, GPU utilization, and error rates and retry rates (repeated calls due to errors are pure waste)."

Cost per use case. Not per request. Not per thousand tokens. Not per team. Per outcome.

Every cost tool I've ever used counts tokens, and there's a reason that number is so easy to get: a machine can see it. Outcomes aren't visible to a machine. Naming "done" is a judgement call, and nobody wants to write the function that decides whether a research task actually succeeded.

So the metric the standards body names as the real one gets skipped by every dashboard on the market. Not because it's technically hard. Because it's the only number in the stack that requires someone to admit which runs produced nothing.

What my own numbers look like

I can measure every tool call my agent makes. They all sit in a SQLite file, one row per message, 19,090 parts across 64 sessions and 56 days. Four lines of SQL gets you the shape:

SELECT s.title,
       COUNT(m.id) AS messages
FROM session s
LEFT JOIN message m ON m.session_id = s.id
GROUP BY s.id
ORDER BY messages DESC;

Run that against your own agent and you'll see what I see. Heavy tail. A handful of sessions hold a third of everything. My median session is 18 messages, and my largest is 1,327.

Then I did the thing nobody warns you about, which is read the titles and sort them by what the session was actually for. Crash recovery came to 1,636 messages across 10 sessions. Ship work, meaning the sessions that actually wrote and published posts, came to 536 across 3.

A third of every message this project has spent went to recovering from failures.

Now the caveat.

Those categories come from session titles, and I wrote those titles myself in a picker menu. No system field anywhere says "this session was for recovery." I classified 64 strings by keyword and then read them back.

What survives that weakness is the tail. The crash-recovery sessions aren't marginally longer. They average 164 messages against a median of 18, an order of magnitude. Mislabel a few and the ratio wobbles slightly. It doesn't move much.

Twenty-four posts came out of the 11% I labelled ship work. The rest bought me a system that stayed up.

The tool was never going to show me this

This is the part that took me a while to actually see.

I have a spend dashboard. It told me, accurately, that my context was 63% bash output and that a single web search cost 27,000 characters. Those numbers moved me. They changed what I wrote next.

It never once showed me that a third of my spend was buying back my own mistakes. Not because the tool is bad. Because a crashed session still produces tokens, and tokens are the thing the tool counts. Work that got undone doesn't leave a debit behind. It leaves an absence.

That's the whole problem in one line: cost accounting can only see what happened, and most of what an agent spends goes on what didn't.

The same source says observability tooling is "frequently the last one funded," and that budget controls and iteration limits "are not optional safeguards." Both describe a team that can read the bill perfectly well and still can't tell you what the bill bought.

Three ways it looks when nobody is counting

If the framing is any use to you, it shouldn't require running infrastructure on a phone. These three checks work on any agent setup, and none of them need a new tool.

You can name your monthly bill but not your most expensive week. Everyone reports the total. Almost nobody has looked at the distribution, and the distribution is where the story lives. A month where one run cost eight times the median is a very different month from one where every run cost the median, and the invoice treats them identically.

No one on the team can say which task is expensive. Spend that can't be attributed to work doesn't create accountability, because there's nothing for anyone to own. This is the boring failure and it's extremely common. The dashboard exists, the number is right, and the number doesn't point at anything a person decided to do.

Your most expensive run was your least memorable one. You remember the thing that shipped. You don't remember the four attempts before it, the two dead branches, the retry that doubled the context. Memory is shaped by outcomes, so the cost of the path you abandoned disappears from your sense of what the work involved.

If one of those three is true of your setup, you have a cost-per-outcome problem whether or not anyone has used that phrase.

How to build the denominator

You can't buy this one. You have to decide it's worth measuring, which means writing down what "finished" means for one small slice of your agent's work. Not all of it. One slice.

Then three steps:

1. Name the outcome so a machine could check it. Not "good research." "A file exists at this path, containing the query that produced this number."
2. Count both halves. Spend is the easy numerator. Runs is the easy denominator. Outcomes are the only genuinely hard number here, and it's the one everybody skips.
3. Let the ratio embarrass you. If you ran 200 times and shipped 4, your cost per outcome is fifty times your cost per run. That isn't a flaw in the measurement. That is the measurement, and it's the figure your next architecture conversation should be built around.

People argue with step one, and the argument is always the same. It feels like over-engineering, and a wrong heuristic is worse than no heuristic.

Both are true, which is why the first slice should be small enough that a human can check the verdict by hand. Verify twenty of them yourself and you'll know whether your definition of done survives contact with reality. Only then automate it.

The bit that surprised me is how fast the definition improves. Mine started as "published a post," which was wrong three times in four days because it scored corrections as wins. Adding "and nobody found an error in it afterwards" made it harsher and far more accurate. A denominator you tune isn't a measurement weakness. It's the measurement starting to work.

Where this leaves me

I'm not going to pretend this solves it. I can name the recovery slice now, and I still can't put a dollar figure on it, because I don't pay per token. I have a subscription. The next honest step is to price the runs and find out whether a third of my messages is also a third of my money.

But the shape is visible, and the shape is the useful part. The tools are excellent at the half that's easy to count and stay quiet about the half that's expensive.

If you'd rather have these posts arrive in your inbox than wait for a feed to surface them, there's a subscribe link at the bottom of this one. I write about agent cost and reliability most days.

What's the largest share of your agent's spend that nothing in your current stack would show you?