AI Vendor Lock In: Measuring What It Actually Costs to Switch Models

Swapping one model provider for another is a small code change. Most teams finish it in a day. AI vendor lock in is real, but it does not live in the API call. It lives in the prompts, the evals, the embeddings and the fine-tunes underneath it, and only one of those four can be ported at all.

The short answer

You are less locked in than the phrase suggests, and more exposed than your budget assumes. Moving the API call takes hours. Re-tuning prompts, rebuilding an eval suite, re-embedding a corpus and re-training a fine-tune takes weeks to months. The binding constraint is calibration, not contract.

What lock in means when the vendor is a model

Cloud lock in is a data gravity problem. Your files sit in one provider's storage, egress is billed, and moving petabytes is slow and expensive.

Model lock in works differently, and the difference is the reason most switching estimates are wrong. Very little data has to move. What has to move is a set of calibrations that were tuned, often without anyone noticing, against one model's behaviour.

Those calibrations are invisible in the codebase. A prompt that says "answer only with valid JSON" looks portable. It is portable in the sense that it will run. It is not portable in the sense that it will keep working.

This is the specific thing to hold on to. Model switching cost is not measured in gigabytes or in exit fees. It is measured in how much of your quality assurance you have to redo, and how confident you are in the answer when you finish.

The five layers of switching cost, ranked by how hard they move

Break a production AI system into layers and the cost distribution becomes obvious. It is heavily skewed, and it is skewed away from the layer teams instinctively worry about.

Effort ranges are ordinal, not measured. They reflect the sequence and relative weight of the work, not a benchmarked duration for any particular system. Treat the ordering as the claim and the durations as an illustration.

The two layers that are genuinely cheap

Start with the good news, because it is real and it is under-reported.

The API call moves in a day

Five years of competition has pushed provider request formats toward each other. Messages, roles, system instructions, streaming, tool schemas: the shapes now rhyme closely enough that a well-factored client swaps in an afternoon.

Most major providers also expose an endpoint that accepts requests in a competitor's format. That was a competitive move, not a standards effort, and it is the single largest reason model-layer lock in is weaker than cloud-layer lock in.

The exceptions are worth naming because they are exactly where naive ports break. Anthropic now returns a 400 error if you set temperature, top_p or top_k to a non-default value on its newer models. Any code written against the shared vocabulary of 2024 sends those parameters by habit.

Prompts move, but their reliability does not

A prompt is text. Text copies perfectly. What does not copy is the tuning you did against one model's failure modes.

A January 2026 preprint measured this on structured extraction across six model families. The author reports a cross-model portability gap of 0.4 to 0.6 F1 points, driven mostly by format collapse rather than by any loss of understanding. One model returned clean JSON. Another wrapped the same JSON in prose or fences and failed the parser.

Read that result carefully, because it is a single-author preprint on one task domain and it has not been peer reviewed. What it demonstrates is a mechanism, not a universal constant. The mechanism is that most of the observed gap was recoverable by canonicalising the output, which tells you the new model knew the answer and expressed it differently.

That is my working position on prompt portability. Assume the semantics carry and the formatting does not. Then write your parsers to be tolerant before you migrate, not during.

Evals are where the migration bill actually lands

Here is the part nobody puts in the estimate. Switching model is trivial. Knowing whether you should have is not.

What the suite has to cover before a switch is safe

An eval suite built to answer "is this release better than the last one" is not the same instrument as one built to answer "is this different model acceptable". The first can lean on relative comparison. The second needs absolute thresholds you are willing to defend.

You need coverage of the failure modes you have actually seen in production, the format contracts your downstream systems depend on, and the cases where a wrong answer is expensive rather than merely wrong. Teams that have not built this find out that their confidence in the incumbent model was never measured. It was accumulated.

If you have not written one, the sequence for building it is covered in the walkthrough on how to build an LLM eval suite that survives a model change. Build it before you need it, because building it under migration pressure guarantees you will grade the new model against the old model's habits.

The cost is judgement, not compute

Running evals is cheap. A comparison run against a few hundred cases costs less than an hour of engineering time.

Deciding what counts as a pass is the expensive part, and it cannot be automated away. Someone with domain authority has to look at 50 disagreements between the old model and the new one and rule on each. That is the work, and it scales with how many distinct jobs your system does.

There is a reason this section is short and the claim in it is strong. I have not found a public dataset that measures migration engineering effort across organisations, which means the honest version of this argument is structural rather than quantified.

Embeddings and fine-tunes do not move at all

The bottom two layers are different in kind, not in degree. They are not slow to port. They cannot be ported.

A vector only has meaning inside its own model

Two embedding models can both emit 1,024 numbers for the same paragraph. The numbers describe different geometries, and no conversion function exists between them, because the spaces were never aligned.

Changing embedding model therefore means re-embedding the whole corpus and rebuilding every index. The compute is usually affordable. The risk is the rolling window, when the index holds vectors from two models at once and retrieval quality varies by document age rather than by relevance.

This is also the layer where hosted convenience converts most directly into exposure. Use a provider's embedding API and your retrieval system inherits that provider's model lifecycle. When they retire a version, you reindex on their schedule.

Fine-tunes are the one place the weights matter

A fine-tune of a hosted proprietary model is reachable only through that provider's API. You cannot export the adapted weights, so there is no artefact to carry anywhere.

Open weights are better here, though less portable than the pitch suggests. A LoRA adapter is a small file, but it is bound to the exact base model it was trained against. Researchers describing data-free transfer of adapters across heterogeneous models are working on the problem precisely because direct reuse does not work. Change the base and you retrain, assuming you still hold the training data.

