Microsoft expands Foundry model router to additional regions and refreshes model pool

Microsoft has expanded the model router in Foundry Models, its service for directing inference requests to different LLMs, and refreshed the pool of models it can select from. The router is now available in 28 regions for standard workloads and 21 data-zone regions, up from the previous footprint. The supported model list adds Anthropic Claude Opus 4.8 and the GPT-5.6 family, while four older models — gpt-5-chat, gpt-5.2-chat, gpt-5.3-chat, and Deepseek-V3.1 — have been removed as they reach end of life in Foundry.

The model pool refresh happens without a redeployment. Microsoft says the router's endpoint remains stable as supported models change, so applications keep using the same integration while the router evaluates requests against the updated pool. One caveat: Anthropic models still must be deployed separately before the router can send traffic to them.

Microsoft frames the router in terms of what it calls "hill climbing" — the idea that AI progress comes from continuous, measured iteration rather than one-off decisions. At the model selection layer, that loop takes the form of three documented usage patterns. A/B testing lets teams compare two router configurations or candidate models against the same workload, measuring quality, cost, latency, and governance outcomes before promoting a winner. Model decomposition uses the router as a diagnostic tool: by running it against representative traffic and examining which models requests route to, teams can see how their workload naturally splits into task classes — simple retrieval or summarization versus heavier reasoning or agentic flows. The third pattern, continuous routing, is the one the router was designed for: leaving it in production and letting it pick a model per-request as the pool evolves.

Every routing decision is instrumented. Each response includes a model field identifying which underlying model was selected, which gives teams an auditable trail for evaluating whether the router's choices meet their requirements.

The expansion addresses a real constraint: for organizations with regulatory or governance requirements on where inference runs, intelligent routing only helps if it works in the regions where traffic is allowed to stay. Adding data-zone regions speaks to that directly.

The mechanism behind the router's per-request selection is not described; available detail covers what the router can do and how to evaluate it, not how it chooses a model. Microsoft recommends monitoring routing traces and application outcomes to confirm quality, cost, latency, and governance targets are still being met after model pool changes. The router automates the selection loop, but the evaluation loop remains the operator's job.