AI Vendor Lock-in - How Not to Depend on One Model Provider (Multi-Model Strategy and Plan B)

Vendor lock-in in AI is when switching a model or provider means rewriting the application, retesting everything from scratch and negotiating under deadline pressure. You can't escape it completely, because every model has an expiry date. But you can make a switch take a day instead of a quarter: the model name in configuration, one access layer for several providers, your own test set, a ready plan B and an exit plan written into the contract. Don't ask whether you'll switch models. Ask when - and whether you'll be ready.

Every AI model has an expiry date: recently retired Anthropic models lived 12-16 months, and companies got about 60 days to migrate. I show where provider lock-in lives, how to build an access layer for several models, how tests cut a model switch down to one day, plus a 10-question test.

In this post I show how an AI provider can upset your plans, how much time you really get to migrate (I counted it from the official OpenAI, Anthropic and Google deprecation lists), where lock-in really lives, how to build an access layer for several models, how tests cut a model switch down to one day, and how to check how locked in you are - with a ready test at the end.

Five Ways an AI Provider Can Upset Your Plans

• Model retirement. Claude Sonnet 4.5 launched in September 2025 and will be shut down on 30 November 2026. After that date, requests to it fail.
• Behaviour and API changes in a new model. Newer Claude models return a 400 error when you set temperature to a non-default value, and they also reject prefill, i.e. a pre-written start of the answer. Code that worked for years stops working after a model change.
• Price changes. Gemini 3.8 Flash costs $0.75 per million input tokens until the end of 2026, and $1.50 from 1 January 2027. On top of that, newer Claude models count the same text as about 30% more tokens, so the bill grows even at the same price per token.
• Limits and outages. Rate limits (429 errors) and downtime happen at every provider. Without a second route, your application goes down with them.
• Platform feature shutdowns. This is the least obvious risk. OpenAI shut down the Assistants API (26 August 2026), and on 30 November 2026 it shuts down Agent Builder, the Evals platform and saved prompts. The Videos API with the Sora models was shut down on 24 September 2026 with no named successor. If you built a process on such a feature, you have to rewrite not just the model call but a whole piece of the system.

Lock-in also works the other way: it blocks savings. Claude Haiku 5.5 costs $0.10 per million input tokens (for prompts up to 100k tokens), ten times less than the previous Haiku 4.5. A company that can switch models in a day collects that price cut right away. A company with the model hard-coded in a dozen places collects it a quarter later.

How Much Time You Get to Migrate - an Analysis of Deprecation Lists

I went through the official deprecation lists of the three biggest providers (as of 10 October 2026) and counted how long it takes from announcement to shutdown and how long a model lives:

Three conclusions from this table:

1. 1.Expect at least one migration a year for every AI process. The model you deploy today will most likely be gone in 12-16 months.
2. 2.Two months isn't much if a switch means rewriting code. If the only knowledge of how the integration works sits in one person's head, 60 days can go on just working out what needs to change.
3. 3.Don't use preview versions in critical processes. At Google a preview can live 12 weeks (Gemini 3.1 Flash-Lite Preview: 3 March to 25 May 2026).

Where Lock-in Really Lives

People usually think only about the model. But lock-in has several layers, and the model is usually the easiest to replace:

An embeddings example: Google shut down the text-embedding-004 model on 14 January 2026. A company with a knowledge base of hundreds of thousands of fragments on it had to recompute the whole index with a new model - time and cost nobody had planned for. More on choosing a database in the vector database comparison.

The Abstraction Layer - One Interface, Many Providers

The foundation of independence is one place in the code that all model calls go through. You have three routes:

• The OpenAI-compatible format. Anthropic and Google provide endpoints compatible with the OpenAI SDK, so the same code can talk to different providers after changing the URL and key. Note: compatibility layers don't support every feature (e.g. some caching or reasoning settings), so for a model's full capabilities you'll still want its native SDK.
• A library or gateway. LiteLLM (open source) or gateways such as OpenRouter or Vercel AI Gateway give you one interface to many models, with automatic failover on errors.
• Your own thin layer. A few dozen lines of code that read a list of models from configuration and try the next one on error. Full control, no extra dependencies.

Here's a minimal version of the third route:

import os, time, loggingfrom openai import OpenAI

