Every AI vendor publishes a price per million tokens, and every comparison starts there because it is the only number that is easy to get. It is also the number least likely to predict what the tool costs your business.
Prompted by Theo's video and Nate B Jones's video, both of which land on the same uncomfortable point from different directions.
The price on the page is not the bill
A model comparison on a spreadsheet looks convincing: input price, output price, maybe a blended rate. Then the tool meets real work. It takes more tries than expected. The first answer is close but not usable. Someone retries it, checks the source, fixes the formatting, or hands the job to a more expensive tool to finish.
The generation was cheap. Completing the job was not. The invoice still looks reasonable, and the workflow does not.
One of the clearest illustrations, from the two videos credited above: across seven published benchmarks, DeepSeek ranged from 53 percent cheaper to 41 percent more expensive per correctly solved task, despite having the lower token price. That does not crown a winner. It shows that the task, and your definition of correct, can reverse the advertised saving entirely.
Count the cost of one accepted result
The unit that matters is not the token. It is one finished piece of work you are willing to accept without redoing it. So the question becomes: what does one accepted result cost?
That number is countable, and you do not need a data team to count it. Pick twenty real examples of the task, including the awkward ones a polished demo would avoid. Run every candidate tool against the same examples with the same instructions and the same standard for done. For each attempt, write down the tool spend, the extra steps and retries, the waiting time, the human review and cleanup, and the share of attempts that passed with no repair. Then divide the total cost of all attempts by the number of accepted results.
That single division separates cheap output from economical work, and it stops a weak first attempt from looking efficient because the rework happened on somebody else's desk.
Route the work, do not crown a winner
Once you can see cost per accepted result, the decision stops being which model is best and becomes which work goes where.
Low-cost tools do well on bounded, reviewable, high volume work: pulling fields out of documents, sorting inbound messages into categories, first pass research, drafting a starting version. The output is easy to inspect and a mistake is easy to contain.
Work that turns on reading intent, recovering from a surprise, or making a consequential call deserves the opposite treatment. A higher price per request can still produce a lower cost per accepted result, because the first answer is usable more often.
Your people are the ones who benefit
There is a practical reason this matters beyond the budget line. Cost per accepted result is really a measure of how much cleanup your staff absorbs. A bargain tool that produces almost-right output moves work onto the person reviewing it, which is the opposite of the point.
A tool worth keeping gives your office manager, your estimator, or your coordinator back the part of the day that was never the job they were hired for, and leaves the judgment with them. Measure that, and the right choice usually stops being ambiguous.
Where to start
Pick one recurring task, define what an acceptable result looks like in writing before you test anything, and count. If you want help choosing the task and setting the standard, you can request an assessment, and the local service area is on the page for AI consulting on Long Island.