Avoiding AI vendor lock-in: a portability checklist
Lock-in sits in several layers. A checklist of what to abstract (API layer, prompts, evals, embeddings, data) and what vendor docs say about switching.
Lock-in to an AI vendor is not one decision; it accumulates in several layers. The goal is not to avoid commitment but to keep the cost of leaving known. The vendor documentation cited below is living documentation and can change, so verify before relying on it.
What vendors say about switching
Several providers offer an OpenAI-style API so that existing code can be pointed at them. That lowers the cost of trying a model, but the documentation is candid that it is not full portability:
Anthropic describes its compatibility layer as "primarily intended to test and compare model capabilities" and "not considered a long-term or production-ready solution for most use cases." Fields such as
strictfunction calling are ignored, and prompt caching is not supported through it [1].The same page warns that prompts tuned heavily for OpenAI models are "likely to be well-tuned to OpenAI specifically" and may need reworking [1].
Google's Gemini API lets you use OpenAI libraries by changing the API key, base URL and model name, but marks that support as beta, and parameters outside its documented list are "silently ignored" [2].
OpenAI recommends its Responses API for new projects. It stores state by default and uses a different structure from Chat Completions, so function calling, multimodal inputs and streaming need code changes when migrating [3].
"Silently ignored" is the phrase to remember: a switch can appear to work while dropping a feature you relied on.
The portability checklist
Layer | What to abstract | Cost of switching if you don't |
|---|---|---|
Model API | One internal interface; vendor-specific parameters in config | Rewrite calls for tools, streaming, structured output [1][3] |
Prompts | Store in version control, separate from code, with notes on model assumptions | Re-tuning and re-testing [1] |
Evals | A vendor-neutral test set run against any model | You cannot tell whether the new model is as good |
Embeddings and vector store | Record the embedding model per index; keep source documents | Re-embedding the corpus, since dimensions differ by model (1536 vs 3072 for two OpenAI embedding models) [4] |
Data and state | Keep conversation history and documents in your own storage | State held only in a vendor's store must be exported or rebuilt [3] |
Using an open store such as pgvector, which keeps vectors in Postgres alongside your other data [5], is one way to keep the index under your control.
How to use this
Build the eval set first. It is the one asset that makes every other switch measurable.
Run your top use cases against a second vendor each quarter, even if you do not switch.
Check data export and deletion options before you commit, not at exit.
Switching will still cost something. The checklist makes that cost an estimate, not a surprise.
Sources
- OpenAI SDK compatibility Anthropic documentation, 2026-06-04. platform.claude.com/docs/en/api/openai-sdk
- OpenAI compatibility Google AI for Developers (Gemini API), 2026-06-04. ai.google.dev/gemini-api/docs/openai
- Migrate to the Responses API OpenAI documentation, 2026-06-04. developers.openai.com/api/docs/guides/migrate-to-responses
- Vector embeddings guide OpenAI documentation, 2026-06-04. developers.openai.com/api/docs/guides/embeddings
- pgvector: open-source vector similarity search for Postgres pgvector (GitHub), 2026-06-04. github.com/pgvector/pgvector
