Your model has an expiry date: who gets paged at 2am

On Azure, one version of GPT four o has a retirement date of April fourteenth, twenty twenty-seven. Microsoft lists GPT five point one as its replacement. And Microsoft says that replacement column is also, where supported, the target for automatic upgrades at retirement. Amazon Bedrock's own docs say its lifecycle dates may differ from the dates model providers publish. So when your platform's date arrives, is the model answering your traffic at two in the morning still the one you tested? The Platform Radar. I'm Mat Caniglia. The Platform Radar is produced by Clouditive, nearshore platform engineering for US teams.

Welcome in. The voice you're hearing is an AI clone of my own, used with my permission. This deep dive has five items, and we close with the takeaways. In order: why now, and the one claim, then same model, different dates, then when the vendor swaps it for you. After that, what breaks, and who gets paged, and last, the SDK that picks your API version for you. One thread orders them all: the model ID you ship on is a dated dependency on each platform, and we follow it from the calendar date to the version your code sends. By the end, you'll be able to answer that two a.m. question for your own stack.

What you want is a list of every model ID and API version you ship on, each platform's own retirement date on the on-call calendar, pinning settings you picked on purpose, and no replacement going live until your own eval passes on it. So who on your team owns that date, and who gets paged when it arrives?

We just covered the promise of this deep dive: by the end, you'll know whose phone rings when a model date lands at two in the morning. That question depends on dates, because a pager only rings on a deadline somebody missed. So this chapter starts with the dates that moved over the last sixty days. Start with Anthropic. On September thirtieth, twenty twenty-six, it notified developers using Claude Sonnet four point five of the model's upcoming retirement on the Claude API. The retirement date is November thirtieth, twenty twenty-six.

Anthropic's lifecycle runs through four states: Active, Legacy, Deprecated and Retired. A deprecated model is still functional but no longer recommended. A retired one is no longer available for use, and in Anthropic's words, requests to retired models fail. The practical read: the quiet stretch is the risky one. Nothing in your logs looks wrong while the model still answers, so the first signal can be the error itself. Treat the retirement date as the day that feature stops, and put it on the on-call calendar the week it's announced.

Then the API moved. On October twenty-first, twenty twenty-six, Anthropic released a new API version named for that date, and new SDK majors that send it by default, Python SDK two point oh and TypeScript SDK one point oh among them. Anthropic adds that the new SDK and CLI versions also have breaking changes that don't depend on the API version. For a platform team, that means a routine dependency bump can change the API version you call without anyone touching a prompt. Ask who reviews SDK major versions, and whether that review looks at the version your client sends. Pin the SDK on purpose, and ship the upgrade as its own change with its own eval run.

On the AWS side, Amazon Bedrock has a lifecycle policy for models launched on or after September seventh, twenty twenty-six, and it says its lifecycle dates may differ from the dates model providers publish. Anthropic says the same from its end: Bedrock sets its own retirement schedules. Bedrock also names an exception. G P T six point one Sol follows the OpenAI first-party model's lifecycle and end-of-life terms, with no separate Bedrock minimum-availability date.

So the check is conditional. If your traffic runs through Bedrock and your calendar copied a date from the provider's page, that calendar may be holding a date that doesn't govern your calls. Look up each model on the platform you actually call, and write down whose terms apply to it. That's the claim this episode stands on. The deadline belongs to a pair, the model ID plus the platform you reach it through, and the pager rings when nobody owns that pair. Which invites the obvious pushback: why not just track retirement per model and be done with it?

We just covered the claim this episode stands on, that a deadline belongs to a pair, the model ID plus the platform you reach it through. That brings us to the pushback, because the obvious shortcut is a single retirement date per model, and it's worth testing that shortcut against the published schedules before anyone builds a calendar on it. The thread doesn't change. A model ID is a dated dependency per platform, until your own eval passes on the replacement. Start with Microsoft's retirement schedule for Azure OpenAI. The GPT four o snapshot dated August sixth, twenty twenty-four, is listed as deprecated, with a retirement date of April fourteenth, twenty twenty-seven.

