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
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.