Azure Foundry's Model Router goes from 2 to 28 regions and swaps models without redeploy

Microsoft expanded the model router in Foundry Models from two regions to 28 in global standard deployments, and to 21 in data zone deployments, according to an InfoQ report. Before this update, the router only ran in East US 2 and Sweden Central. Along with the geographic reach, the pool of models it chooses from was also refreshed.

The model router is a single endpoint that decides, for each request, which foundation model best serves that call, optimizing between cost, quality and latency without the application needing to know which model responded. For those building software in Brazil, this regional expansion is the detail that moves from abstract to concrete: it becomes possible to keep inference within specific geographic boundaries for regulatory, governance or customer trust reasons, something that two regions in the US and Sweden didn't solve.

What entered and left the pool

The model refresh came in the same batch. The pool gained Anthropic Claude Opus 4.8 and the GPT-5.6 family, and lost four models that reached end of life.

| Added | Removed (end of life) | |---|---| | Anthropic Claude Opus 4.8 | gpt-5-chat | | GPT-5.6 family | gpt-5.2-chat | | | gpt-5.3-chat | | | DeepSeek-V3.1 |

According to Sanjeev Jagtap, when announcing the update, the key point is precisely not having to do anything:

The most important detail is what you don't need to do: these updates happen automatically. The endpoint remains stable while the pool of supported models is refreshed, so teams don't need to redeploy the model router to get the update.

>

-- Sanjeev Jagtap, Microsoft

API stability is not behavioral stability

This is the part the announcement leaves implicit, and that InfoQ brings to the surface. Christos Panagiotidis, Azure MVP and cloud engineer, makes the distinction the official text doesn't:

API stability and behavioral stability are different things.

>

-- Christos Panagiotidis, Azure MVP

In practice, a new model in the pool can change response style, tool-selection behavior, structured output reliability, latency distribution, token usage, refusal patterns and failure mode. As he sums it up: the response schema can stay identical while the application's business outcome changes.

For a standard deployment, Jagtap's promise holds true: the model router operates in Balanced mode over the entire supported set, unless configured otherwise. In other words, a workload on default now has two candidates it never evaluated and four it may have been using that disappeared, without redeploy and without a version bump. It's an opt-out update, and the opt-out is a setting most teams never touch.

The three routing modes

The announcement doesn't mention it, but there are three modes, and the choice changes the cost and quality of what your application delivers:

• Balanced: optimizes cost while maintaining quality. It's the default.
• Quality: targets critical work. Microsoft cites legal review, medical summaries and complex reasoning.
• Cost: targets high volume, such as classification and simple questions.

Mode or subset changes take up to five minutes to take effect. Teams that restricted routing to a chosen subset are isolated from the refresh: new models only enter if explicitly added.

The gotchas that decide whether it's worth it

Some previously published restrictions gain weight precisely because the pool now changes:

• Context window is that of the smallest model. The effective window equals that of the smallest model in the pool, and large prompts only go through if the router picks a model that supports them. Adding a smaller model to the pool drops the ceiling for every request routed through it.
• Routing decisions are text-only. Vision inputs are accepted, but images don't influence model choice. Audio isn't supported.
• There's built-in markup. The router charges for its own input prompt on top of the cost of the chosen model. Any savings promise already includes this add-on.
• Claude needs a separate deploy. Anthropic models require a separate deployment on the same Foundry account, with a compatible SKU, before the router can select them. Referencing a Claude model in a subset without that deployment fails with an InvalidResourceProperties error. Claude Opus 4.8 being on the supported list doesn't make it reachable.

Governance and data residency

Microsoft frames the regional expansion in compliance terms: inference needs to stay within specific geographic boundaries. Going from 2 to 28 regions changes what's viable for teams with data residency obligations, a hot topic for those operating under LGPD, Brazil's data protection law, and contracts that require processing within a defined territory. What the material doesn't clarify is how a data zone restriction interacts with pool selection when the candidate model isn't available within that boundary.

The model router respects native Azure Policy for Foundry model deployment, applied at deploy time in the portal, REST API, CLI and ARM templates. The allowed publishers list needs to include Microsoft plus the publisher of each model in the pool. That's deploy-time governance, and it remains an open question how it composes with the new AI Gateway tier in Azure API Management, which controls at runtime which models a workload can reach.

What to do before sending production traffic

The announcement doesn't bring measurements: no accuracy numbers, no cost comparison against a single-model baseline, no latency overhead for the selection step. Microsoft's own guidance is to treat the initial deployment as a starting configuration and benchmark before sending production traffic. There's an open-source evaluation pipeline that measures quality, cost and latency in a single run, with router-aware cost accounting and a report on which models it actually invokes.

Each response carries the chosen model in a model field, so decisions are auditable after the fact. That's the basis for the discipline Panagiotidis proposes: treating a pool refresh like a managed dependency update, logging the selected model on every evaluated request, comparing against the previous period, and keeping a path to restrict the pool when an update produces unacceptable results.

For platform teams in Brazil, the practical takeaway is direct: model selection has become a runtime decision the platform can make, but the default configuration accepts pool changes as they arrive. Those who don't want behavioral surprises with every refresh will want to look at the subset and evaluation pipeline before the next model quietly slips in.