LLMSwaps

Which model each app runs today, and when it last changed

A version named at deployment, not defaulted

A deployment on this platform names a model version explicitly. That is what makes a dated retirement schedule usable at all, and it means there is no default engine: something in the customer's configuration says which version answers, and it keeps saying so until somebody edits it. As of 2026-09-22.

What explicit deployment settles about defaults and about schedules. Recorded 2026-09-22.
What the page is askedWhat Microsoft Foundry publishesWhat that leaves open
Is a starting tier statedNot applicable, a deployment names the versionNothing answers that was not deployed
Why that matters for retirementA dated schedule can be matched to a deploymentWhich is how the notice finds its audience
Who holds the effective defaultThe customer's own configurationIt persists until an edit is made
What happens when the date passesThat deployment stops answeringRecorded in the stored work column

Inclusion rule. Filled when the entry's own public page says which model a new project starts on, or when a single-model menu makes the answer follow from the list having one line. Order. What does not apply first, then why the arrangement exists.

1Explicit versions are the precondition for a schedule

A retirement schedule is only actionable if somebody can tell which of their systems uses the retiring version. Deployments that name versions make that answerable, which is why the platform with the most detailed schedule also has no defaults.

The two facts are the same design decision seen from two sides. A product that hides the version cannot publish a useful schedule, because nobody reading it could tell whether it applied to them.

Explicit versions are what make a schedule usableA retirement schedule is only actionable if a reader can tell which of their systems uses the retiring version. Deployments that name versions make that answerable, which is why the platform with the most detailed schedule has no default engine.DeployA versionstring is namedand stored inyourconfiguration.It persistsScheduleA dated rownames that sameversion on theplatform'spage.They matchNoticeReachessubscriptionsthat have anactivedeployment ofit.You editDateThat deploymentstopsanswering, with410 Gone.Why there is no default to publish hereMost productions reach video models through an application instead, where somebody elseholds the string.
Fig. 1 The same design decision seen from two sides: a product that hides the version cannot publish a useful schedule.

2The default moves into configuration, where it persists

Whatever version was deployed keeps answering until an edit happens, so the effective default is whatever a team set up once and forgot. That is a pin, and it fails closed on the retirement date.

Failing closed is the right behaviour and it is still a failure. The notice period is what turns it into a scheduled edit, which is why this platform's two commitments belong together.

3Why a production is usually two layers away from this

Most productions reach video models through an application, not through a deployment they control. In that arrangement somebody else holds the version string and the schedule never reaches the person whose series depends on it.

The register keeps both layers: this reading for the platform, and the application readings for products where a default really does exist and mostly is not named.

4Sources

Read from the model retirement schedule on learn.microsoft.com, 2026-09-22. The whole entry is on Microsoft Foundry, and the column it sits in is on Default tier. Same column, other entries: Amazon Bedrock, Gemini API.