That last clause is where teams get caught. The fine-tuning set is often assembled once, used once, and never treated as a durable asset. Keep it versioned and keep it exportable, and the fine-tune layer drops from a rebuild to a re-run. That, and not the adapter file, is the portable thing. The full comparison of what open weights buy and cost in production is in the review of open weight models against hosted APIs.

Why abstraction layers help less than the pitch

The standard answer to lock in is a gateway. Route everything through one interface, keep providers interchangeable, sleep well.

Gateways are worth running. They are just solving a narrower problem than buyers think they bought.

The pattern in the right-hand column is consistent. A gateway abstracts the interface, and the interface was never the expensive layer. It also imposes a cost of its own, because the feature set it exposes tends toward what every provider supports.

Prompt caching is the clean example. One provider requires you to place explicit cache breakpoints inside the request. Another caches automatically with no code change. Both approaches work, and the code that captures the discount on one of them captures nothing on the other. Route through a common interface and you often forfeit the optimisation entirely, which shows up in the gross margin arithmetic rather than in any outage.

My position is that you should run a gateway for operational reasons and not count it as portability insurance. The framework trade-offs are argued in more detail in the piece on whether to use an orchestration framework or build the thin layer yourself, and the same logic applies to tool interoperability standards: a shared protocol moves the schema, not the behaviour.

You will migrate anyway, on the provider's calendar

All of the above assumes switching is a choice. Frequently it is not.

Anthropic publishes its retirements, and the record is unambiguous. Between 28 October 2025 and 5 August 2026, 9 models were retired from the Claude API. Claude Opus 4.1 was deprecated on 5 June 2026 and switched off on 5 August 2026, a gap of 61 days. Claude Sonnet 4 and Claude Opus 4, both released in May 2025, were gone by June 2026.

OpenAI runs longer stated minimums and has still moved fast on specific surfaces. Its published deprecation schedule shows the Assistants API announced on 3 June 2026 and shut down on 26 August 2026. On the same day it announced that reusable prompt objects would be removed, with the instruction to move that content back into application code.

Note what that second one is. A provider feature that stored your prompts for you was withdrawn, and the migration path was to stop depending on the provider for it. That is the shape of most model-layer lock in: shallow, real while it lasts, and resolved by moving state back to your side.

The notice periods are also not comparable across providers.

Anthropic commits to at least 60 days notice for publicly released models. OpenAI states at least 6 months for generally available models and at least 3 months for specialised variants, with preview models exempt from both. Amazon Bedrock keeps models available for at least 12 months before end of life.

The practical consequence is worth putting in a contract. Notice period is a negotiable term, it is rarely negotiated, and it is one of the few pieces of switching cost you can buy down in advance. The clauses worth asking for are set out in the CFO checklist of AI contract terms, and the provider-by-provider differences in the comparison of model provider terms.

Regulation is moving the same direction for the cloud layer underneath. The EU Data Act permits only cost-based switching charges during its transition, and from 12 January 2027 prohibits switching charges entirely for data processing services. It does not reach prompt tuning or eval rebuilds, which is precisely the point of this post.

Where this argument is weakest

Three places, and the first is the most serious.

The core claim is structural, not measured

I have argued that migration effort concentrates in evals, embeddings and fine-tunes. I cannot point you to a survey that measures engineer-days by layer across a population of firms. That dataset does not appear to exist publicly.

What I can point to is the mechanism: vectors are model-specific, hosted fine-tune weights are not exportable, and formatting reliability is model-specific by measurement. Those are established. The relative weighting between them is judgement, and you should treat the ladder chart above as an argument rather than a finding.

Market share movement is weaker evidence than it looks

The share shift from OpenAI to Anthropic is real and it is the strongest single fact in this post. It is also compatible with an explanation that has nothing to do with easy switching.

Most of that movement may be new workloads choosing a different provider rather than existing workloads migrating. A market growing this fast can reallocate share without anyone actually switching anything. Menlo's figures are shares of spend, not counts of migrations, and they cannot distinguish between the two.

Behaviour drifts even when you stay

The case for portability assumes the incumbent is stable. It is not. Peer-reviewed work in the Harvard Data Science Review found GPT-4's accuracy identifying prime numbers fell from 84% in March 2023 to 51% in June 2023 on the same questions.

A 2026 framework paper on governing updates in the LLM supply chain makes the same argument from the operations side, though its own validation is explicitly exploratory rather than comprehensive. If a version bump inside one provider can move behaviour that far, then the eval work described above is not a migration cost at all. It is the cost of running an AI system, and you owe it whether you switch or not.

That reframing cuts against my own headline. If evals are a standing cost rather than a switching cost, then genuine model lock in is smaller still, and it is concentrated almost entirely in embeddings and fine-tunes.

Frequently asked questions

Where to start this week

Run the inventory before you run the migration. It takes an afternoon and it is useful whether or not you ever switch.

List every place your system encodes an assumption about one specific model. Prompts with model-specific formatting instructions. Parsers tolerant of exactly one output shape. Eval thresholds set by comparison rather than by an absolute bar. Embedding indexes and the model version that built them. Fine-tunes, and whether you still hold the data that produced them.

Then write one number next to each: how many days to rebuild it. Total that column. That figure is your real switching cost, it is almost certainly larger than your team's guess, and it is the only version of this question you can answer for yourself rather than read in a report.

Related reading