# Foundry Model Router Expands from Two Regions to 28, Refreshing Its Model Pool > Source: > Published: 2026-08-31 10:18:00+00:00 Microsoft recently [expanded model router](https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/model-router-updates-new-regions-a-refreshed-model-pool-and-understanding-the-hi/4521310) in Foundry Models from two regions to 28 for global standard deployments and 21 for data zone deployments, and refreshed the pool of models it selects from. Until this release, the router ran only in East US 2 and Sweden Central. The pool gained Anthropic Claude Opus 4.8 and the GPT-5.6 family, and lost gpt-5-chat, gpt-5.2-chat, gpt-5.3-chat, and DeepSeek-V3.1 as those models reached end of life. Teams on the default configuration receive the change without redeploying. Teams that configured a model subset do not. That split matters, because the announcement and the [documentation](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/model-router) describe it differently. Sanjeev Jagtap, announcing the update, presents automatic delivery as the point of the release: The most important detail is what you don't have to do: these updates occur automatically. The endpoint remains stable as the supported model pool is refreshed, so teams do not need to redeploy the model router to receive the update. Christos Panagiotidis, an Azure MVP and cloud engineer, [draws the distinction](https://www.beyondcloudwithchriz.com/post/microsoft-foundry-model-router-expands-regions-and-refreshes-its-model-pool) the announcement leaves implicit: API stability and behavioral stability are different things. A new model in the pool can change answer style, tool-selection behavior, structured-output reliability, latency distribution, token usage, refusal behavior, and failure patterns. As he puts it: The response schema may remain identical while the application's business outcome changes. For a default deployment, Jagtap's claim is accurate. [Model router deploys in Balanced mode](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router-how-it-works) across the full supported set unless told otherwise, so a workload on defaults now has two candidates it has never evaluated, and four it may have been reaching are gone, with no deployment and no version bump. The documentation describes the escape hatch the announcement omits. Teams can restrict routing to a chosen subset, and in that configuration new models introduced later are excluded by default until explicitly added. A team that constrained its pool is insulated from precisely the refresh the blog post celebrates. The update is opt-out, and the opt-out is a setting most teams will not have touched. Three routing modes exist, none of them mentioned in the announcement. Balanced optimizes cost while maintaining quality and is the default. Quality targets critical work, with Microsoft naming legal review, medical summaries, and complex reasoning. Cost targets high-volume classification and simple question answering. Changes to mode or subset take up to five minutes. A constraint [published earlier this year](https://devblogs.microsoft.com/foundry/how-to-run-evals-for-model-router/) deserves more attention than it has received, because a changing pool makes it moving rather than fixed. Microsoft states that the effective context window equals the smallest underlying model's window, and that oversized prompts succeed only if the router happens to select a model that can handle them. Adding a smaller model to a pool therefore lowers the ceiling for every request routed through it. Two further limits sit in the same guidance. Routing decisions are text-only, so vision inputs are accepted but images do not influence which model is chosen, and audio is unsupported. And the router bills its own input prompt on top of the underlying model's cost, which means any savings claim has a markup inside it. Anthropic models carry a prerequisite that appears as a footnote in the announcement and a troubleshooting entry in the documentation. Claude models must be deployed separately to the same Foundry account with a matching SKU before the router can select them, and referencing them in a subset without that deployment fails with an InvalidResourceProperties error. Claude Opus 4.8 joining the supported list does not make it reachable. Microsoft frames the regional expansion in compliance terms, noting that inference requests must stay within specific geographic boundaries for regulatory, governance, or customer-trust reasons. Going from two regions to 28 changes what is practical for teams with residency obligations. What the material does not address is how a data zone constraint interacts with pool selection when a candidate model is unavailable within that boundary. Model router honors the built-in Azure Policy for Foundry model deployment, enforced at deploy time across the portal, REST API, CLI, and ARM templates, which means the allowed publishers list needs Microsoft plus the publisher of every model in the pool. That is deploy-time governance, and it leaves an open question alongside Microsoft's recent [AI Gateway tier](https://www.infoq.com/news/2026/08/azure-apim-ai-gateway-tier/) for Azure API Management, which fronts models behind runtime policy and controls which a workload may reach. Where both are deployed, the public material does not describe how the two compose. The announcement contains no measurement: no accuracy figures, no cost comparison against a single-model baseline, no latency overhead for the selection step. Microsoft's guidance is to treat an initial deployment as a starting configuration and benchmark it before sending production traffic, and it has published an [open-source evaluation pipeline](https://github.com/microsoft/foundry-model-router-autoeval) that measures quality, cost, and latency in one run, including router-aware cost math and reporting on which underlying models the router actually reaches for. Every response names the selected model in a model field, so decisions are auditable after the fact. For platform teams, the release makes model selection a runtime decision the platform can make, and the default configuration accepts pool changes as they arrive. Panagiotidis frames the discipline that follows: treat a pool refresh as a managed dependency update, capturing the model selected for every evaluated request, comparing against the previous period, and keeping a path to restrict the pool when an update produces unacceptable outcomes.