ModelRefs / Provider Lock-In — AI Glossary
Provider Lock-In — AI Glossary
The cost and difficulty of moving a workload off one model provider, created by provider-specific APIs, formats, tuning, and operational dependencies.
Overview
Lock-in accumulates quietly: prompts tuned to one model's behavior, provider-specific tool-calling or structured-output formats, fine-tunes that cannot transfer, evaluation baselines tied to one snapshot, and infrastructure built around one SDK. It matters because model availability, pricing, and terms change, and because an incident with a single provider becomes an incident with your product. Mitigations include keeping an abstraction over the model call, storing prompts and schemas independently of any SDK, maintaining a scored second candidate, and rehearsing a switch rather than assuming one is possible. Common mistakes: assuming portability because two providers both expose a chat endpoint, and discovering only during an outage that no fallback has ever been evaluated.
Reference details
| Topic | ecosystem |
|---|---|
| Also known as | vendor lock-in, model lock-in |
| Last reviewed | 2026-06-24 |
Related terms
How it works
- Lock-in accrues as accumulated adaptation rather than as a contractual term, so nothing in the agreement records it and no date marks when it began.
- Prompts are the largest store of it: each one is tuned against one model's behaviour until it works, and that tuning does not transfer even between versions of the same model.
- Provider-specific interfaces harden next — tool-calling shapes, structured-output modes, cache-control directives — each of which ties working code to one vendor's format.
- Fine-tunes are non-portable by construction, since the weights they adapt belong to the provider and the training data mix was chosen for that base.
- Evaluation baselines quietly join the list, because a scored history against one model snapshot is the only evidence of quality, and a switch invalidates the comparison.
- The cost becomes visible only when a switch is forced, which is why rehearsing one is the measurement and not the mitigation.
Example: Itemising a switch, and the part of it that is not lock-in
Price moving a mature deployment. Re-tuning 240 prompts at 40 minutes each is 9,600 minutes, or 160 hours. Rewriting 18 tool schemas into another provider's format at 2 hours each is 36 hours. Three fine-tunes cannot transfer at all and cost about 30 hours each to re-create, so 90 hours. Re-running the evaluation baselines to make the candidate comparable is 20 hours. Building the abstraction over the model call that should have existed is 80 hours. The total is 160 + 36 + 90 + 20 + 80 = 386 hours, which at a $100 loaded rate is $38,600. The useful move is separating that figure into two parts. The 80 hours of abstraction is work worth doing regardless, so the lock-in premium is 386 - 80 = 306 hours, about 79.3% of the total and $30,600 of the bill — pure rework caused by having adapted to one vendor rather than to an interface. Against this, building the abstraction first costs 80 hours and converts the 306 into something much smaller, since prompts and schemas held independently of any SDK move with far less handling. The timing is the other half of the argument. The same 386 hours is a quarter's planned work if the switch is rehearsed, and a critical-path outage if it is discovered.
Commonly confused with
Provider lock-in is not the same as a lack of alternatives, and conflating them produces false comfort. Several providers expose a chat endpoint with similar parameters, so a migration looks like changing a base URL — and then the prompts behave differently, the tool-calling format differs in the details that matter, and the structured-output mode has different guarantees. Portability of the interface is not portability of the behaviour, and behaviour is what was tuned. It is also distinct from a single point of failure, though they overlap. A single point of failure is an availability problem addressable with a fallback that has been tested; lock-in is a cost problem that makes building that fallback expensive. A deployment can have a second provider configured and still be locked in, if the second has never been evaluated on the real workload.
When to use it
Reach for it when:
- As a standing cost to track rather than an event to plan for, since it accrues without any decision being recorded.
- When choosing whether to adopt a provider-specific feature, where the question is what it would cost to unwind.
- To justify an abstraction over the model call early, which was 80 hours of the 386-hour switch and the only part worth doing anyway.
- By rehearsing a switch, which is the only way to know whether the fallback works.
Reach for something else when:
- As an argument against using a provider's best features, which usually earn their lock-in.
- Assumed absent because two providers both expose a chat endpoint, since interface portability is not behavioural portability.
- Considered addressed by configuring a second provider that has never been scored on the real workload.
- Treated as an availability problem, which a tested fallback solves and a rework bill does not.
Continue your research
Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Provider Lock-In — AI Glossary.
Frequently asked questions
What is Provider Lock-In?
The cost and difficulty of moving a workload off one model provider, created by provider-specific APIs, formats, tuning, and operational dependencies.
Is Provider Lock-In the same as vendor lock-in?
Yes — vendor lock-in, model lock-in are common aliases for Provider Lock-In.
What concepts are related to Provider Lock-In?
Closely related concepts include model routing, fallback chain, structured output, function calling.