Cost & models4 min read
One of These Models Costs 5× More Than the Other. Most Tasks Can't Tell.
Frontier models are priced like frontier work. Most of what an app builder does all day is not frontier work.
Ask an AI builder to change a heading and it will happily spend the most expensive model available doing it. Not because that is the right call, but because someone set a default in a config file eighteen months ago and nobody has looked since.
The spread is not marginal. Across a current model family, the cheapest and the priciest option differ by roughly five times on input tokens and five times on output. On a long build with a lot of file reading, that is the difference between a coffee and a lunch.
5×
input token price, cheapest to dearest
5×
output token price, same comparison
1
line of config most teams have ever changed
What you are actually buying
The premium is not for correctness on small tasks. A cheap model renames a variable, rewrites some copy, adjusts a Tailwind class or fixes an obvious type error about as well as an expensive one. You are paying for behaviour that only shows up at length:
Holding a plan across many files
A feature touching six files, where the fourth edit has to remember a decision made during the first. This is where cheaper models drift.
Recovering from being wrong
Noticing a diagnosis was mistaken and changing approach, rather than applying the same fix harder. The single biggest cost sink in agent work.
Reading unfamiliar code
Working out what an existing codebase already does before adding to it, instead of writing a parallel implementation next to it.
None of that matters for "make the button blue". All of it matters for "add multi-tenant billing".
A rough rule that survives contact
- Copy changes, colours, spacing, single-file edits, obvious type errors: the cheapest model in the family. You will not notice a difference except on the invoice.
- Most feature work — a new page, a form wired to an endpoint, a component with real state: the mid model. This is where the bulk of your turns should land.
- Multi-file refactors, unfamiliar codebases, anything you have already failed at once: the frontier model. Being wrong slowly is more expensive than the token price.
- Long autonomous runs: whichever model you would trust for step four, because you will not be there to correct step two.
The counterintuitive one
Retries are priced in the expensive currency. A cheap model that needs three attempts on a refactor — plus your attention between each one — costs more than one model that gets it right the first time. Cheapest per token is not cheapest per outcome, and the gap widens the longer the horizon.
The picker and the price list must be one table
Here is an implementation detail with real money attached. If the list of models a user can pick lives in one place, and the table used to estimate what a turn cost lives in another, they drift. Someone adds a model to the picker, forgets the price table, and every turn on that model bills at whatever the fallback is.
Two directions to get that wrong, and they are not symmetrical. Fall back to the cheapest and an unpriced model quietly uncaps spending. Fall back to the dearest and you over-bill a misconfiguration — recoverable, visible, and someone will complain within a day. Make the fallback the most expensive rate you know.
Better still, make it impossible: one table that is both the allowlist and the price list, so a model you can select is by construction a model the caps can account for.
Record what ran, not what was configured
The related bug is subtler and lives in usage accounting. A turn is started with a model override. The turn runs. Afterwards, the cost is recorded against… the server's default, because that is what the accounting code had to hand.
Nothing looks broken. Every number is plausible. But the moment anyone picks a cheaper model, they are billed at the expensive rate, and the ledger that is supposed to enforce their daily cap is quietly wrong in the platform's favour. The fix is unglamorous: the turn reports which model it actually ran on, and the ledger records that.
Where the choice should live
A model is a property of the project, not of the person. Everyone working on the same app should get the same behaviour and the same bill — "why is it suddenly worse at this" is a miserable thing to debug when the answer is that a colleague's dropdown says something different.
One nuance worth building in: let a project follow the platform default rather than pinning a model that happens to be the default today. The two look identical now and diverge usefully later, when the default moves and you want the projects that never expressed an opinion to move with it.
Should the cheap model handle automatic error repair?
Use whatever the user chose. Quietly upgrading to a bigger model to fix your own mistake puts a charge on their bill that they did not choose and cannot see coming.
Is it worth switching models mid-project?
Yes, and it should be a two-second change. Draft on the cheap model, switch up when you hit something structural, switch back. The friction of changing it is what stops people, not the decision.
How much does the model matter compared to the harness around it?
Less than vendors imply. A mid-tier model with real feedback — build errors, browser checks, a repair loop — beats a frontier model working blind. Buy the loop before you buy the tier.