# order from configuration, e.g. LLM_CHAIN="openai:gpt-6.1-sol,anthropic:claude-sonnet-5-5" PROVIDERS = { "openai": OpenAI(), "anthropic": OpenAI(base_url="https://api.anthropic.com/v1/", api_key=os.environ["ANTHROPIC_API_KEY"]), } CHAIN = [p.split(":") for p in os.environ["LLM_CHAIN"].split(",")]

def complete(messages: list[dict], max_tokens: int = 1024) -> tuple[str, str]: errors = [] for provider, model in CHAIN: t0 = time.time() try: r = PROVIDERS[provider].chat.completions.create( model=model, messages=messages, max_tokens=max_tokens, timeout=30, ) logging.info("llm ok %s/%s %.1fs", provider, model, time.time() - t0) return r.choices[0].message.content, f"{provider}/{model}" except Exception as e: # 429, 5xx, timeout, retired model logging.warning("llm fail %s/%s: %s", provider, model, e) errors.append(f"{provider}/{model}: {e}") raise RuntimeError("all providers failed: " + "; ".join(errors))

Three rules make the difference here: no parameters that not every model in the chain supports (hence no temperature), logging which model actually answered, and a time limit on every call. The backup model doesn't have to be as good - it has to keep the process alive until the main one is back.

Tests as Insurance - How to Switch Models in One Day

The abstraction layer tells you how to switch models. Tests tell you whether you may. Without them every migration is guesswork; with them the decision takes hours:

1. 1.A set of examples from real traffic - 50-200 requests with an expected result or evaluation criterion. How to build one is covered in the post on LLM evaluation.
2. 2.Run on the old and new model - the same examples, comparing quality, response time and cost.
3. 3.Recount cost in the new model's tokens - a different tokenizer can change the bill by tens of percent with the same prompts.
4. 4.Review parameters and prompts - what the new model rejects and what it does differently (longer answers, a different format).
5. 5.Shadow traffic for a week - the new model answers in parallel, but only the test system sees the result. Only then switch.

The same test set also protects you against silent behaviour changes. Researchers from Stanford and Berkeley showed in 2023 that successive versions of the same model could noticeably change results on the same tasks within a few months. That's why in production you pin a specific model version rather than a "latest" alias.

When Your Own Model Is the Plan B

Open models are the strongest insurance: nobody can shut them down or raise the price. Qwen 3.5 and Gemma 4 are under Apache 2.0, DeepSeek V4 under MIT, Mistral Large 3 under Apache 2.0, and the Polish Bielik handles Polish well. They make sense as a backup when:

• the process is critical and can't stop even for an hour,
• data can't leave the company, so you need local infrastructure anyway,
• there are many simple requests, so a small model on your own server is cheaper than the API.

At a few hundred requests a day your own server usually doesn't pay off - a second API provider is a better plan B then. How to run a model locally is covered in the post on Ollama and vLLM.

An Exit Plan in the Contract with Your Contractor

The hardest lock-in to undo isn't with the model provider but with the implementation contractor. Before you sign, check that:

• accounts with AI providers are in your company's name, and the contractor only has access,
• the code, prompts and test set belong to you and live in your repository,
• model names are in configuration, and the documentation describes how to change them,
• the contract describes the handover at the end of the engagement: documentation, access, a support period.

The full list of questions for a contractor is in the post on choosing an AI implementation partner.

The Vendor Lock-in Test - 10 Questions

Answer each question: 0 - no, 1 - partly, 2 - yes. Add up the score.

16-20 points: a model switch is a day's work. 10-15: a switch will take a week or two - start with tests and an abstraction layer. 0-9: every model retirement will be a small crisis for you - start with the first three questions.

The Most Common Mistakes

• The model hard-coded. A switch means searching the whole project and redeploying.
• A "latest" alias in production. The model changes without your knowledge, and the results change with it.
• A process built on a beta or preview feature. Those disappear the fastest.
• No tests before migrating. Without them you don't know whether the new model is better, worse or just different.
• Multi-model for its own sake. Three providers in every process means triple the testing and maintenance. To start, one main model and one checked backup are enough.

---

I help companies build AI systems that survive a model and provider change - from the access layer and test set to an exit plan in the contract. I do this as part of AI consulting and AI app development. Get in touch - I'll start with a review of where the biggest lock-in sits in your system.

Worth reading next:

• How to Choose an LLM in 2026 - OpenAI, Anthropic, Google or Open Weights
• LLM Evaluation (Evals) - How to Measure AI Application Quality with LLM-as-a-Judge
• AI Model API Cost Optimisation
• How to Choose an AI Implementation Partner