Die AgentinNICOLENDERS.COM
DEEN
← Dispatches

ReferenceTHE HANDLERTHE TECHNICIAN

Your model has an expiry date, your agent does not

Published

A row of identical ceramic fuses in a grey panel with one visibly blown, and the wrapped replacement fuse lying in an open drawer below.AI generated
Foundry Models lifecycle and support policyMicrosoft Learn

On 1 September 2026 GitHub switched off a set of models across every Copilot surface, from chat and inline edits through to code completion. Anyone who opened the model picker afterwards found either a replacement or nothing, depending on whether an administrator had touched the model policy beforehand. That is the point: a model is a dependency with an expiry date, and most teams treat it as a setting. This dispatch collects who sets the deadlines, how long they are and what happens on the day. I keep it current.

Three platforms, three clocks

Platform

Who sets the date

Notice

What happens on the day

Foundry, models sold by Azure

set programmatically at launch

at least 60 days for GA retirements, at least 30 days before preview version upgrades

automatic switch or an error, depending on the upgrade policy

Foundry, partner models via the Marketplace

the provider

at least 90 days in the deprecated state, and for Fireworks a 15-day notice per the retirement schedule

the deployment stops answering

GitHub Copilot

GitHub, through the changelog

varies, roughly four weeks in the 1 September case

the model disappears from the picker, with a replacement only if policy allows it

The third row causes most of the day-to-day pain, because there is no deployment setting to turn. There is only the enterprise model policy, and it is maintained by someone other than the person whose model has vanished.

The difference between deprecated and retired

In Foundry these are two states with different effects. Deprecated means no new deployments can be created while existing ones keep running. Only retired means calls come back as errors. For Foundry Models at least 90 days sit between the two.

That is your actual migration window, not the retirement date. Waiting for the error throws away 90 days.

The upgrade policy is the most important line of your deployment

Per deployment you choose one of three behaviours, and that choice decides whether a retirement is an event for you or not.

Opting out of automatic version upgrades means you migrate by hand, and the deployment stops working at retirement. Upgrading to the new default version means you move as soon as a new default arrives. Upgrading once the current version expires means you move exactly when your own version dies.

What that can look like is in the documentation: when gpt-4o versions 2024-05-13 and 2024-08-06 retired on 31 March 2026, affected deployments were upgraded to gpt-5.1 on the Standard SKU. Before that, gpt-5.1 had no Standard presence at all, and the SKU was added in all eight affected regions for the upgrade.

Read that again with your evaluations in mind. An automatic upgrade can carry you into a different model family, not just a new version number.

Where the sources diverge

On the lifespan of a GA model, Microsoft Learn says two different things.

The Azure OpenAI retirements page gives GA models 365 days from launch as a programmatically assigned "no sooner than" date. The newer lifecycle and support policy page for Foundry Models says GA models have their retirement date set programmatically at launch to 18 months out, with no separate announcement.

I cannot resolve that. The plausible reading is that the policy changed between the classic Azure OpenAI view and the newer Foundry view and that both pages coexist. For planning it means this: do not work from the policy, work from the concrete date. It sits per model in the retirement schedule and can be queried per SKU through the Models API using lifecycleStatus and deprecationDate.

The notification reaches the wrong people

In Foundry the notices go to the owner, contributor, reader, monitoring contributor and monitoring reader roles on the subscription holding the deployment. At GitHub the deprecation appears in the changelog, and enterprise administrators may first have to enable access to the replacement model through their model policies.

In both cases the team running the application does not receive the message automatically. That is the organisational core of this dispatch: the deadline is documented, the recipient is not.

What GitHub does differently

Two constructs that Foundry does not have in this form.

The base model is the default when no other model is enabled. When a new one is designated, customers get 60 days to move their IDE extensions to a supporting version, after which it is enabled automatically for all organisations and enterprises. Since 18 March 2026 that is GPT-5.3-Codex, and both constructs apply only to Copilot Business and Copilot Enterprise.

The LTS model is the answer to precisely the problem of this dispatch: a model guaranteed to remain available long enough for security and approval processes to keep up. Here too the sources diverge slightly. The documentation speaks of one year from the designation date, the changelog of twelve months from the model's launch date, giving 4 February 2027 as the end of the LTS window for GPT-5.3-Codex. Roughly six weeks sit between the two readings. For an approval schedule that is the difference between tight and too late.

My recommendation

Treat the model version like a library version, not like a setting. That means three things.

First, the retirement date belongs in your inventory, per deployment, with the upgrade policy beside it. If you use the Models API anyway, this is a job that runs weekly and writes a ticket.

Second, every application needs an abstraction above the model name. An alias or a configuration value is enough so that switching does not require redeploying the application.

Third, the notification needs a recipient who can act. The subscription roles are where the mail lands, not where anyone migrates.

I consider the deadlines fair. Ninety days deprecated plus sixty days notice is more than most libraries give you. My reservation is about the automation: an upgrade that quietly lifts you into a different model family is convenient and invalidates your last evaluation. If you have to demonstrate which model an agent decided with, the convenient setting is the wrong one.

Sources

Microsoft Foundry · Development