Cost Per Token Is a Vanity Metric. Cost Per Finished Task Is the Bill.
Corporate AI spend moved to a half-price model in under a month, which proves model choice is reversible and the cheap model is often the expensive one
Three founders in the last four months have sent me a development quote with a line item that says something like "AI usage: estimated $X per 1,000 tokens." Every one of them asked me the same question: is that a good price?
It is the wrong question, and the person who wrote the quote usually knows it.
This week Opus 5 overtook Fable 5 in corporate model spending within a month of launch, largely because it costs about half as much and companies could reroute routine work to it almost immediately. I have not used either model in production, so I am not going to tell you which one is better. But billions of dollars in enterprise spend relocating in under thirty days tells you two things about your own product that most founders have backwards.
Thing one: model choice is a two-week decision, not architecture
If large companies with compliance reviews and procurement departments can move their default model in a month, then the choice of which model powers your MVP is not a foundational decision. It is closer to picking a payment processor than to picking a database.
That should change how you negotiate. Right now a lot of founders are being walked into a vendor commitment during the sales conversation, wrapped in language that makes it sound permanent. It isn't permanent for the enterprise. It shouldn't be permanent for you either.
The thing that is permanent is how the code was written. Model choice is reversible. Model coupling is not, or at least not cheaply.
Thing two: the cheap model is frequently the expensive one
Half price per token is not half price per outcome. A cheaper model may need more attempts, longer prompts with more examples stuffed into them, and more human eyes on the output before it goes anywhere near a customer. Your bill is retries, context, and salary.
I learned this with my own money. I run FlipSmrt solo, and it has real MRR, which means every AI call in it has a margin attached to it that comes directly out of what I take home. There is no infra budget to hide inside. When I was tuning one of the core flows, I had a cheaper model that looked like an obvious win on the rate card. In practice it needed a longer prompt to behave, it failed cleanly maybe one time in six and needed a re-run, and worst of all, I did not trust it enough to stop reading the output.
That last part was the actual cost. The token difference was rounding error next to twenty minutes a day of me checking work. The moment I priced my own attention into the equation, the "expensive" model was cheaper, and it stayed that way until the cheap models got good enough that I re-ran the comparison and switched. That re-run took an afternoon, because I had built it so it could.
The number that matters is cost per finished task. Not cost per call. Not cost per token. Cost to get one unit of work all the way done, including the failures and the human who checked it.
What I audit first when I walk into someone else's codebase
I have done interim CTO work where I inherit a product built by a previous team or an agency. The first thing I look for is not test coverage or infrastructure. It is whether the product has been welded to one model provider.
Welded looks like this, in plain terms. The provider's code library is scattered through dozens of files instead of sitting behind one internal function. The prompts have been tuned to the quirks of one specific model with no record of what "good output" even means. The product depends on vendor-specific features in the main workflow, so there is no equivalent to switch to. And there is no saved set of real examples to test against, which means nobody can prove a different model would be worse. They can only guess, and guessing always favors the status quo.
When all four are true, switching models stops being an afternoon and becomes a rewrite. That is when a founder discovers their pricing is set by someone else's roadmap.
None of this is malice. It is what happens when a developer optimizes for shipping this sprint and nobody in the room is responsible for what the product costs to run in month nine. That accountability gap is exactly the CTO-shaped hole most of my clients are trying to fill.
What to demand, in language you can use tomorrow
You do not need to understand model architecture to enforce this. Ask for four things, in writing, before work starts.
- One seam. All model calls go through a single internal function. Ask them to show you the file. If they can point at one place, you can switch providers. If they wave at "it's throughout the codebase," you cannot.
- A test set of real tasks. Thirty to fifty actual examples of the job your product does, with what a good answer looks like. This is the thing that lets anyone, including a developer you hire later, prove whether a swap helps or hurts.
- Per-task cost logging, including failures. Not monthly spend. Cost to complete one job, with retries counted.
- Human review time, tracked. If someone on your team reads the output before it ships, that is part of the cost. Write it down in minutes.
The honest counter-argument: building an abstraction layer for its own sake wastes time, and there are jobs where the premium model genuinely earns its rate. Long autonomous work that has to stay coherent across many connected steps is real, and it is where the expensive models are supposed to live. Both things are true. But one thin seam is a day of work, not a framework, and the test set pays for itself the first time you need to decide anything.
If you are spending $14,500 on a fixed-scope MVP, the model bill is not the thing that will hurt you. Being unable to change your mind is.
Ask your developer where the switch is. If there isn't one, that is the conversation to have this week, not next year. If you want a second pair of eyes on a quote or an inherited codebase before you sign, book thirty minutes and bring the quote.