Should You Build on One AI Provider or Keep a Second Ready?

Should You Build on One AI Provider or Keep a Second Ready?

Build on one, but keep the seam where a second could go. Full portability costs more than most teams admit and buys less than they hope. A single hard boundary between your application and whichever model answers it gives you most of the protection for a fraction of the work.

We get asked this by B2B teams who have just put an AI feature into production and realised how much now depends on somebody else's API. It is a fair worry. It is also frequently answered by building an abstraction nobody needed.

Here is how we would think about it, and what the actual risks are once you look at published vendor policy rather than at the general feeling of unease.

What Does Lock-In Actually Mean Here?

It means the cost of moving, not the impossibility of it. Nothing about a text-in, text-out API traps you the way a database schema or a proprietary file format does. What traps you is everything you built on top of one model's particular behaviour.

Your prompts are tuned to one model. Your evaluation set is scored against one model's output. Your error handling knows one vendor's failure modes. None of that is contractual. All of it is work.

So the real question is not whether you can switch. It is how many days it would take, and whether you would find out something broke only after customers did.

What Is the Risk You Are Actually Insuring Against?

Three things, in descending order of likelihood. The model you use gets retired. The price or terms change. The vendor becomes unavailable or unsuitable for a customer you need to win.

Retirement is the one that actually happens, on a schedule, to everyone. Anthropic's model deprecation documentation describes a lifecycle of active, legacy, deprecated and retired, and states plainly that requests to retired models will fail. It commits to at least 60 days notice before retirement for publicly released models.

The published history shows the pace. Claude Opus 4.1 was deprecated on 5 June 2026 and retired on 5 August 2026. Claude Sonnet 4 and Claude Opus 4 were deprecated on 14 April 2026 and retired on 15 June 2026.

That is the risk you can plan for, and it is the same risk whether you use one provider or five. We wrote about handling it directly in what happens when the model behind your automation is retired.

Does a Second Provider Actually Protect You?

Less than people expect, because the failure you are most likely to hit is not the one a second provider fixes. A retired model means you migrate to a newer model. Usually that is a newer model from the same vendor, because that is the one your prompts and evaluations are already shaped around.

A second provider protects you against the vendor itself becoming unusable. That is a real but rare event, and it is worth weighing honestly against the ongoing cost of keeping two integrations current.

There is one case where it genuinely earns its keep. If you sell to customers who mandate a particular cloud or a particular model provider, a second path is not insurance. It is a sales requirement, and you should treat it as a feature rather than as a hedge.

Does Staying With One Vendor Mean Nothing Changes?

No, and this is the part teams underestimate. Interfaces move inside a vendor too. Anthropic's documentation lists temperature, top_p and top_k as deprecated for Claude Opus 4.7 and later, and states that setting them to a non-default value returns a 400 error on those models.

So a team that never switches providers can still have code stop working because a parameter it passed for two years is no longer accepted. Single-vendor is not the same as stable.

That cuts both ways in this argument. It weakens the case that switching is uniquely painful, and it strengthens the case for having the seam, because you will be doing migration work regardless.

Where Should the Seam Go?

At one module that every AI call passes through. Not a general purpose abstraction layer that models every provider's features. One place in your codebase that owns the model name, the request shape, the retry policy and the parsing of the response.

The test for whether you have it is simple. Search your repository for the model name. If it appears in more than one file, you do not have a seam, you have a habit.

Keep the abstraction thin. The moment it tries to paper over genuine differences between providers, it becomes its own maintenance burden and starts blocking you from using the features you pay for.

An AI gateway can serve as this seam if you prefer to buy it, which is the trade we looked at in whether your web team needs an AI gateway.

What Should Be Portable No Matter What?

Your evaluation set, your prompts as data rather than as code, and your tool definitions. Those three are what make a switch a week instead of a quarter.

The evaluation set matters most. If you have fifty real inputs with known-good outputs, you can test any model against them in an afternoon and have an evidence-based answer. Without it, every migration is a guess followed by a customer complaint.

Tool definitions are more portable than they used to be. The Model Context Protocol is an open standard for connecting AI applications to external systems, and its documentation describes broad support across clients including Claude, ChatGPT, Visual Studio Code and Cursor. Building your integrations as MCP servers means the tools survive a change of model.

We think that is the most underrated portability move available right now, and it is the point we made in what MCP servers mean for web teams.

What Does Multi-Provider Cost You?

Twice the surface area and half the depth. Two sets of credentials, two rate limit regimes, two sets of quirks to learn, and prompts tuned to neither model particularly well because they have to work on both.

There is also a quieter cost. Teams running two providers tend to use the lowest common denominator of features, because anything else breaks the symmetry. You end up paying for capabilities you have designed yourself out of using.

If you are a small team, that is usually the decisive argument. Depth on one provider beats shallow coverage of two, and the seam gives you the exit without the ongoing tax.

When Should You Genuinely Run Two?

Four situations, in our view. A customer contract requires it. You have a workload where one provider is clearly better and a different workload where another is. You are large enough that a few hours of downtime has a measurable cost. Or you are actively mid-migration.

Note that three of those four are not about fear. They are about a specific, present requirement. That is the bar we would hold it to.

Running two because it feels safer, with no named requirement behind it, is how teams end up maintaining an integration they have not tested in six months. An untested fallback is not a fallback.

How Do You Keep the Exit Real?

Test it on a schedule. Once a quarter, run your evaluation set against a model from a different provider and record the result. You do not have to switch. You just have to know what would happen.

Also keep an eye on retirement dates in your calendar rather than in your inbox. Anthropic publishes tentative retirement dates for active models, and equivalent information exists for other providers. A date you have written down is a plan. An email you will get 60 days out is a fire drill.

And keep a short written note of what would have to change. Which prompts, which parsing, which tests. Two pages is enough, and it turns a scary unknown into a tracked piece of work.

Where Does That Leave the Decision?

Pick one provider, go deep, and pay for the seam rather than for the second integration. Keep your evaluations and your tools portable, because those are what actually cost you time in a move. Add a second provider when something concrete requires it, not when something vague worries you.

The honest summary is that model choice is less sticky than most infrastructure decisions you will make this year, and your own accumulated tuning is the real lock-in. That is worth knowing before you spend a month building an abstraction.

If you want help placing that seam properly, or working out whether your AI features are as portable as you think, we are happy to take a look. You can find us at phoenix.studio.