Back to the blog

Token cost is the easy half of agent economics

15 August 2026

Nine of my Claude Code sessions cost $0.119264. I can write that to six decimal places because the token counts came out of the API and the per-token rates are published, so the calculation is a multiplication over numbers somebody else already measured. The time-saved figure I got from those same nine sessions was wrong by a factor of exactly two.

Both halves came out of the same code on the same evening. One was right to a hundredth of a cent. The other was off by 100%, looked completely plausible on screen, and would still be wrong today if the run count had happened to match the session count when I went looking for something unrelated. Anyone building agent economics is going to hit that asymmetry, so it's worth being explicit about where it comes from.

The cost side is finished work

Metering spend is solved and has been for a while. LiteLLM prices calls at the proxy. Langfuse and LangSmith both attach cost to traces. Every provider dashboard shows you a monthly figure. My own price table took 2,499 priced models from the 2026-08-08 sync of LiteLLM's MIT-licensed model_prices_and_context_window.json, and most of the work in building it went on deciding what to throw away.

This half is tractable because both of its inputs are handed to you. Token counts come from the provider that billed you. Rates are published. Whatever is hard about agent economics, it isn't the multiplication.

Then, at the end of the month, an invoice arrives and tells you whether you got it right, and that is the part that matters most. A cost model has an external referee. If my per-run figures sum to something the provider disagrees with, one of us is wrong, it is probably me, and I can go find out which line is off.

Here is what the nine sessions looked like:

The cache ratio is about 34 to 1, and on Opus 5 the cache read rate is $0.50 per million against $5.00 per million for fresh input. So the expensive-looking number on that table is the cheap one. Nine sessions of real work, twelve cents.

Where the cost side still misses, and why it recovers

It isn't perfectly solved. Claude Code reports its model as claude-opus-5[1m], with the context window as a bracketed suffix, and no upstream LiteLLM key carries a bracket. I checked all 2,986 of them. So my lookup missed and one run booked with no price at all.

The system flagged it as unpriced and left it visibly unpriced. The alternative, which plenty of tools take, is to treat a missing price as zero, which produces a slightly cheaper run and no signal that anything happened. I'd have shipped that bug for months.

Even so, look at the shape of the failure. A lookup miss is discoverable, it is falsifiable against the bill, and once found it takes an afternoon. Per-request charges, image tokens and negotiated enterprise rates all sit outside a per-token table too, and all of them share that property: someone can check.

The value side has no invoice

Now the other half. The value of an agent run is the cost of the thing that didn't happen, which means it rests on four assertions, none of which any system emits:

• how long the task took a person before
• what that person's fully loaded hour is worth
• whether the task would have been done at all without the agent
• whether the hour returned turns into anything the business can spend

Nobody bills you for work that didn't happen. There is no month-end statement against which your counterfactual reconciles. You can be wrong about all four of those for a year and the only symptom is a number that looks good.

My own error was the second-simplest version of this. I wrote the baseline per session: 25 minutes of manual work with 4 minutes of oversight deducted, 21 minutes net. The engine applied it per priced run. One Claude Code session emits two priced runs, a primary Opus request and a Haiku sub-agent call. A per-unit baseline multiplied by a unit count that doesn't match the unit of work is the most common way an agent savings figure gets inflated, and it inflates by whatever the ratio between the two units happens to be. Twelve model calls per job and a per-job baseline gives you a twelvefold overstatement.

One agent, both halves

Say an agent handles a task a person used to do in 20 minutes. Say it's first-line helpdesk work, so the rate defaults I'd reach for are the BLS OEWS May 2024 national median for SOC 15-1232, which is $29.01 an hour, loaded at 1.43 to cover benefits (BLS ECEC December 2025 puts benefits at 29.9% of total compensation). Call it $41.48 an hour fully loaded. Every one of those inputs is a choice I just made in front of you.

The cost lines on that table are worth a fraction of a cent each and I know them to six places. The value lines are worth a thousand times more and I know them to roughly "somewhere between $6.91 and $13.83, depending on an argument about whether returned time is bankable". Effort spent tightening the cost side past the fourth decimal is effort spent on the wrong half.

The same asymmetry at production volume

Nine sessions is a small enough sample that the gap is easy to wave away, so I generated a month of traffic for that triage agent and ran it through the product: 5,000 runs on claude-sonnet-5, 149 of them failures.

The traffic is synthetic. I invented the token shapes to look like a triage workload, a large cached prompt with a small fresh delta per ticket. The pricing is not invented. Every run went through the ingest path, the dated rate table and the ledger that a real workspace uses.

The cost reconciles by hand: 14,182,283 at $2.00 per million, plus 2,948,071 at $10.00, plus 200,145,291 at $0.20, is $97.874334, and the six-decimal column carries the rest. The value is 1,617 hours from the 4,851 runs that succeeded, at $41.48 halved to $20.74. The 149 failures cost money and returned none.

So the large number is 342 times the small one, and it is the one resting entirely on "20 minutes". That ratio is the argument. Adding a seventh decimal to $97.874338 does nothing for it.

Two of those lines deserve their own defence. The 0.50 discount has precedent: Nucleus Research's published methodology recommends 0.5 as a conservative default for exactly this class of claim. That's precedent for discounting. Whether 0.50 is right for your process is a separate question that nobody has answered for you.

What a complete agent P&L needs

On the cost side: token spend at a dated rate, per-run platform cost, the build cost amortised over something, and ongoing maintenance. Most teams have the first and forget the last two.

On the value side, one thing, stated four ways: the baseline, who asserted it, when they asserted it, and how it was arrived at. If the answer to the third is "the vendor" and the answer to the fourth is "we asked around", say so on the report. Gartner's August 2025 CFO survey found that 36% of CFOs are confident they can deliver enterprise AI impact (source). Confidence at that level doesn't get repaired by pricing tokens to a seventh decimal place.

What this doesn't tell you

• Nine sessions on one laptop is a sample. Your cache ratio will differ with your working style, and caching dominated the cost half in mine.
• The doubling error was mine, found in my own product, in a domain I work in full time. I have no evidence about how common it is elsewhere, only the structural argument that a unit mismatch produces no symptoms.
• The BLS medians above are national and they are for the United States. A rate that is honest in Ohio is wrong in Zurich and wrong in Manila.
• Nothing here says the value half is unknowable. It says it is assumed, which is a different claim, and the fix is labelling rather than more precision.

If you want to argue with your own number

The ROI calculator takes the baseline minutes, the loaded rate, the run counts and the per-run cost, and shows what year one does when you move any of them, including the version halved for productivity hours.

Whatever you use, check the unit of work before you check anything else. Count the runs and count the jobs. If those two numbers differ, find out why before you multiply either of them by a baseline.