The Token Price Is the Easiest Number in Agent Operations and the Only One That Decides Nothing.

Three numbers that keep getting confused

Whenever a room discusses the cost of AI agents, three different quantities almost always travel under the same word.

The first is the token price. It sits in the vendor’s price list, is public, verifiable and rarely changes. Anthropic’s pricing documentation lists five US dollars per million input tokens and 25 per million output tokens for Claude Opus 5, two and ten for Claude Sonnet 5, one and five for Claude Haiku 4.5. Those numbers hold up because you can look them up.

The second is the price per attempt. It follows from the token price and the token consumption of an actual run. It appears in no price list, because it depends on your prompt, your context and your tools. It becomes measurable the moment something runs.

The third is the price per completed business event. The cost of an invoice actually being booked, a ticket actually resolved, a record actually created correctly. That number decides whether something pays off, and it is the only one of the three no vendor can calculate for you.

The error in most calculations is not bad arithmetic. It is that the first number is presented as the answer to the third question.

What the vendor documents and what it does not

It pays to separate precisely which quantities are publicly evidenced and which you have to collect yourself. More is public than most people assume.

Evidenced: the prices per million tokens. As above, as of the cited documentation.

Evidenced: the effect of prompt caching. The documentation states concrete factors. A cache write with five-minute validity costs 1.25 times the input price, with one-hour validity twice. A cache hit costs 0.1 times, so ten percent. From that follows a statement you can verify: at five minutes, caching pays off from the first hit, at one hour from the second.

Evidenced: that the tokenizer is not constant. Anthropic states explicitly that Claude 4.7 and later models use a different tokenizer that produces roughly 30 percent more tokens for the same text. Comparing model costs across generations by price list alone compares two different units.

Evidenced: that runtime can be billed separately. For Claude Managed Agents the documentation names 0.08 US dollars per session hour on top of tokens, metered only while the session is actually running. Server-side web search costs ten US dollars per 1,000 searches.

Not evidenced and not evidenceable: your success rate. Plenty of figures circulate on this point, some with two decimal places. None of them transfers to your process, because success rate is not a model attribute. It is a property of the combination of task, data quality, tooling and stopping criterion. Taking that number from someone else’s study is not measuring it. It is guessing.

The multiplier nobody publishes

A price list describes a request. An agent is not a request-response pair but a loop. It plans, calls a tool, reads the result, decides again. Every one of those steps carries the prior context along, and every tool call adds new context.

The documentation makes this very concrete in one place. It quantifies how many extra input tokens the tool definition alone costs before any tool is called: for Claude Opus 5 it is 286 tokens with free tool choice and 406 with forced choice. Bash access adds 325, the text editor 700. Small numbers, but they accrue on every pass through the loop, not once per task.

Then there is the context itself. An agent that in pass seven still carries the complete history of passes one through six pays for that history seven times. This is exactly where caching applies, and exactly why it is not fine-tuning but the difference between two orders of magnitude.

The documentation works through an example you can follow. A one-hour session with Claude Opus 5, 50,000 input tokens and 15,000 output tokens, costs 0.25 dollars for input, 0.375 for output and 0.08 for runtime, 0.705 dollars in total. If 40,000 of the input tokens are cache hits, the same session drops to 0.525 dollars. A third less, with nothing about the task having changed.

Why the success rate dominates everything

Take the 0.705 dollars from the example as cost per attempt and see what the second quantity does to it.

At a 90 percent success rate you need on average 1.11 attempts per completion. Cost per completion: about 0.78 dollars.

At 60 percent you need 1.67 attempts. Cost: about 1.18 dollars.

At 30 percent you need 3.33 attempts. Cost: about 2.35 dollars.

That is a factor of three between the best and the worst variant, and no human is involved yet. Assume the failed cases do not vanish but get handed to a person, and the picture shifts again sharply, because an hour of a person’s time in any European market sits two to three orders of magnitude above one agent run.

An uncomfortable ranking follows. A model switch that halves the token price saves half of the smaller factor. A process change that lifts the success rate from 60 to 90 percent saves a third of the larger one. In most cases the second is by far the more rewarding work, and it is the work no vendor does for you.

What you have to measure for the calculation to hold

Four quantities are enough, and all four can be collected from normal operations if you plan for them from the start.

1. Tokens per attempt, split by input, output, cache write and cache hit. The API reports these per response. If you do not record them, you cannot reconstruct later where the budget went.
2. A definition of completion, before the first agent starts. What exactly counts as done? Without that definition, every success rate is an opinion. It has to hang on a state in the target system, not on the agent’s self-report.
3. Attempts per completion. Follows from point two plus an identifier that ties all attempts to the same business event.
4. Handover rate to humans and the time behind it. The share of cases that land with a person despite the agent, and how long the person needs.

Point two is where most projects fail, and it is the only one that costs nothing. An agent reporting “done” and a record actually sitting correctly in the target system are two different statements. As long as the success rate rests on the first, you are measuring the model’s confidence, not the outcome.

That distinction is exactly what underpins our automation unit economics benchmark. It translates tasks, credits and executions from different platforms into one shared unit, cost per successful business event, across twelve workflow archetypes and 180 scenarios. The raw data is open so the model can be recalculated with your own assumptions rather than believed.

The comparison that is actually due

Once the four quantities exist, a question becomes answerable that used to be a matter of taste: does this specific step warrant a model call at all?

A substantial share of what gets handed to agents today is deterministic. Writing a form field into a CRM field, reformatting a date, looking up an order number. For steps like that, a language model is the most expensive and least reliable option available. Not because it is bad, but because it is a tool for ambiguity being pointed at something unambiguous.

The architecture that holds up is almost always mixed. Deterministic steps run as code, with clear errors and no per-execution cost. The model takes the places where interpretation is genuinely required. What running that on your own infrastructure looks like, without execution limits and with full access to the logs, is described on our process automation page.

This is not an argument against agents. It is an argument for treating the model call as what it is commercially: the most expensive line in the loop, which you therefore place only where it does something code cannot.

What remains

The token price has been falling for years and will keep falling. That is the most reliable forecast in this entire field and simultaneously the least useful, because it concerns the smallest of the three factors.

What does not fall on its own is attempts per completion and the share that reaches a human anyway. Both hang on your data quality, your process definition and your stopping logic. They do not improve because a vendor publishes a new price list.

Start measuring them today and in six months you have a basis for decisions. Keep comparing token prices and in six months you have a more current price list.