Vendor lock-in can grow through provider-specific APIs, model behavior, prompt tuning, tool formats, stored data, pricing commitments, identity systems, and operational knowledge. Even when alternatives exist, migration may require costly changes and new evaluation.
Multi-provider routing and compatibility layers can reduce dependence, but portability must be tested. An application may still rely on a unique capability or behave differently after switching, so recovery plans need real alternative providers rather than only theoretical support.
ELI5
Vendor lock-in means it is hard or expensive to move from one provider to another after a product or workflow depends on that provider's special features. The barrier can be technical, contractual, financial, or based on data that is difficult to export.
For example, a coding team may rely on one provider's bundled model, saved agent context, and unique tools. If access ends, moving may require new keys, rewritten prompts, different integrations, and retraining users rather than one simple switch.
