Why Ethen Supports More Than One AI Provider

Ethen supports more than one AI provider because no single provider is the best fit for every job, available at every moment, acceptable under every data agreement, or stable in price and behavior over time. Using several providers gives Ethen resilience when one is degraded, a choice of the right model for each kind of work, options that meet different data-residency and contractual rules, and room to respond when models and prices change. Multi-provider support also has real costs: models behave differently across providers, there are more combinations to test, and fallback paths fail when they are rarely exercised. Ethen manages those costs with a few rules — check eligibility before preference, never break a data or contract rule to stay available, keep the state of a task independent of any one provider, and record which provider served each request.

Key takeaways

• No provider fits every job. Different models from different providers are strongest at different tasks, modalities and price points.
• Availability is not the only constraint. Data residency, contractual terms and policy decide which providers are even eligible.
• Failover must respect the rules. Staying available is never a reason to send data somewhere it is not allowed to go.
• Your work should not live inside a provider. The state of a task belongs to the task, so changing providers does not erase progress.
• Untested fallbacks are a risk. Alternative paths must be exercised, not just configured.

What does multi-provider AI mean?

Multi-provider AI means building a product or workflow so that it can use models from more than one company — frontier model providers, providers of open models, and models you run yourself — through a common way of requesting work. It is different from merely having accounts with several vendors. In a multi-provider system, the decision about which provider serves a request is made per request or per task, under explicit rules, and the rest of the system does not care which provider was chosen.

At Ethen, the AI Gateway is the main place this happens: one API key for model access and routing, with logs, fallback and usage tracking. Ethen's local and GPU options extend the same idea to models you run on your own machine or deploy on dedicated hardware. Whether a gateway is worth it for your situation is covered in our guide When an AI Gateway Helps.

Why does Ethen use more than one provider?

Ethen uses more than one provider for four reasons, roughly in order of how often they matter.

1. The best model for the job varies

Model providers make different trade-offs. One family may be strongest on long reasoning, another on fast and inexpensive classification, another on vision, another on speech, another on code. Open models may be preferable when a task must run locally or when predictable costs matter more than the last increment of quality. A product that serves chat, code, research, creative work and long-running jobs will meet all of these needs at once. Restricting it to one provider would mean accepting that provider's weaknesses everywhere. We discuss the broader case in Why Ethen Is Built Around Multiple Models Instead of One.

2. Providers have bad days

Every provider has outages, degraded performance, rate limits and capacity pressure. A product that depends on one provider inherits all of them. With several providers, a degraded provider can be removed from consideration while healthy ones continue to serve. Ethen's Gateway already treats provider health as an eligibility condition: a model whose provider is unhealthy is filtered out before any ranking happens, as described in How Ethen Gateway Chooses an Eligible Model.

3. Data and contract rules differ

Organizations often have rules about where data may be processed, which providers may see which data, and under what retention and training terms. Those rules are not preferences; they decide which providers are eligible at all. A product with only one provider can only serve customers whose rules that provider happens to satisfy. Supporting several providers — including the option of running models locally — makes it possible to meet stricter requirements without giving up AI assistance entirely.

4. Things change

Prices fall and rise, new models are released, old versions are retired, and hosted models can change behavior behind a stable name. A study of a widely used hosted model documented substantial behavior differences between versions released months apart (Chen et al., 2023). An organization tied to one provider has to absorb every such change on that provider's timeline. With multiple providers, it can choose when and whether to move.

What does multi-provider support cost?

Multi-provider support costs real effort, and pretending otherwise produces fragile systems.

Models are not interchangeable. Two models from different providers asked the same question will often answer differently in format, length, tone and correctness. Prompts tuned for one model can perform worse on another; research has shown that model performance can be sensitive even to formatting choices that carry no meaning (Sclar et al., 2023). Swapping providers is therefore a change in behavior, not just a change in supplier.

There are more combinations to test. Every additional provider multiplies the configurations that need checking: which models, with which prompts, tools and settings, on which kinds of task.

