Model Router spreads requests across several AI providers, but does not solve vendor lock-in on its own

Since 6 October 2026, Microsoft's Model Router in Foundry can spread requests across models from several providers with automatic fallback and per-request route metadata. That limits the outage of one model, but reduces vendor lock-in demonstrably only with at least two permitted providers, an independent control plane and a tested exit path.

What exactly has Microsoft changed about Model Router in Foundry?

In its documentation updated on 6 October 2026, Microsoft described Model Router as routing requests across models from multiple providers, including OpenAI, Anthropic, xAI, Fireworks, DeepSeek and Meta. By default, automatic failover to another suitable model is available, and per request the router can report routing metadata, the ordered sequence of model attempts, the HTTP statuses and the fallback decision.

According to the updated Model Router documentation from Microsoft, this means an application no longer stalls as soon as one underlying model fails to respond: the traffic can be routed to an alternative model, and that decision leaves a trace. For organisations that value operational resilience and auditability, that is a concrete step forward. The concept documentation does add a hard precondition: a custom deployment needs at least two models in the subset to make use of fallback.

Why does model routing across several providers not yet mean independence from the platform?

Routing between models within one platform is something other than being independent of that platform. In its guide on high availability and resiliency for Foundry, Microsoft states explicitly that Foundry itself does not provide automatic disaster recovery or failover for the complete solution. In the case of a regional or endpoint outage, the application, or a gateway, must route the traffic to a second deployment.

The boundary therefore does not lie at the model, but at the layer around it. The concept documentation for Model Router warns, moreover, that the active router version can continuously add new underlying models, and that the smallest underlying context window — the amount of text a model can process in one go — can determine the effective limit for all requests. In our assessment, a new, often unnoticed risk arises here: whoever presents the router as self-evident independence relocates the concentration point from the model to the router itself. If the router, the authentication, the quotas or the network connection to that one platform fails, model diversity does not help.

That Microsoft does not make this unique is shown by a comparable design elsewhere. In the documentation about Unity Gateway as a central AI governance layer, Azure Databricks describes routing, traffic splitting, fallbacks and audit logging across external providers as gateway capabilities. In our analysis, this supports treating provider choice, fallback and audit as capabilities that may warrant a separately managed control plane rather than assuming that model-level routing alone provides them.

What does this mean for directors, lawyers and CISOs who want to manage concentration risk?

Our analysis: because Model Router with a customised subset needs at least two models to make use of fallback, the CISO should record which models are and are not permitted on grounds of privacy, region, context window or task requirement, before the next release. Because Microsoft itself states that Foundry does not provide disaster recovery for the complete solution, the application remains vulnerable to regional and endpoint outage despite model diversity; therefore, in our analysis, the responsible architect should set up a second deployment, independent quotas and periodic failover tests, and the director should record that test as a recurring obligation. Because the active router version can continuously add new underlying models and the smallest context window determines the effective limit, a validated workflow can change quietly; therefore, in our analysis, the lawyer should seek contractual provisions on version control, change notification and an enforceable audit right with concrete inspection evidence. Because the router can report route, model, error and fallback data per request but that does not of itself give evidential value, accountability after the fact remains, in our assessment, weak without a linked decision record; therefore, in our analysis, the responsible manager should link model identity, version, attempt sequence, status, fallback decision, data classification and human release to each other and retain them per request.

Which conditions make model routing demonstrably resilient against outage and lock-in?

In our analysis, model routing reduces concentration risk demonstrably only if provider diversity, route independence, compatibility, observability and a tested exit path are managed together. The following points follow from the Microsoft documentation and from our analysis of it.

• Genuine model diversity: configure, in our assessment, at least two substantively suitable models from different providers and document per model why it may or may not be used. Microsoft describes that without a second model in the subset, fallback does not work.
• Independent control plane: do not let routing, circuit breaking, access policy, quotas and fallback, in our assessment, depend solely on the same provider as the primary models; record what happens if the router, authentication or quotas fail. This connects to managing recording provider concentration in the AI supplier chain.
• Compatibility and version control: test incompatible context windows and changed model versions, because the router version can change according to Microsoft and the smallest window determines the limit.
• Evidence per request: record model identity, version, route, attempt sequence, status, error type, fallback decision, data classification and human escalation. Note that models that agree do not prove independent control; see why several models do not prove independent verification.
• Tested exit path: maintain an alternative path to another gateway or local model and test provider outage, quota exhaustion and recovery periodically.

In our assessment, whoever assigns these five layers jointly turns the gain of multi-model routing into demonstrable resilience, whereas whoever skips one layer maintains the dependence on one platform. More context on managing this kind of dependency is in the topic hub on AI governance and control.

Sources: The article relies on official Microsoft Learn documentation about Model Router, the Foundry resiliency guide and Azure Databricks Unity Gateway.