Microsoft retired four models from the Foundry router under every deployment left on defaults

A default deployment routes in Balanced mode across the full supported set unless someone configured it otherwise ^[11]. So the change lands inside the request path rather than in a release note: the workload gains two candidates it has never evaluated and loses four it may have been reaching, without a deployment or a version bump ^[12]. Christos Panagiotidis, the Azure MVP quoted by InfoQ, itemizes what a new pool entry can move: answer style, tool-selection behavior, structured-output reliability, latency distribution, token usage, refusal behavior and failure patterns ^[9]. His summary is the line to paste into the design doc, that the response schema may remain identical while the application's business outcome changes ^[10].

The escape hatch is in the documentation rather than the announcement. Restrict routing to a chosen subset and models introduced later are excluded by default until you add them explicitly ^[13]. A team that pinned its pool is insulated from exactly the refresh the blog post celebrates. This is opt-out behavior. Settings nobody had a reason to touch stay untouched. Mode and subset changes take up to five minutes to apply ^[15], which is close to the whole operational cost of holding the control.

Three routing modes exist and the announcement mentions none of them ^[14]. Balanced is the default and optimizes cost while maintaining quality; Quality is what Microsoft points at for legal review, medical summaries and complex reasoning; Cost is aimed at high-volume classification and simple question answering ^[14]. If your workload sits in Microsoft's own Quality examples, running on Balanced by default is a bigger finding than the pool refresh.

Microsoft's earlier guidance 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 ^[16]. Adding a smaller model therefore lowers the ceiling for every request routed through that pool ^[17]. Pair that with a pool the vendor edits on its own schedule and the prompt ceiling stops being a number you can measure once and cache. Selection is also text-only: vision inputs are accepted, images do not influence which model is chosen, and audio is unsupported ^[18].

The router bills its own input prompt on top of the underlying model's cost ^[19]. Any savings figure has that markup inside it, and it transfers to your invoice only if your prompts are long relative to the router's own prompt. Short prompts at high volume pay the largest proportional overhead, which is the workload Cost mode is described for ^[14][19].

Region coverage went from East US 2 and Sweden Central to 28 for global standard ^[1][3], 26 more than before ^[1], with data zone deployments trailing by seven ^[2]. Microsoft frames the expansion as residency, since inference requests must stay inside specific geographic boundaries for regulatory, governance or customer-trust reasons ^[21]. The material does not say what the router does when a candidate model is unavailable inside a data zone boundary ^[22]. And Claude Opus 4.8 appearing on the supported list does not make it reachable: Claude models must be deployed separately to the same Foundry account with a matching SKU, and naming one in a subset without that deployment fails with InvalidResourceProperties ^[20]. Governance has the same seam. The built-in Azure Policy allowed-publishers list is enforced at deploy time across the portal, REST API, CLI and ARM templates ^[23], while the pool is refreshed afterwards.

In my context, pin the subset, add models deliberately, and keep an eval you run before each addition. That trades automatic access to Claude Opus 4.8 for a pool you can name in a changelog. If the workload is a chat surface where style drift costs nothing, defaults are the cheaper answer and this whole argument is overhead.