What Moves When You Change AI Providers

You can always switch the AI provider behind your agent. It is true, and it is worth knowing what it costs before you rely on it. Changing the model is a config line. What takes the time is everything built around it: the instructions the agent follows, its connections to your tools, and the testing that proves it still works. If a provider retires your model, the warning you get runs from six months down to two weeks. This is what a switch involves, what forces one, and what to ask before you commit.

You can always switch the AI provider behind your agent. It is true, and it is worth knowing what it costs before you rely on it.

Changing the model is a config line. What takes the time is everything built around it: the instructions the agent follows, its connections to your tools, and the testing that proves it still works. If a provider retires your model, the warning you get runs from six months down to two weeks.

This page covers what a switch actually involves, what forces one, and what to ask before you commit to a provider. It describes how providers behave and how a setup handles a move. It does not rank the models.

What actually changes when you switch AI providers?

Six parts of a running agent setup change with the model, and the model call is the smallest of them.

An agent is a model wrapped in a setup: instructions, tool connections, a search index, a set of tests, and an operating routine, all shaped around one provider's behaviour. Point it at a different model and each of those meets something that responds a little differently.

• The instructions. The prompts that tell the agent how to work are tuned to one model, down to how it phrases things, when it uses a tool, and when it holds back. Another model reads them differently, so they get re-tuned. The symptom of skipping this is small at first: replies formatted the wrong way, a tool called with the wrong input, a different answer in exactly the cases the instructions were written to handle.
• The tool connections. Each provider has its own format for how an agent calls your tools, including how it passes a name, a date, or a file. The connections get rebuilt to the new format and re-tested one by one, because a connection that looks fine can fail on an edge case.
• The keys and endpoints. New credentials, new addresses, different rate limits. This is the part a good setup makes quick, because the provider is a setting rather than something written all through the code.
• The saved history and search index. The stored conversations and the index built from your documents sit in a format tied to the old model. The index in particular is usually rebuilt from scratch with the new one, and that cost grows with how many documents it holds.
• The testing. The set of checks that tell you the agent still works was run against the old model. The checks carry over; the results do not, so everything gets re-run. The differences show up in the edge cases the checks were written to catch.
• The changeover. For a period the new model runs alongside the old one while you confirm it behaves, before you move real work across. A setup with no test checks has to do this the hard way, one live task at a time.

How much warning do you get if your model is retired?

Between six months and two weeks, depending on the provider and how mainstream the model is.

OpenAI commits to at least six months' notice before retiring a generally available model, at least three months for specialised variants, and as little as two weeks for preview models. Its own guidance is that preview models should not sit under work you cannot move quickly.[1]

Anthropic commits to at least 60 days' notice before retiring a publicly released model, tells active users by email, and keeps the retired model's weights preserved. Claude Opus 3 was retired on 5 January 2026 as the first model to run that full process.[2]

Two things follow for a buyer. A model built into a setup you cannot move quickly is a risk with a clock on it, and the clock can be two weeks if someone picked a preview model. And if you run through a hosted platform like Azure or Amazon Bedrock, that platform sets its own retirement schedule on top of the model provider's, so the warning you get is whichever of the two is shorter.

Why can't you just point it at a new model?

Because the instructions the agent runs on were written against one model's habits, and a different model does not follow them the same way.

A prompt that gets one model to draft a reply in the right tone, call the right tool, and stop when it should will get a different model to do something close but not identical. You see a different format, a tool called with the wrong input, a different answer in the cases the prompt was written to handle. So the instructions get a pass with the new model in the loop, and every tool gets re-tested.[3]

It is not a rewrite from nothing. It is a review of every instruction and every connection with a new model that responds slightly differently. That is real work, and it is the reason "just switch the model" is never just that.

How long does a provider switch take?

Anywhere from an afternoon to a few weeks, and three things decide where you land.

The number of tools. Each connection to a tool the agent uses, such as email, calendar, CRM, or a project tracker, gets rebuilt and re-tested. Two tools is quick. A dozen is a project.

The size of the document index. If the agent searches a large set of documents, that index is rebuilt with the new model, and the time scales with how much is in it.

How well the setup is written down. If the instructions, connections and tests exist in a form another person can follow, the switch is a task list. If they live in one person's head, the first job is reconstructing what the setup does, and that is where most of the time goes.

A small agent with two tools and no document index can move in a day. A setup running several workflows across a dozen tools with a big index is a two-to-four-week job. Knowing which one you have is the point of asking the questions further down before you commit.

Whose job is the switch, yours or your provider's?

With a done-for-you setup, most of the switching work sits with the provider. The decision and the data stay with you.

If a setup partner built your instructions and tool connections, re-tuning them for a new model is their work, not a change order you pay for on top. What stays with you is narrower:

• The decision. Whether to switch, and when.
• Access to your data. Providing the history and documents that need rebuilding.
• The contract terms that let your data leave in a usable form.
• The downtime call. Accepting the changeover window.

