Microsoft expands Foundry Model Router to 28 regions and refreshes model pool

Microsoft expanded Foundry Model Router from two regions to 28 for global standard deployments and 21 for data zone deployments, Microsoft said Aug. 31, 2026. The company also changed the models that the router can select.

The router previously ran in East US 2 and Sweden Central. The regional expansion gives teams more options for workloads that must keep inference within defined geographic boundaries for regulatory, governance or customer-trust requirements.

The model pool now includes Anthropic Claude Opus 4.8 and the GPT-5.6 family. Microsoft removed gpt-5-chat, gpt-5.2-chat, gpt-5.3-chat and DeepSeek-V3.1 after those models reached end of life.

Default deployments receive new behavior

Teams that use the default configuration receive the refreshed pool through the existing endpoint. They do not need to redeploy the router.

Foundry Model Router uses Balanced mode across the supported model set by default. A workload that uses those defaults may now reach two models its team has not evaluated, while four previous candidates no longer serve requests.

The endpoint keeps the same response schema, but a model change can affect answer style, tool selection, structured-output reliability, latency, token consumption, refusal patterns and error rates. Application teams should measure those outcomes instead of treating endpoint stability as behavioral stability.

Teams that configure a model subset follow a different path. Foundry excludes new models from a restricted subset until an operator adds them. That setting gives teams control over pool changes, but it requires active maintenance as Microsoft adds or retires models.

Three routing modes set different priorities

Foundry offers three routing modes:

• Balanced targets cost while maintaining response quality. It serves as the default.
• Quality targets demanding work such as legal review, medical summaries and complex reasoning.
• Cost targets high-volume classification and simple question answering.

Microsoft says mode and subset changes can take up to five minutes to apply.

The choice affects more than model preference. A Quality configuration may increase cost and latency. A Cost configuration may reduce response quality for requests that require reasoning or precise formatting. Platform teams should connect each mode to a measured workload profile.

A smaller candidate can lower the context ceiling

Microsoft defines the router's effective context window by the smallest context window among the underlying models in the pool. A request with a large prompt may succeed when the router selects a model with a larger window and fail when it selects a smaller candidate.

A team that adds a model with a smaller context window therefore creates a lower capacity boundary for requests that reach that model. Prompt-size tests should cover each candidate in a restricted subset and several routing outcomes in the default pool.

The router uses text for routing decisions. It accepts vision inputs, but image content does not influence model selection. Audio input remains unsupported.

A request incurs the router's input charge along with the selected model's cost. Teams that compare router economics with a single-model deployment need to include both charges, token usage and the cost of failed or retried requests.

Claude requires a matching deployment

Claude Opus 4.8 becomes reachable through the router only after a team deploys the Claude model to the same Foundry account with a matching SKU. The supported-model list does not create that deployment.

An operator who adds Claude to a restricted subset before creating the required deployment receives an InvalidResourceProperties error. Teams should validate the account, SKU and publisher configuration before they add Claude to production routing.

Regional reach expands compliance options

The move from two regions to 28 gives organizations more room to match inference with residency requirements. Data zone deployments cover 21 regions, which supports a narrower geographic boundary than the global standard option.

Microsoft has not explained how the router handles a candidate that lacks capacity or availability inside a selected data zone. Teams with strict residency rules should test unavailable-model scenarios and confirm that fallback behavior stays within their approved boundary.

Azure Policy applies to Foundry model deployment through the portal, REST API, command-line interface and Azure Resource Manager templates. Operators must allow Microsoft and the publisher of every model in the selected pool.

That policy controls deployment. Azure API Management's AI Gateway adds a runtime control layer for model access, traffic rules and related AI tools. Microsoft has not described how the two layers compose when a workload uses both services.

Benchmark before production traffic

Microsoft's announcement provides no accuracy results, cost comparison with a single-model baseline or latency measurement for the routing step. Its Foundry model router guidance directs teams to treat the initial configuration as a starting point and benchmark quality, cost and latency before production use.

Each response includes the selected model in a model field. Teams can record that value beside prompt size, latency, token usage, quality scores and business outcomes. Those records show which candidates serve each workload and reveal changes after a pool refresh.

Platform teams should manage the router pool as a versioned dependency even though Microsoft refreshes the default pool through a stable endpoint. A test suite, model-level telemetry and a restricted-subset fallback give operators control when a new candidate changes application behavior.