One model is not an AI strategy
- Models retire on the vendor's calendar, and the notice windows are documented: as little as two weeks for previews, sixty days to six months for released models, depending on provider.
- A multi-model strategy means a stable task contract, routing justified by business requirements, and evidence kept outside every vendor's walls. Sending every task to five models is a spending habit, and a different thing entirely.
- Compatibility is a spectrum. Some providers accept OpenAI-shaped requests with a base URL swap; others run native-first formats with partial compatibility layers; compatible surfaces still carry proprietary extensions that become load-bearing quietly.
- The Provider Dependency Map inventories where your system is coupled: named models, provider-specific parameters, proprietary features, vendor-resident data, and vendor-tied evaluation.
- One provider is often the right answer. The strategy is knowing your exit works before you need it, and that knowledge costs one test a quarter.
Somewhere in your codebase right now there is a model name in a string. That string has a retirement date, and you do not set it. The providers publish this plainly: Anthropic's deprecation documentation commits to at least sixty days' notice before a released model retires, and requests to retired models fail. OpenAI's policy runs from at least six months for generally available models down to two weeks for previews. Both pages, as they stand in July 2026, list steady histories of models that no longer answer.
None of that is an accusation. The vendors publish schedules, name replacements, and ship migration guides, which is more courtesy than most enterprise software ever offered. The point is simpler: a system coupled to one provider inherits that provider's calendar, pricing, policy, and roadmap. When leadership asks what the AI strategy is and the answer is a vendor's name, the strategy is whatever that vendor does next.
The strategy
A multi-model strategy is a stable task contract with portable evidence. Define the work independent of any provider, route only where business requirements justify it, and keep your records and evaluation outside every vendor's walls. Design the exit test before you need it.
The vendor clock, in the vendors' own words
Read the deprecation pages the way a risk officer would. Anthropic's lifecycle runs Active, Legacy, Deprecated, Retired, and the documentation is blunt that deprecated models “are likely to be less reliable than active models.” Retirement reaches below the model level: on newer Claude models, three long-standing request parameters now return errors when set to non-default values, meaning even the shape of a request moves. OpenAI has migrated whole API surfaces, with Assistants API users directed to newer Responses and Conversations APIs. And Perplexity's chat completions reference carried, on the day I fetched it, a banner marking that entire endpoint deprecated in favor of a newer agent API. In this market, migration is the maintenance schedule.
What “compatible” actually covers
The common comfort is that everything speaks OpenAI's dialect now, so switching is a base URL away. The truth is a spectrum, and it is worth walking. At one end, xAI's documentation genuinely shows the OpenAI client with a swapped base URL. In the middle, Perplexity accepts OpenAI-shaped requests and then extends them with proprietary search controls and response fields (citations, search results, filters) that do not exist elsewhere; build on those and the compatible endpoint is compatible in shape only. Build a parser on that citations array and point the same code at another provider: the field simply is not there. Google makes the same point from the other direction: the Gemini API reference documents a native-first format with its own auth and recommended endpoints, while a separate OpenAI-compatibility endpoint covers a subset of the surface for easy first calls. The pattern is consistent everywhere: compatibility, where it exists, covers the request shape. It never covers the feature set, the failure behavior, or the quality profile of what comes back. Those you discover only by testing, which is the whole argument for owning the test.
The task contract
Here is the pattern I run, in a production research system and in my own editorial instrumentation, across OpenAI, Anthropic, Gemini, Perplexity, and Grok. Every AI task gets a contract written in my schema, never a vendor's: what goes in, what must come out, what quality gates apply, and what the legitimate non-success states are. Concretely, a contract for a support-ticket summarization job reads: input, the full ticket thread; output, a five-sentence summary plus a category from our taxonomy; quality gate, the category must exist in the ticket system; failure state, “insufficient context,” flagged to a person. Nothing in that contract names a model or a vendor. Providers plug into that contract through adapters, meaning thin translation layers between the contract and one provider's API, which normalize every response, and every failure, into records I own. A provider that errors is recorded as a failed provider, never silently patched over, because the record is what makes providers comparable at all. The contract is what makes a model swap an adapter change instead of a rewrite, and normalized records are what make quality claims testable instead of vibes.
The Provider Dependency Map
You cannot manage coupling you have not inventoried. The map is five questions asked of every AI workload.
| Dependency class | What to inventory | The question that reveals coupling |
|---|---|---|
| Named models | Every model string in code and config | What retires, and what is its notice window? |
| Request surface | Provider-specific parameters and API shapes | What breaks if the shape changes? |
| Proprietary features | Search fields, tool formats, caching, extensions | Which features have no equivalent elsewhere? |
| Data residency | Prompts, outputs, embeddings, logs held only by the vendor | What evidence could we not take with us? |
| Evaluation | Quality baselines tied to one provider's outputs | Could we score a replacement fairly tomorrow? |
The last two rows are where enterprises get quietly stuck. Losing a model is an adapter change. Losing your only copy of the evidence, or having no provider-neutral way to judge a replacement, is the coupling that turns a migration into a crisis.
When one provider is the right answer
Often, and it deserves saying plainly. A small team with a uniform workload should not run two vendors for sport. A product genuinely built on one provider's distinctive capability has a load-bearing dependency, and pretending otherwise wastes money. The multi-provider tax is real: two sets of quirks, two evaluation baselines, normalization code to own, and more surface to secure. Portability is bought with engineering, and sometimes the price is wrong.
What stays non-negotiable is cheap: the task contract in your own schema, the evaluation set in your own repository, and an honest answer to the notice-window question. Single provider by choice, with a tested exit, is a strategy. Single provider by accretion is an exposure with a calendar attached.
The exit test
The exit-readiness scorecard is one workload, once a quarter. The cadence is a practice heuristic with reasoning attached: a quarter sits inside the six-month floor of the longest common notice window with margin to act, and preview-tier windows run far shorter, so treat quarterly as the floor. Pick a real task. Route it through a second adapter, any capable alternative. Score both providers on your own evaluation set, in your own records. Time the work it took, and write down what broke: a prompt that leaned on one vendor's behavior, a feature with no equivalent, an evaluation that could not run without one provider's output format. Each breakage is a coupling you now know about, and most are cheap to fix while they are small. The scorecard's one number is the honest answer to a board-grade question: if our provider's terms, pricing, or model lineup changed inside our shortest notice window, how long would we need? If the answer is “we do not know,” the strategy is a vendor's name.
Questions worth asking next
What is a multi-model AI strategy?
A design discipline rather than a purchasing quota. The core is a task contract: your definition of each AI task's inputs, outputs, quality gates, and failure states, written in your own schema so any capable model can serve it through an adapter. On top of that sit routing decisions justified by real requirements (cost, quality, latency, policy), records and evaluation kept outside every provider, and an exit test that proves the portability claim. Whether one model or four serve the contract this quarter is an implementation detail.
Is vendor lock-in actually a risk with AI providers?
It is an operating characteristic, documented by the vendors themselves rather than alleged by critics. Providers retire models on published schedules. OpenAI's policy provides at least six months of notice for generally available models and as little as two weeks for previews; Anthropic commits to at least sixty days before retiring released models. Beyond models, Anthropic has deprecated request parameters and OpenAI has migrated whole API surfaces. The vendors supply migration guides and replacements, so no malice is involved. The risk is coupling your system to a clock you do not control.
When is a single AI provider the right choice?
Often. A small team with a uniform workload, no regulatory pressure for provider diversity, and genuine dependence on one vendor's distinctive feature should not pay the multi-provider tax: two sets of quirks, two evaluation baselines, normalization code, and more security surface. The discipline that still applies is cheap: keep the task contract and evaluation set in your own schema, know your notice window, and run the exit test occasionally. Deliberate single-sourcing with a tested exit is a sound strategy.
Sources
- Anthropic, "Model deprecations" documentation. https://platform.claude.com/docs/en/about-claude/model-deprecations
- OpenAI, "Deprecations" documentation. https://developers.openai.com/api/docs/deprecations
- Google, Gemini API reference. https://ai.google.dev/api
- Perplexity, "Chat Completions" API reference. https://docs.perplexity.ai/api-reference/chat-completions-post
- xAI, API documentation overview. https://docs.x.ai/docs/overview
About the practice behind this guide
I am Bob Michaels, a Web and AI Systems Architect in Austin, Texas. I have built the web since 1994, and today I run AI visibility measurement, complete web presence transformations, and custom AI system builds for organizations that want one accountable owner across all three. The dependency map and exit test above are the first working session of a vendor-neutral architecture review.
Evaluating me for an AI leadership role instead? The work record is here.