Every LLM API cost comparison starts with the same number: price per million tokens. It is printed on every pricing page, so it is what gets compared. It is also, for most real workloads, the smaller half of the bill.
The bigger half is rework.
Where the money actually goes
Watch a team use a weak model for a week and a pattern appears. The first answer is almost right. Someone reads it, finds the flaw, re-prompts. The second answer is closer. A human fixes the last 10% by hand. The API line item for that task was cheap. The task was not.
Three costs hide in that loop:
- The retry. Every re-prompt resends the whole conversation — system prompt, history, files. On a coding-agent workload, a single retry can cost more than the original attempt, because the context has grown.
- The human pass. A developer spending four minutes fixing an "almost right" answer costs more than any token ever will. This cost never appears on the API bill, which is exactly why it gets ignored.
- The trust tax. Once a team learns the model needs checking, they check everything. Review time becomes a permanent surcharge on every task, including the ones the model would have nailed.
None of this is an argument against cheap models. It is an argument that "cheap" has to be measured at the task level, not the token level.
The unit that matters
The honest unit is cost per accepted output — total spend divided by the number of outputs you actually ship without manual rescue:
cost per accepted output = cost per attempt ÷ acceptance rate
A $0.10 attempt accepted 90% of the time costs $0.11 per shipped result. A $0.05 attempt accepted 40% of the time costs $0.125 — and that is before pricing the human minutes. The cheaper token lost.
We will not pretend we have a controlled experiment with a tidy savings percentage; we have not run one, and anyone who quotes you a precise universal figure is selling something. The arithmetic above is mechanistic, not measured — but it points at a measurement you can run yourself, on your own tasks, in an afternoon.
Measure yours in an afternoon
- Pick 20 real tasks from last week. Not benchmark tasks — the actual tickets, prompts, and questions you gave the model.
- Run them through two candidates — your current provider and one challenger. Same prompts, same tools.
- Score acceptance harshly. Accepted means: shipped as-is, or with edits under a minute. Anything else is a reject.
- Count the real bill. Tokens for every attempt, including retries. Then divide by accepted outputs.
Twenty tasks is not statistics. It is enough to see a 2× difference, and 2× is the size of difference worth acting on. If the numbers come back close, keep the cheaper provider — that is what the measurement is for.
Two things we do know from our own logs
We run an API gateway, so we see our own numbers in uncomfortable detail. Two observations, offered as anecdotes rather than universal laws:
- Cache behavior dominates agent bills. In one documented coding-agent run, 93% of input tokens were cache reads. A provider's cached-input price carried most of that bill — which is why we publish a cache column and why our Kimi K3 API pricing comparison blends at 7:2:1.
- Retries multiply context. The failed runs in our logs are never the cheap ones. A task that takes two attempts costs well over double, because attempt two resends everything attempt one accumulated.
Both point the same direction: the interesting question about a provider is not "what does a token cost" but "what does a finished task cost."
The takeaway
Per-token price is a fine first filter — it eliminates providers in seconds. If you are still at that stage, our Kimi K3 API pricing comparison lines up 18 providers with cached-input pricing broken out. But the decision it cannot make for you is the one that matters: which provider finishes your work with the fewest total dollars and the fewest human minutes. That number is cost per accepted output, and no pricing page will ever print it for you. You have to measure it once.
After that, the cheap API and the best API tend to be the same one. One caveat from our own scar tissue: the effort knob only saves you money if it actually reaches the model. And if your workload scales by adding agents instead of effort, the newest scaling axis comes with its own invoice.
Wallaby Token is an inference platform for open-weight models. We wrote this because we publish our own prices in the open and would rather be compared on finished tasks than on token lists. Check our live pricing and run the 20-task test against us — that is the point.