Perspectives
You do not have to bet on one AI provider
Changing models should be a one-word edit.
By Ehsan Gazar, 22 October 2026
Your team spent a month choosing an AI provider. You compared prices, ran a few tests, and signed up.
Three months later a different provider releases a model that is better at exactly your task. Or cheaper. Or both.
Switching should be easy. It rarely is.
The choice of provider feels like a one-time decision. It is not. It is a decision you will make again every few months, for as long as these models keep improving.
Why switching is harder than it looks
Each provider has its own interface. The request has a different shape, the errors have different names, and the streaming format is not quite the same.
So the first integration gets written against one provider's library. Then a second team builds on top of it, and a third.
By the time a better model appears, changing provider means touching every service that calls it. Each one needs new code, new tests and a new key.
Most teams look at that list and decide the old model is good enough. The better model stays untried, not because it was tested and rejected, but because trying it was a project.
One endpoint in front of every model
Vatan Gateway puts one endpoint in front of models from many providers. It speaks the same request format as OpenAI's chat completions, which most AI libraries already support.
Your code sends a request to one address with one key. The model is a field in that request.
curl https://gateway.vatan.one/v1/chat/completions \
-H "authorization: Bearer $VATAN_API_KEY" \
-H "content-type: application/json" \
-d '{"model": "anthropic/claude-sonnet-5", "messages": [{"role": "user", "content": "..."}]}'
To try a model from another provider, you change the model name. The request, the key and the code around it stay as they are.
That turns the comparison into an afternoon. Send the same requests to two models, read the answers side by side, and decide.
A name your code keeps while the model changes
Even a one-word edit is a deploy when the model name is written into every service.
A route moves that decision out of the code. It is a name of your own, such as cheap-summariser, standing for an ordered list of models. Your code sends the route name where a model name would go.
The gateway tries the models in that order until one answers. The response says which model answered, and which were tried first.
Changing the model behind a route is a setting, not a release. The team that owns the decision changes it once, and every service using that name follows.
It also means a provider outage is a slower answer rather than an error, if the route lists a model from a second provider.
A comparison on your own work
A model that wins a public benchmark has not yet been tested on your work.
The useful test is narrow. Take twenty real requests from the task you care about, with the private details removed. Send each one to the current model and to the candidate.
Then give the answers to the person who owns that task, without saying which model wrote which. They know what a good answer looks like better than any score does.
A cheaper model is only cheaper if you can see the bill.
Every call through the gateway is recorded with its model, its tokens, its cost and how it ended. The usage screen shows it by key and by model.
So a comparison does not stop at the answers. You can see what a week of the new model cost against a week of the old one, for the same work.
A model that is slightly better and three times the price may still be the wrong choice for a task that runs ten thousand times a day.
Each key also has its own limits. A team testing a new model can have a key with a small budget, which stops at that budget rather than surprising anybody.
What stays the same when the model changes
Some things should not move every time the model does. Who can call it, how much they can spend, and where the record of each call lives.
With one endpoint, those live in one place. The keys, the limits and the usage record stay the same while the model behind them changes.
That is what makes the next decision cheap. When another model is released next quarter, the question is whether it is better for your task, not how many services you would have to rewrite to find out.
The provider you choose today should be a setting you can change, not a foundation you build on.