--- title: "Why I assume I will change AI providers" url: https://rytovdigital.com/blog/assume-you-will-change-ai-provider published: 2026-10-10 updated: 2026-10-10 author: Oleksii Rytov --- I assume that whichever AI provider I build on this year is not the one I will be using in three years. Not because of anything I know about the providers. Because of how much money is being spent on the thing underneath them. Most people meet AI as a chat window on a phone, and from there it looks like a finished product. Underneath it there are data centres, power contracts, network capacity, chips and the software to schedule all of it, being built right now at a scale that makes the chat window look like a side effect. I do not know how that settles. Some of those companies will get cheaper and some more expensive, a few will be bought, and at least one will quietly stop being good at the specific thing you were using it for, which is the version that actually catches people out. None of that is a reason to wait. It is a reason to keep the cost of changing your mind low, which is a smaller and more boring task than it sounds. ## Three different things people call switching They are not the same size, and treating them as one is why the advice online is confusing. **Changing the model inside one provider.** Close to free. Same API, same keys, different string in a config file. You re-check your prompts because the output moves, and that is most of the work. **Changing the provider.** This is where the arguments live. If your code calls the provider directly in twenty places it is a real project, and if every call goes through one place it is an afternoon plus the prompt re-checking. Nothing clever is needed for that, just the discipline not to scatter the calls in the first place. **Changing a vendor that holds something for you.** Money, a queue, customer history, stored credentials. Expensive regardless of how well the code was written, because what makes it expensive is not in the code. ## The expensive kind, with numbers I moved a large e-commerce platform [from one payment provider to another](/blog/braintree-to-stripe-migration-cost). Four to five months, then two or three more of fixing things nobody predicted. Saved cards had to be transferred between the two companies, both had to run in parallel for months, and the refund policy decided the earliest date the old one could be switched off. I also moved a system from a hosted message queue to Kafka. Technically that is a small job. The hard part was downstream: other teams reading from it, a period of writing to both, keeping the two in sync, and bugs landing on people who had not chosen the migration and did not want it that quarter. Neither was hard engineering. What made them long was that other people depended on the thing, and that is also true of the next one. An AI provider mostly does not hold anything for you today. The prompts are yours, the output lands in your own database, and the provider is closer to a supplier than a landlord. That is the cheap kind of switch, and it is only true while it is true. The moment you start keeping state inside a provider's product instead of your own, it moves into the expensive category without anybody announcing it. ## What I actually do Everything the assistant can touch in my own systems goes through tools I wrote, on my own database. The provider sees a request and a list of tools, and that is all it sees. The provider and the model are configuration rather than code. I think a system doing real work should be able to fall back to a second provider from that config, so that a bad morning at one company is a setting change instead of a day without the thing. I have not had to use that in anger, so take it as a design I am confident about rather than something I have been through. ## What the layer costs you It is not free, and the people who sell the idea tend not to mention the bill. You end up with the shared subset of what providers offer. Features specific to one of them arrive late behind your own abstraction, or never, and some of those features are good. Somebody maintains the layer, and in a one-person business that somebody is you, which adds one more thing that only one person understands. The version I would defend is narrow: keep the calls in one place, keep your data in your own database, keep the provider name in config. Most of the benefit sits in those three and they cost almost nothing to do from the start. Anything heavier can wait until there is a reason for it, and there often is not one. ## When I would not bother If you use one feature of one provider and moving would take a day, do nothing at all. A day of switching cost is not worth designing around. The layer earns its keep when what it protects is slow to rebuild. Your data, your processes, the habits people have built around them. So the question to ask is not really about the provider. It is how much of the business would have to be put back together if that provider went away next month, and for most small companies the honest answer is a lot less than they fear. ## What I do not know Whether any of this matters in five years. Providers might converge on a common interface and the question disappears, or one of them gets far enough ahead that everybody takes the lock-in on purpose and is fine. What I am reasonably sure of is that the price and the capability of what you are integrating will keep moving for a while yet, in both directions. Signing a long agreement against something that is still moving seems like the wrong order of operations to me, though I would understand someone deciding otherwise if the discount were large enough.