Put the model behind your own interface, so that switching costs a day instead of a quarter. Do not marry a single model. Expect to migrate at some point.
The advice is correct and it usually arrives in one sentence, which makes it sound like a small architectural precaution. It is not. The model is the one component that genuinely does port easily. What accumulates around it is where the cost sits, and a business that has been told to keep things swappable, has done the obvious thing, and then tries to switch, discovers the difference at the worst possible moment.
This piece is about what actually moves, what does not, and what to do about it before you need to.
Why the question arrives whether you want it or not
The reasons to switch are mostly not strategic. They are things that happen to you.
Providers retire versions. A model your system was built and tuned against is deprecated, and the replacement behaves differently on your specific work even when it benchmarks better overall. This is the most common trigger and it comes with a deadline set by somebody else.
Prices change, in both directions and without much notice.
Terms change. Retention, training use, sub-processors, regional availability. A tool that was acceptable under January’s terms may not be under June’s, and that is a compliance question rather than an engineering one.
Availability fails. A provider has an outage long enough to matter, or restricts a model in your region, or withdraws a model at short notice. A business whose operations depend on one provider’s uptime has taken on a dependency it never priced.
And occasionally the ordinary reason: something else has become clearly better at your particular job.
The common feature is that the timing is rarely yours. Portability is worth having because the decision arrives unannounced.
What ports easily
Genuinely straightforward, if the design allowed for it.
The call itself. Requesting a completion from a different provider is a small piece of work, and most providers have converged on similar shapes for this.
The plumbing around it: retries, timeouts, logging, cost accounting. All provider-agnostic if written that way.
Your documents and records, which were always yours and always in your own systems if the build was done properly.
That is the part people picture when they hear “swappable,” and it explains why the advice sounds cheap.
What does not port
Four things, in ascending order of pain.
Prompts. The instructions that get sent alongside each request are calibrated to one model’s particular tendencies instead of to the abstract task: what it over-explains, where it needs an example, how it responds to a particular phrasing. Move to another model and the same prompts produce different output, sometimes better and sometimes subtly worse in ways nobody notices for a fortnight. Every prompt in the system needs re-testing, and prompts calibrated over months of production experience carry months of embedded knowledge that has to be re-earned.
Thresholds and calibration. If the system defers to a person when confidence falls below a level, that level was tuned against one model’s confidence behaviour. Another model expresses confidence differently, and training on human feedback is known to push models toward overstating the confidence they report. Carry the old threshold across and you get either a flood of deferrals or, worse, a system that stops deferring on cases it should.
Stored representations of your documents. This is the one that surprises people, and it needs a distinction most discussions skip. If the system searches your material by meaning, every passage was converted into a position by a specific embedding model, and those positions are meaningless to a different one. The embedding model is a separate choice from the model that writes the answers, so changing provider for the writing does not automatically force this. Changing the embedding model does, and then every position has to be recomputed and retrieval quality re-validated, because the new model scores similarity differently. For a large document set that is a real job with a real cost. Retrieval is where the lock-in is deepest, and it is the part of the stack least discussed in the context of switching.
Fine-tuned weights. These do not transfer at all. A model adapted with your examples is specific to that base model, and moving means redoing the adaptation on the new one, assuming the new provider supports it and you still have the training data organised.
Add a fifth that is less technical and often decisive: the provider’s surrounding services. The agent framework, the managed retrieval, the evaluation tooling, the hosted infrastructure. These are genuinely convenient, they are why people adopt a platform instead of an interface, and they have no equivalent elsewhere. The deeper the use, the higher the cost of leaving, and the decision to use them is usually made early by whoever is moving fastest.
What to actually build
Portability is not free, and buying more of it than the situation warrants is its own waste. Three tiers, and most businesses should pick the middle one deliberately.
Thin. Keep your data and documents in your own systems, use the provider’s services freely, accept that switching means a rebuild. Correct for a small internal tool where the cost of rebuilding is a week. Wrong for anything the business depends on.
Practical. One place in the code where model requests are made, so the rest of the system never names a provider. Prompts stored as data rather than scattered through the code, so they can be reviewed and re-tuned as a set. Documents and their source material kept in your own store, so the searchable representations can be regenerated instead of recovered. An evaluation set that can be run against any provider, which is what makes a switch measurable instead of a leap. And provider-specific services used deliberately, with a note of what each would cost to replace.
Heavy. Two providers wired up and both exercised regularly. Expensive, and correct when an outage would stop the business.
In my experience the practical tier adds a small single-digit percentage to the build and turns a switch from a rebuild into a fortnight. That is the trade most businesses should take, and it is a scoping decision, which means it has to be raised before the build rather than discovered during one.
The part that makes it real
An abstraction that has never been exercised is a belief.
The thing that turns portability from a claim into a fact is running the system against a second provider once, deliberately, before anyone needs to, and away from production. Point the evaluation set at the alternative, run the thirty known cases, and look at what breaks.
What that rehearsal finds, reliably, is the provider-specific assumptions nobody knew were there: a response format the code depends on, an option with no equivalent, a prompt that only works because of one model’s habits. It takes a day. Finding the same things during a forced migration, on a deadline, takes considerably longer and happens while the system is degraded.
It also produces the number worth having: what a switch would actually cost, in days, stated in advance. A business that knows that number can make an unhurried decision when a provider changes its prices. A business that does not is negotiating from a position it has never measured.
The version of this that is not about AI
Worth noting because it makes the principle easier to hold.
The same argument applies to the accounting package, the booking system and every platform a business runs on. Can you get your data out, in what format, and what would moving cost. AI providers are a newer instance of an old question, and the reason it gets special attention is that this particular market is moving faster than most, so the interval between forced decisions is shorter.
The related discipline is the same one behind crypto-agility: build so that the component everyone expects to change can be changed, because the alternative is discovering the coupling under pressure.
What to hold on to
Keep the model swappable is right, and the sentence hides the work.
The model ports. The prompts, the thresholds, the stored representations of your documents and anything fine-tuned do not, and the provider’s convenient surrounding services are where the real lock-in accumulates.
The practical version is one place where model calls happen, prompts kept as data, your own documents in your own store, an evaluation set that runs anywhere, and provider-specific services used with a note of what each would cost to replace. Then rehearse it once, against a second provider, before it matters.
Three questions to put to anyone building this: which provider-specific services does this use and what happens to each if we leave, what would a switch cost in days, and has anyone ever actually run this against a second provider. The third question is the whole test. An answer of yes means the abstraction is real. An answer describing the architecture means it is a plan.