From your side, a well-run switch is quiet. The partner flags the retirement or the reason for the move, re-tunes the instructions and rebuilds the connections behind the scenes, and runs the new model alongside the old one for a week or two. You get a short report showing the tests pass, you sign off, and real work moves across. The visible part is a review and a sign-off, not a rebuild you have to manage.

This is why lock-in is not really about the model. You are not tied to a model. You are tied to the setup around it, and how portable that setup is depends on whether it was built to be handed over. YardWork stays involved after launch, so a provider switch is work we handle, not a job that lands back on you.

What forces a switch?

Five things, and only one of them comes with the notice period.

• A retirement. The provider ends the model. You get the six-months-to-two-weeks warning and a replacement that behaves differently. This is the one case you can plan for calmly if the setup is portable.
• A price rise. The provider raises the price the setup's running cost was built on. No notice period covers this; your lead time is however long the budget can absorb the new rate while a move is arranged.
• A terms change. The provider changes its data-handling terms or where it processes data, the kind of change covered in AI data residency. If the new terms do not work for your obligations, the timeline is set by when the change takes effect, not by you.
• An outage. Sustained downtime or a drop in answer quality forces a move on the shortest timeline of all, because it is already costing you every day it continues.
• The provider shuts down or is acquired. A smaller provider folding into a larger one can bring a new price, new terms, and a migration deadline at once. The warning is whatever the new owner decides to give, which is rarely the full retirement window.

Only the first has a guaranteed warning. The other four are why a portable setup is worth having even when no switch is planned.

What should you ask before you commit to a provider?

Three questions, before you sign, not after. They decide whether a future switch is a task list or a rebuild. The rest of the evaluation, covered in how to choose an AI implementation partner, matters too, but these three are specific to lock-in.

1. Can my data be exported in a usable form? The conversation history and the documents the agent works from should be able to leave in a standard format. Get that in writing.
2. Who handles a model switch, and is it included? A partner who has done one has a concrete answer: the instruction pass, the tool re-tests, the changeover window. A partner who treats it as hypothetical is telling you it will be billed separately.
3. Is the setup written down? The instructions, the tool connections, and the tests should exist in a form another team could pick up. If they only live in one person's head, that is the lock-in.

None of this removes the work a switch takes. It turns it into a scoped job with a known shape instead of a surprise rebuild.

What this page does not cover

This page describes how a provider switch works and how a setup handles one. A few things sit outside that.

• It does not rank the providers. Which model is best for your work is a separate question. This page is about what moving between them involves.
• Provider policies change. The OpenAI and Anthropic notice periods were current in early September 2026, and both providers revised data terms in August 2026. Confirm before you rely on a number.
• The size of the work varies a lot. A simple single-instruction agent moves in an afternoon. A setup with a dozen tools and a large document index moves over weeks. The shape is the same; the scale is not.
• It assumes the switch is planned, not an emergency. An outage that forces a move in a day is a different situation, handled by whoever built the setup rather than by working through this at your own pace.
• The figures quoted are provider policy, not guarantees. A single contract can set shorter or longer terms; check yours rather than relying on the default policy.

Frequently asked questions

What happens when you switch AI model providers?

The model call itself is a one-line change. What has to be redone is the setup around it: the instructions the agent follows get re-tuned for the new model, the tool connections are rebuilt to the new provider's format and re-tested, the saved history and search index may need rebuilding, and there is a changeover period where the new model runs alongside the old one until it is trusted.

How much notice do you get before an AI model is retired?

OpenAI's published policy is at least six months for a generally available model, at least three months for specialised variants, and as little as two weeks for preview models. Anthropic gives at least 60 days before retiring a publicly released model. Preview and experimental models from any provider can go with much less warning.

Does an abstraction layer remove AI provider lock-in?

It helps with the smallest part. An abstraction layer makes swapping the model endpoint clean. It does not re-tune instructions written for one model, rebuild tool connections to a new provider's format, or move a saved history and search index. Most of the switching cost is in that work.

How do you avoid being locked into one AI provider?

Keep the instructions, tool connections and test cases documented and portable, in a form another team could pick up. Route model calls through one place so the provider is a setting. And put a data-export right in the contract so your history and documents can leave in a usable format.

Notes

Sources retrieved 1 September 2026.

1. OpenAI model deprecation policy commits to at least six months' notice for generally available models, at least three months for specialised variants, and as little as two weeks for preview models: OpenAI API deprecations documentation. Most recent deprecation notices on the page dated 26 August 2026; re-verify before quoting.
2. Anthropic model deprecations: at least 60 days' notice before retiring a publicly released model, email notice to active users, retired model weights preserved; Claude Opus 3 retired 5 January 2026. See Anthropic model deprecations documentation and Anthropic deprecation commitments.
3. On instructions, tool connections and tests being tied to one model, and portability being an architecture choice: Braintrust on avoiding LLM provider lock-in and NHI Mgmt Group on avoiding LLM provider lock-in.

The list of parts describes a common agent setup and should be checked against your own.