The switching cost you sign up for with a model provider

Choosing a model provider looks reversible. It is an API call. You could point it somewhere else on a Friday afternoon. That is the story people tell themselves at the start, and it is roughly true on day one. It stops being true the moment you start making the feature good, because every improvement you add ties you a little tighter to the specific model underneath.

The prompts that only work here

A director of engineering at a messaging startup described the shape of it. His team spent months tuning prompts against one provider’s model. The wording, the examples they packed into context, the small tricks that coaxed the format they wanted, all of it was shaped to how that particular model behaved. The prompts read like a contract written in the dialect of one model.

When a cheaper provider appeared, he ran the obvious test. He pointed the same prompts at the new model and the quality fell apart. The instructions that were load-bearing on one model were noise on the other. Moving was not a config change. It was a second tuning project, weeks of it, to rediscover on the new model what the team already knew on the old one. The switching cost was invisible until he tried to switch.

He was clear that this was not anyone tricking him. It is the nature of prompting a specific model well. The better you get, the more your work assumes that model’s habits, and the more of that work you throw away if you leave.

The commitments that go deeper than prompts

A staff engineer at a networking-hardware company had a heavier version of the same story. His team had gone past prompting into fine-tuning, and had wired the feature into one provider’s tools for function calling and structured output. Each of those was a good decision on its own. Together they formed a set of ropes tying the feature to one vendor.

He made the point that matters. The lock-in is not one big wall you can see. It is a pile of small conveniences you accepted one at a time, each reasonable, each adding a little to the bill you pay if you ever want out. A fine-tuned model does not transfer. Provider-specific features have no equivalent elsewhere. He was not against any of it. He wanted teams to know they were spending future flexibility every time they leaned on something only one provider offered.

You reduce the cost the same way you reduce any debt, by watching where it accrues:

Keep a thin layer between your code and the provider. One place to change the client means one place to change, not a hundred call sites.
Track which features are provider-specific. Function-calling formats and structured-output modes differ. Know which ones you depend on.
Hold a small evaluation set the provider never sees. It lets you test a rival model honestly in an afternoon instead of guessing.
Treat fine-tuning as a deliberate commitment. A tuned model is real lock-in. Choose it knowing it does not move with you.

Deciding with the cost in view

None of this argues for staying vendor-neutral at all costs. Chasing perfect portability means using none of the good provider-specific features, and that is its own tax on quality. The point is to make the trade on purpose. When you reach for a convenience that only one provider offers, decide it is worth the rope, and write down that you reached for it. That record is what turns a future migration from an archaeology project into a scoped one.

Every model choice is also a decision about how expensive it will be to change your mind. Spend that flexibility where it buys you real quality, and keep an honest count of what you spent.