The GPT four point one snapshot from April fourteenth, twenty twenty-five, carries that same Azure retirement date, April fourteenth, twenty twenty-seven. On the same list, an older GPT four o snapshot, from May thirteenth, twenty twenty-four, retires sooner, on December ninth, twenty twenty-six. So even inside one platform, one model name already holds more than one date, and the version string decides which row you're on. Now pull up the provider's own deprecations page for those same snapshots and treat it as a second, separate schedule. The practical read: put the Azure date and the provider's date side by side for every snapshot you call, and never assume they match because the names do.

Anthropic says this plainly on its deprecations page. The dates there apply to the platforms Anthropic operates. Amazon Bedrock and the Google-managed version of Claude on Google Cloud are run by partners, and they set their own retirement schedules, so a model's status and dates can differ. Amazon's Bedrock documentation says the same thing from the other side. Its lifecycle dates are specific to Bedrock and may differ from the dates model providers publish. And for Bedrock usage, only the dates on the model card apply.

That policy covers models launched on Bedrock on or after September seventh, twenty twenty-six. Where it applies, the model card shows an end-of-life no-sooner-than date, and a Legacy period, which is the notice before end of life. There are two Legacy periods, six months and forty-five days, and when a model enters Legacy, its end-of-life date is added to the card. Every model on Bedrock has one of three states. You can see the state in the console, and when you call Get Foundation Model or List Foundation Models, it comes back in a field called model lifecycle.

For a platform team, that changes who checks what. The date that governs Bedrock calls lives on Bedrock's card, so a calendar copied from the provider may hold a date that doesn't apply. And because the state comes back from an API call, a team can poll it on a schedule and alert the day a model it uses moves to Legacy. With a forty-five day notice window, a quarterly review would be too slow.

Here's the decision rule. Key your inventory on four fields, the provider, the platform, the model ID and the version, and give every row its own date and the page that date came from. Take a made-up example, where a team calls the same Claude model straight from Anthropic for one product and through Bedrock for another. That's two rows with two dates, and neither row borrows the other's date. One more thing about that key. A row pinned to a dated snapshot gives you a date you can plan around. If a row's ID is an alias, a name that could point at a newer model, it's harder to date, because what answers behind it could change while your code sits still. That question is where we go next.

We just covered how the same model carries different dates on different platforms, and why a row in your inventory only protects the version you actually pinned. That brings us to the harder case, because the same question of who controls the version shows up when the vendor changes it for you. The thread is the one running through this whole episode. Treat the model and API version you ship on as a dated dependency per platform, until your own eval passes on the replacement. Start with Azure. Its retirement schedule has a Replacement column, and Microsoft describes it as identifying its recommended replacement and, where supported, the target for automatic upgrades at retirement.

One row from that schedule makes it concrete. G P T four o, the version dated August sixth, twenty twenty-four, is listed as deprecated, with a retirement date of April fourteenth, twenty twenty-seven, and G P T five point one in the Replacement column. The upgrade itself is run by Microsoft. For Global Standard, Data Zone Standard and Standard deployment types, Microsoft manages automatic upgrades when a model version is retired. Provisioned deployments are the exception, and the policy says plainly that they are not auto-upgraded.

One more detail from the same policy. Upgrades can occur even if the new model version isn't yet separately available in that region, because the upgrade process makes it available. The practical read: on those deployment types, the model behind your endpoint can change at retirement without a single commit from your team. So the deployment type you picked is a pinning decision, whether anyone made it on purpose or not. Treat it as one. Write down which deployments will move on their own, and put each retirement date on the same list as your other dated dependencies.

For a platform team, that means asking one question per deployment. If this one moved overnight to the listed replacement, would anything we measure tell us? If the honest answer is no, the auto-upgrade is a change you haven't tested yet, on a schedule someone else set. Azure's own guidance points the same way. The schedule says you don't need to wait for a replacement to be listed before evaluating or manually migrating to another compatible model. And it asks you to evaluate available models using your application and data, comparing quality, latency, and cost.

