Stop Picking a Model. Start Buying the Right to Change Your Mind.
Open models jumped from 28% to 62% of tokens at Vercel in two months. Which AI you build on is now a config value, and switching cost is the only thing worth evaluating
Last year I inherited a half-built product where the previous team had welded everything to one vendor. Not just the model. The conversation state, the file storage, the tool-calling logic, the retrieval, all of it lived inside that provider's hosted abstraction. When the founder's usage grew and the monthly bill stopped looking like a rounding error, I priced out the move to a cheaper model.
Three weeks. Three weeks of rewrite, on a build where the founder had budgeted those weeks for features customers had asked for. Nothing about the product got better. We just bought back a choice that should never have been sold.
I think about that build every time a founder asks me which AI they should build on.
The number that should change how you think about this
Vercel published their token mix recently, and open source models went from 28% of their traffic to 62% in about two months. That is real production traffic, not benchmark chatter. Two-thirds of it flipped vendors in eight weeks.
Read that as a founder, not as an engineer. It does not mean open models are better. It does not mean you should switch to one. It means the answer to "which model is right for this workload" changed underneath thousands of live products in less time than most seed-stage MVPs take to build.
Which tells you something specific: the model is not a founding decision. It has the half-life of a pricing page.
You are being asked to make the wrong decision
When you commission an MVP or interview your first engineer, someone is going to ask you to weigh in on the model. They will show you a comparison. Maybe a benchmark chart. You will nod, because you cannot evaluate it, and because it feels like the sort of thing a founder should have an opinion about.
You cannot evaluate it. That is fine. Neither can they, honestly, not six months out.
What you can evaluate is what it costs to be wrong. And that number is entirely determined by how the thing gets built, which is a decision you are absolutely qualified to make demands about.
I have been fractional CTO for around ten companies since 2024. Inference pricing (what you pay per unit of text the model reads and writes) has moved under me repeatedly in that window, sometimes down by an order of magnitude, sometimes sideways when a provider quietly deprecated the cheap tier. On FlipSmrt I build with a swappable model layer for exactly this reason. Not because I am clever. Because I got burned and did not enjoy it.
The four things to put in writing
Whether you are hiring an agency, a contractor, or your first engineer, these belong in the scope document. All four are cheap to do at the start and expensive to retrofit.
One-file model swap. Ask directly: "If I want to move from this model to a different one from a different company, how many files change?" The answer should be one, plus a config value. If the answer is "well, it depends," or involves the word "refactor," you are buying the three weeks I described above.
No annual API commitments. Some providers will offer a discount for committing spend up front. At your stage, do not. You are trading real optionality for a percentage off a bill you cannot yet forecast. Pay retail, stay free.
Evals you own. An eval is just a scored test set: fifty or a hundred real inputs from your business with the answers you consider correct. If you own that, swapping models is a Tuesday afternoon. You run the new one, you compare the scores, you decide. If you do not own it, every switch is a guess and nobody will want to make it. This is the single most valuable artifact your engineering spend produces and most founders never ask for it.
No provider-proprietary features doing load-bearing work. Vendors ship convenient hosted pieces: managed conversation memory, their own document search, their own agent runner. They are genuinely nice to use and they are the bars of the cage. Your data, your prompts, and your orchestration logic should live in your codebase, running against a generic interface.
That is the whole list. It is not a technical wish list, it is a set of terms.
The honest counter-argument
Sometimes one model really is the only thing that works. Frontier reasoning on a hard task, a specific long-context behavior, a particular tool-calling reliability that nothing else matches. I have shipped on the expensive option more than once and did not feel bad about it.
But that is a runtime fact, not an architecture. Use the best model for the job today. Just refuse to build in a way that assumes it will still be the best model in March. Those are separate decisions and the whole trick is keeping them separate.
The other objection I hear is that abstraction costs time. It does, a little. On a fixed-scope MVP build it is maybe half a day of the total, and I include it by default because I would rather absorb that than have the conversation I had with that founder about her three missing weeks.
What this actually buys you
Leverage in a negotiation you are going to have whether you plan for it or not. When your usage grows and someone's pricing changes, you want to be the customer who can walk. Products that can switch models get cheaper over time as the market fights over them. Products that cannot get more expensive on someone else's schedule.
The cheapest model that will run your product a year from now has probably not been released yet. Build like you believe that.
If you are about to commission a build and you want the swap clause and the eval set written into the scope before you sign, that is most of what my fixed-scope MVP at $14,500 is designed around, and it is also a fine use of a single $4,500 fractional sprint if you already have a team and just want someone to audit what they have locked you into. Grab thirty minutes and bring the scope doc.