The open-weights argument is nearly always conducted as a values debate. Openness good, gatekeepers bad, or alternatively, safety serious, amateurs reckless. I find I have very little to contribute to that, partly because both sides are arguing about the world and I'm usually being paid to argue about one company's next eighteen months.
The question I actually care about is duller and more answerable. If the model you're building on became unavailable, unaffordable, or unacceptable in six months, what would it cost you to move?
Most teams have never worked this out. Which means they've taken on a risk of unknown size, which is the only kind that really hurts.
Why the question comes up now
Three things happen, and they've all happened to clients of mine in the past year.
A hosted model gets deprecated. You're given a migration window, which sounds generous until you realise your prompts were tuned against the old version's particular quirks and the replacement is better on benchmarks and worse on your task. That's not hypothetical; better-on-average routinely means worse-on-yours, and you find out with three weeks left.
The price changes, or your volume does. At pilot scale nobody cares about per-token cost. At production scale the bill becomes a line item somebody senior has opinions about, and suddenly the question of whether this workload could run somewhere cheaper is not academic.
Or the requirement changes underneath you. A customer's procurement asks where the data goes. A regulator asks the same. A deal you want requires processing to stay in a particular jurisdiction, and your entire architecture assumes an API endpoint you don't control.
None of these are exotic. They're the ordinary weather of running software with a supplier in the critical path, and we all knew how to think about this before AI turned up — we just seem to have forgotten while we were excited.
What actually locks you in
Here's the useful part, because the lock-in isn't where people look for it.
It isn't the API. Swapping one chat completion endpoint for another is an afternoon, and there are half a dozen libraries that will do it for you. If your migration plan is "we use an abstraction layer," you have solved the five percent of the problem that was never going to be the problem.
The lock-in is in three other places.
Your prompts. They are not portable and pretending otherwise wastes a fortnight. A prompt that's been refined over months against one model encodes hundreds of small accommodations to that model's tendencies — how it handles a negative instruction, whether it needs the format example, how it drifts when the context gets long. Move it and it degrades in ways that are individually minor and collectively fatal. Expect to redo real work per prompt, and budget for it honestly.
Your fine-tunes. If you've fine-tuned a hosted model, you have a derivative of an asset you don't hold. The training data is yours, the artefact isn't. This is fine if you kept the data, the pipeline, and the ability to run it again. Many teams did not keep the pipeline, because it was run once, by a contractor, in a notebook.
Everything you've built around one model's failure modes. The guardrails, the retry logic, the output validators, the little cleanup function that strips the preamble it always adds. That accumulated scar tissue is quietly the most expensive thing to reproduce, and it's invisible in any architecture diagram.
The thing that makes an exit possible
There's exactly one investment that converts a scary migration into a boring one, and it's the same artefact I bang on about constantly: a real evaluation set.
If you have a few hundred graded examples that represent what your system is for, then swapping models is a Tuesday. You point the harness at the candidate, you get numbers, you see precisely where it's worse, you fix those cases or you decide the trade is acceptable. The decision becomes evidence-based and takes days.
Without it, the migration is a matter of opinion, conducted under time pressure, by people who are frightened. I've watched that go badly enough times to be blunt about it: your evals are your portability. Everything else is architecture theatre.
So, open or closed?
Given all that, my actual advice is unromantic.
Use the best hosted model for the work that's hard, novel, and low-volume, where capability matters more than anything and the frontier is genuinely ahead. Pay for it. Don't self-host to prove a point; running inference well is a real operational discipline and most teams underestimate it by a factor of several.
Move the high-volume, narrow, well-specified work onto weights you hold, once it's stable — not for ideology, but because at volume the economics and the latency and the "your data never leaves" conversation all point the same way, and because a model you host doesn't get deprecated on someone else's schedule.
And regardless of which you pick: keep your training data and your pipeline, keep your evals current, and once — just once — actually run the migration. Take a real workload, point it at a different model, and see what breaks. A day spent finding out is cheaper than a quarter spent discovering it during an incident.
The teams that will handle the next shift calmly aren't the ones who picked correctly. They're the ones who know what picking wrongly would cost.