Here's a decision rule a team can use. Treat the listed replacement as one candidate among several, and run your own eval on your own prompts before the retirement date decides for you. If the replacement passes, you migrate on your schedule. If it doesn't, you've bought time to try another model while the old one still answers. Keep that eval set small enough to rerun every time a row in the schedule changes.

Bedrock takes the other road. Its lifecycle page says to migrate to an Active model before the EOL date, and that migration will not happen automatically. After that date, requests made to it will fail, unless there is a private arrangement between you and the provider for continued access. So you're planning for two failure shapes. On one platform, the model can change underneath you and keep answering, so the first sign of trouble might be output that reads a little differently. On the other, the calls simply stop working, which is loud, but leaves you with nothing to serve.

Each shape needs its own alarm. The quiet one needs a quality signal from your eval or your production checks. The loud one needs an error-rate alert, and both need a person's name next to them. Which raises the practical question of what a retirement actually looks like in production, and who owns that alert when it fires at two in the morning.

We just covered what happens when the vendor swaps the model for you, and that brings us to the loud shape, because a quiet swap and a call that stops answering are the same dependency failing in two ways. The thread runs through this whole episode. The model ID you ship on is a dated dependency, and a date nobody owns turns into a page at two in the morning. Start with Azure. Microsoft's lifecycle page says that once a model is retired, it's removed from service, and every inference request comes back with a four ten, Gone.

The stage before retirement has a catch. In the Deprecated stage, whether you count as an existing customer is decided per subscription, based on whether that subscription has ever deployed that exact model version. And a new subscription under the same tenant doesn't inherit access. Amazon Bedrock has its own version of this. Once a model enters its Legacy period, new customers can't adopt it, and existing customers may lose access after fifteen days of inactivity. You also can't create new Provisioned Throughput endpoints for a model in that state.

On the Anthropic side, the deprecations page says impacted customers will always be notified by email and in the documentation. It also says deprecated models are likely to be less reliable than active ones. The practical read is that an email lands in one person's inbox, and an inbox doesn't page anyone. Route those notices into the same tracker where you keep your other dependency dates, with a named owner on each one. And treat that word likely, in the reliability line, as a reason to move early instead of waiting for the retirement date to force it.

Now hold those access rules up against your own architecture. Think about the paths that only run when something else has already gone wrong. A disaster recovery region can sit idle for months. A fallback route may only fire when the primary model times out. And a subscription you created last quarter for a new team may never have called the model at all.

Those quiet paths are the ones I'd worry about. Under rules like the ones we just heard, they could be the first to lose access, and you'd find out in the middle of the outage you built them for. So list every place a model ID is pinned, standby regions and fallback config included, and send a small real call through each path on a schedule. Regular traffic keeps the path in use, and if it's broken, it fails while you're awake. Which brings us to who gets paged. My rule is simple. The team that pinned the model ID owns its date, because they chose it and they're the ones who can test a replacement against their own eval.

In practice, a four ten or any similar hard error on a model call should page that product team first, with a runbook attached. The runbook names the approved replacement ID and the steps to switch to it, so the person half awake at two in the morning isn't making a model decision from scratch. The platform team's job sits one level up. It keeps the inventory of pins and dates, and it makes sure every one of those alerts has a name next to it. What it shouldn't become is the team that wakes up for every feature's model.

There's a real trade-off here. Centralizing every model error on the platform team makes it fast at the mechanics of switching, but it can't judge whether a replacement is good enough for someone else's feature. Paging the owner keeps that judgment with the people who can make it. And the model ID isn't the only pin sitting in that call path. The SDK that sends the request has versions of its own, and upgrading it can break a working integration just as hard, which is where we go next.

We just covered what breaks and who gets paged when a model ID expires, and the same question shows up one layer down, in the SDK that sends the call. That's why this comes next. The thread is the same: anything pinned in that path is a dated dependency, and an SDK major bump changes the API version you send. Anthropic's API asks for a version header on every request, and Anthropic's docs say that if you use the client SDKs, this is handled for you automatically. For any given API version, Anthropic preserves the existing input and output parameters.