Fallbacks rot. An alternative path that is used only during outages is, by definition, rarely exercised — and rarely exercised code is where latent bugs hide. Engineers at large cloud providers have written about how fallback logic can turn a partial failure into a full one, and have recommended either avoiding fallback or exercising both paths continuously so that the alternative is always known to work (Gabrielson, Amazon Builders' Library).

More agreements to manage. Each provider has its own terms for data handling, retention and use. Keeping track of which terms apply to which data is work.

How does Ethen keep multi-provider support safe?

Ethen keeps multi-provider support safe with four rules. They describe principles; we do not publish the implementation details of how requests are rerouted.

Rule 1: Eligibility before preference

Before any provider is chosen, the request's requirements and rules decide which options are eligible: the capabilities the task needs, the budget, provider health, and the data and contract rules attached to the project. Only then is an eligible option chosen. If nothing is eligible, the request is refused with a reason rather than quietly served by something that breaks a rule. Gateway API keys are bound to a project, so these rules travel with every request; see How Ethen Gateway Binds API Requests to Projects.

Rule 2: Never break a rule to stay available

When a provider fails, the replacement must satisfy the same rules as the original. A request that may only be processed in one region does not move to another region because the first one is down. A request restricted to certain providers is not sent elsewhere for convenience. Refusing, waiting or degrading gracefully are all acceptable outcomes. Silently crossing a boundary is not.

Rule 3: Keep the task independent of the provider

The state of a task — what has been done, what is pending, what evidence exists — should live in Ethen, not inside one provider's session or proprietary conversation format. That way, changing providers mid-project does not erase progress, and a provider outage does not mean starting over. It also means switching providers is a decision about future requests, not a migration of past work.

Within a single task, switching providers is used sparingly. Changing models halfway through a chain of steps can break consistency, discard cached context and make it harder to understand why a result came out the way it did. Ethen Research Lab's position paper Faros discusses keeping a model choice stable within a chain of steps and switching only at explicit boundaries; it is a research position with no Ethen routing measurements.

Rule 4: Record which provider served

For every request, Ethen records which provider and model served it. That record is what makes multi-provider behavior understandable after the fact: when a result looks different from yesterday's, the first question is whether it came from a different model. It also matters for accountability, because organizations sometimes need to show which provider processed which data.

Questions to ask any multi-provider AI product

If you are evaluating a product that promises to route across AI providers — including Ethen — these questions separate a robust design from a marketing claim.

1. What decides eligibility? Ask which requirements and rules are checked before a provider is chosen, and whether data-residency and contractual restrictions are among them.
2. What happens when no provider is eligible? A good answer is "the request is refused or waits, with a clear reason". A worrying answer is "it always finds something".
3. Can I see which provider served each request? If not, you cannot explain differences in results or demonstrate where your data went.
4. Where does my work live? If conversation history, files or task progress are held inside one provider's session, switching providers may mean losing them.
5. How are fallback paths tested? Ask whether alternative providers are exercised regularly or only during outages.
6. How are behavior differences handled? Ask whether prompts, tools and settings are tested per provider, and whether you can pin a model for a workflow that depends on consistent behavior.
7. Who decides on upgrades? Ask whether a provider's new model version is adopted automatically or only after testing, and whether you can opt out.

These questions do not require access to implementation details. They ask what the product promises, which is what you will depend on.

How should teams test a provider change?

A provider change — whether a planned switch or an unplanned failover — is a change in behavior, so it deserves a test. The most informative test uses your own past work: replay a representative sample of recent tasks on the new option, check the results the same way you checked the originals, and look task by task for regressions, not just at the average. Research on backward compatibility in machine learning has found that model updates can introduce new errors on specific cases even when average accuracy improves (Srivastava et al., 2020).

Ethen Research Lab has written up this idea as model change assurance: before a change reaches live work, compare old and new configurations on the organization's own history. It is a research note, and the validation protocol that would test whether such checks predict live outcomes has not been run. See Model Change Assurance. Our practical advice on upgrades is in Why Ethen Sometimes Won't Use the Newest Model.

What about running models yourself?

Running models yourself is the furthest form of provider independence, and Ethen supports it in two ways: Ethen Local Models, which runs open models on your own machine through Ethen Desktop, and GPU deployment of open models on dedicated hardware. Local and self-hosted models change the trade-offs. They remove dependence on an outside provider and keep data on infrastructure you control, at the cost of hardware, operations and, often, some capability compared with the largest hosted models. We explain when local AI is the right choice in Why Local AI Still Matters in a Cloud-First World.

An example

Illustrative example — hypothetical, not a description of a specific incident.

A support team uses Ethen to draft replies to customer tickets. Their project is restricted to providers that process data in the EU. One afternoon, the provider serving their default model is degraded. Requests are re-checked for eligibility: a second model from a different EU-compliant provider is healthy and supports the task, so new drafts are served by it, and each draft records which model produced it. A third provider is also healthy but does not meet the EU rule, so it is never considered. Ticket drafts in progress keep their history because the work lives in Ethen, not in the first provider's session. The next morning, the team lead notices drafts from the afternoon are slightly more formal and can see why: a different model wrote them. Because the team periodically runs both options on a saved set of tickets, they already know the second model is an acceptable fallback for this task.

Limitations

Multi-provider support does not make a product immune to outages: if every eligible option is unavailable, requests will fail or wait. It does not make models interchangeable, and it adds testing and operational work. Provider terms and capabilities change, so eligibility rules need maintenance. This article describes principles; it does not describe Ethen's provider list, contract terms or rerouting implementation.

Frequently asked questions

Does Ethen switch providers automatically when one fails? Ethen's Gateway filters out unhealthy providers before choosing a model, so healthy eligible options can serve requests. A replacement must meet the same data, contract and capability rules; if none does, the request is refused.

Will my results change if a different provider serves a request? They may. Models differ in format and behavior, which is why Ethen records which provider and model served each request and why provider changes deserve testing.

How do I avoid lock-in to one AI provider? Keep the state of your work outside any provider's session, record which model produced each result, keep a test set of your own tasks, and choose tools that let you change providers per project.

Is multi-provider AI more expensive? It can cost more engineering and testing effort. It can also reduce costs by letting you use cheaper models where they are good enough. The useful comparison is the cost of good results, not the price per token.

Related reading

• When an AI Gateway Helps
• Model Intelligence and Routing
• What We're Improving About Reliability Across Ethen

References

1. Gabrielson, J. Avoiding fallback in distributed systems. Amazon Builders' Library. https://builder.aws.com/content/3EuS9Sakq7L3VLQIF3qzfMfke1Y/avoiding-fallback-in-distributed-systems
2. Chen, L., Zaharia, M., Zou, J. (2023). How is ChatGPT's behavior changing over time? arXiv:2307.09009. https://arxiv.org/abs/2307.09009
3. Sclar, M. et al. (2023). Quantifying Language Models' Sensitivity to Spurious Features in Prompt Design. arXiv:2310.11324. https://arxiv.org/abs/2310.11324
4. Srivastava, M. et al. (2020). An Empirical Analysis of Backward Compatibility in Machine Learning Systems. arXiv:2008.04572. https://arxiv.org/abs/2008.04572
5. Ethen Blog (2026). How Ethen Gateway Chooses an Eligible Model. https://upcube.ai/blog/how-ethen-gateway-chooses-an-eligible-model
6. Ethen Blog (2026). How Ethen Gateway Binds API Requests to Projects. https://upcube.ai/blog/how-ethen-gateway-binds-api-requests-to-projects
7. Ethen Research Lab (2026). Model Change Assurance: Testing AI Upgrades Before They Reach Real Work. Research note; architecture proposal. https://upcube.ai/resources/research/model-change-assurance
8. Ethen Research Lab (2026). Faros: Researching How Intelligence Should Choose Intelligence. Position paper. https://upcube.ai/resources/research/faros-research