Microsoft has expanded its model router in Foundry Models from two regions to 28 for global standard deployments and 21 for data zone deployments, according to a report published by InfoQ. The router, which previously operated only in East US 2 and Sweden Central, now offers dramatically broader geographic coverage while automatically updating the pool of AI models it selects from. The expansion addresses compliance requirements for teams that must keep inference requests within specific geographic boundaries for regulatory, governance, or customer-trust reasons.
The updated model pool now includes Anthropic Claude Opus 4.8 and the GPT-5.6 family, while removing gpt-5-chat, gpt-5.2-chat, gpt-5.3-chat, and DeepSeek-V3.1 as those models reached end of life. Teams using the default configuration receive these changes without redeploying, but teams that configured a custom model subset do not. The router operates in three modes: Balanced, which optimizes cost while maintaining quality and serves as the default; Quality, which targets critical work including legal review, medical summaries, and complex reasoning; and Cost, which handles high-volume classification and simple question answering. Changes to mode or subset take up to five minutes to take effect. The effective context window equals the smallest underlying model's window, meaning oversized prompts succeed only if the router happens to select a model capable of handling them. Routing decisions rely on text-only inputs, so vision inputs are accepted but images don't influence which model is chosen, and audio remains unsupported.
Sanjeev Jagtap, announcing the update, presents automatic delivery as the release's central feature: "The most important detail is what you don't have to do: these updates occur automatically." Azure MVP and cloud engineer Christos Panagiotidis draws a crucial distinction the announcement leaves unstated, noting that API stability and behavioral stability are different things. A new model in the pool can alter answer style, tool-selection behavior, structured-output reliability, latency distribution, token usage, refusal behavior, and failure patterns. As he frames it, "The response schema may remain identical while the application's business outcome changes." The documentation describes an 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.
The update is opt-out, and the opt-out is a setting most teams won't have touched, according to the report. For workloads on defaults, this means two candidates they've never evaluated are now active, and four they may have been reaching are gone, with no deployment and no version bump. A constraint published earlier this year becomes more significant as the pool changes: adding a smaller model to a pool lowers the ceiling for every request routed through it. The router also bills its own input prompt on top of the underlying model's cost, meaning any savings claim has a markup embedded. Anthropic models carry a prerequisite that appears as a footnote: 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 error. 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 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 field, so decisions are auditable after the fact. For platform teams, the release makes model selection a runtime decision the platform can make, with the default configuration accepting 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. The shift transforms model governance from a deployment-time choice into an ongoing operational concern, one that requires teams to balance the convenience of automatic updates against the risk of unexpected behavior changes in production systems.