The new SDK majors are the first to use the version dated October twenty-first, twenty twenty-six. Anthropic's release notes say they also have breaking changes that don't depend on the API version, and they're licensed under Apache two point oh instead of the MIT License. And here's the detail that matters. Anthropic's migration guide says that if you use an SDK, your requests use the API version that was current when your SDK's major version was released.

Under that new version, a request that sends temperature, top P or top K returns a four hundred error, even at the parameter's default value. The guide says a request that relies on a non-default value can either stop sending the parameter, or stay on the version dated June first, twenty twenty-three. The SDK moves with it. The guide says that as of the latest major versions, the SDK and the CLI no longer have the three parameters, and that the removed parameters are gone from the SDK's types. And for code that calls the API without an SDK, the guide says to set the version header yourself.

The practical read: a dependency bump that looks routine can change the version every call sends, with nobody touching the prompt or the model ID. In a typed codebase, expect a call that still passes temperature to fail in the build or the type checker, which is the cheap place to learn about it. Treat that red build as the alarm doing its job. Before anyone deletes the argument to get back to green, ask the owning team what that temperature setting was for. If it was there for steadier output, the eval is where you find out whether losing it matters for their feature.

For a platform team, that means the four hundred lives on a different path. Look for services that call the HTTP endpoint directly, or set the version header by hand, because the version they send moves only when someone edits that header. A shared wrapper with a hard-coded header won't show up in a dependency diff, so inventory those callers on their own. Here's a made-up example. A gateway pins the SDK, but a batch job next to it sends raw requests with its own header. Someone copies the newer header into that job to match, and every request carrying temperature starts failing, while the model never changed.

So the decision rule: pin the SDK major and the version header together, in one place, and move them as one change. Run that change through the same eval you'd run for a new model, because for the code that calls it, the risk is the same size. Until the eval passes on the new pair, the old pair stays. Which of these moves does a team make first, and how much of it fits in a single sprint? That's where we go next.

We just covered the version header and the SDK major you pin in the same file as the model ID, and that brings us to what a team starts on first, since each pin needs a date and an owner. The thread holds: what you ship on is a dated dependency per platform until your own eval passes on the replacement. Move one, the inventory. One row for each model ID and version on each platform, with the API version beside it, and the retirement date read from that platform's own page or API. Microsoft's schedule lists each Foundry model's retirement date and suggested replacement, and says to use it to plan migrations before a model is deprecated or retired.

Amazon says its lifecycle dates are specific to Amazon Bedrock and may differ from dates published by model providers. So the row holds one date per platform, never one per model. Move two, pin on purpose. Set the version upgrade option on each Azure deployment after reading what each value does, pin the SDK major and version header beside the model ID, and give every date an owner on the on-call calendar. On Azure, for the Standard family of deployment types, Microsoft manages automatic upgrades when a model version is retired, while Provisioned deployments are not auto-upgraded and need a manual migration.

On Bedrock, once a model is Legacy, existing customers may lose access after fifteen days of inactivity, and migration will not happen automatically. Two rules, two calendar entries. As a made-up example, a monthly batch job on Bedrock gets its own lifecycle check. Move three, the gate. A replacement goes live only after your eval passes on it, and the vendor's recommended replacement is the first candidate you test. Microsoft calls its listed replacement its recommended one and, where supported, the target for automatic upgrades, and tells you to evaluate models using your own application and data.

Run that eval well before the date, while a failing result still leaves you time to pick another model. Same model, different dates, and when the vendor swaps it for you, share one point. The date that matters is set by the platform you call, and someone has to own it before it arrives. Three ideas to keep. The deadline belongs to the model and the platform together, so track one date per platform. Pinning is something you configure on purpose, and inactivity rules get watched as their own item. The vendor's recommended replacement is a candidate that goes live only after your own eval passes on it.

That last idea is the next episode: the eval gate a replacement model has to pass before it goes live, including what to measure and the pass threshold, at theplatformradar dot com. Thanks for the drive. See you Thursday.