Vendor lock-in with AI providers: how to keep your options open
Models change monthly and providers come and go. How to build AI features so that switching providers is an afternoon rather than a rewrite.
The short answer
The AI provider you build on today may be more expensive, less capable or differently governed in a year, and a better option will almost certainly have appeared. Lock-in is what stops you following that: prompts tuned to one model’s quirks, provider-specific features woven into your code, your data and history held in the provider’s systems, and no evaluation set to tell whether an alternative is better. Portability is a set of habits rather than a product: prompts and evaluation in your repository, retrieval in your own index, a thin layer between your code and the provider, and provider features used only where the gain is clear and the exit is written down. The test is simple: could you switch the model behind a feature in an afternoon and know whether it got better or worse?
Where lock-in comes from
| Source | What it looks like | Portable alternative |
|---|---|---|
| Prompts | Written against one model’s behaviour, never tested elsewhere | Prompts in your repository, tested on two providers at least once |
| Provider features | Agent frameworks, hosted memory, proprietary tool formats woven through the code | A thin adapter layer; features used at the edges, not the core |
| Data | Documents, embeddings, conversation history stored only in the provider’s systems | Your own index and database, in your accounts |
| Evaluation | No test set; quality judged by feel | An evaluation set you can run on any model |
| Contracts | Long commitments for discounts before usage is understood | Short terms until volume is known |
The portability habits
- Own the prompts: version-controlled, documented, tested against your evaluation set.
- Own the index: retrieval from a database or search service in your account, with embeddings you can regenerate.
- Route every call through an adapter so the provider is a configuration value.
- Keep an evaluation set and run it on at least two providers once a quarter.
- Use provider features deliberately: for each, a note of what it saves and what a switch would cost.
- Keep contracts short until usage is understood, then negotiate from data.
When lock-in is worth it
Sometimes a provider’s specific feature saves months of work or offers a capability nobody else has yet. Taking it can be right. The condition is knowing: write down what it saves, what the switch would cost, and how you would detect that it is time to switch. Lock-in chosen with an exit plan is a trade; lock-in discovered during a price increase is a trap.
What this means for you
Build AI features so the provider is a setting: prompts and evaluation yours, retrieval yours, an adapter in between, provider features at the edges with a written exit. Run the evaluation on an alternative every quarter. Then when a better or cheaper model arrives, which it will, you switch in an afternoon and measure the difference, instead of discovering how much your architecture belongs to someone else.
Frequently asked questions
Is lock-in with AI providers worse than with other software?
It is faster-moving. Models improve and cheapen monthly; a provider that leads today may not next year; terms and prices change. A business locked to one provider cannot follow the improvements or negotiate. The good news is that the core of most AI features, instructions plus retrieval, is portable by nature if built that way.
What provider-specific features are worth using anyway?
Ones that save real engineering time or offer a capability with no equivalent, where you understand what a switch would cost. Structured output modes, batch processing and caching are usually fine because equivalents exist. Deep dependence on a provider's own agent framework, memory or hosted data store is where the exit gets expensive.
How do we know if we are locked in already?
Try the afternoon test on paper: list what would have to change to run the feature on a different provider. If the answer is the endpoint and a retest against your evaluation set, you are portable. If the answer includes rewriting prompts, moving data out of the provider and re-implementing features, you are locked in, and it is worth knowing the price.