You Cannot Write the Standard. You Can Write the Contract.
You do not control the table where the AI standard gets written, and you are not going to. You do have a seat at the table where your own contract gets written, and almost nobody is sitting in it.
Disclosure: the author is founder and managing director of Fellowship Intelligence, an AI strategy, governance, and control layer advisory. This piece describes products sold by companies whose services the firm pays for and uses daily, including for the research behind it. There is a commercial interest here. Read it accordingly.
Last week Google DeepMind launched the DeepMind Institute. One of its four inaugural essays, by Demis Hassabis, proposed a standards body that would evaluate frontier models before release, with developers submitting them voluntarily for review. It is a serious proposal. It deserves the argument it is getting.
You are not in that argument. Neither am I.
To be fair about it, the door is not locked. You can file a comment. You can join a consortium or send somebody to a working group, and several of the bodies doing this work actively want the participation. What none of that gets you is control of the result.
That is not a complaint, and it is not unusual. Hospitals did not write the FDA’s device approval pathway. Airlines did not write airworthiness certification. Banks did not draft the Bank Secrecy Act. The organization that buys and runs a regulated thing rarely controls the standard the thing has to meet, and the ones that do control it are usually the ones you would least want controlling it.
So the standard is being decided upstream. Fine.
What is not fine, and what is strange, is that the document the buyer does write has been left blank.
One of the four questions is a contract question
There are four things an organization should be able to answer about any decision a system made on its behalf. Which version made it. Who approved putting it there. Whether a person checked it, and who. What it drew on.
Start with the first one, because it looks like the easy one and it is not.
“Which version made it” is answerable only if somebody pinned the version. That is not a policy decision, a governance framework, or a maturity level on somebody’s assessment grid. It is a string in a configuration file and a line in an agreement.
And here is the part that surprises people. Pinning the string is the easy half. You can freeze the model version. You cannot freeze the calendar. A pinned model still has a date on which it stops answering, and that date was not set by you, and it is very likely not the date you think it is.
Six months, sixty days, twenty days
Every provider in this piece publishes how much warning you get. The numbers are not close to each other.
OpenAI’s deprecations page commits to at least six months for generally available models, at least three months for specialized variants such as chat and Codex and deep research builds, and as little as two weeks for anything with “preview” in its name. The page adds a sentence that reads like it was written by somebody who had to clean up after it: “We don’t recommend using preview models for business-critical production workloads unless you can migrate on short notice.”
Anthropic’s deprecations page commits to at least sixty days before retirement for publicly released models, to customers with active deployments.
Six months against sixty days. Both published. Both on pages you can open in a new tab right now. If your organization runs both, has anybody put the two numbers side by side?
Both companies also keep their word, and that matters, because the argument here is not about compliance. OpenAI announced the retirement of its older GPT-5 and o3 snapshots on June 11 for a December 11 shutdown, exactly six months. The Sora 2 video models were announced on March 24 for a September 24 shutdown. The Assistants API got a full year. Anthropic’s recent retirements have run sixty to sixty-two days from announcement, which is its published floor and which it hits.
That is the shape of it. Two companies, two promises, both kept, one of them three times longer than the other. If your organization treats “we use AI” as one procurement category, you have quietly accepted whichever number came with whichever contract somebody signed.
There is one more number worth having. On September 11 of this year, OpenAI announced that gpt-5.4-cyber is deprecated and will be removed from the API on October 1. That is twenty days. The policy allows a faster timeline where safety or compliance requires it, and the page states no reason in this case, so I am not going to supply one. What is checkable is the interval. If that model was doing work for you, your migration window was twenty days, and it opened while most enterprise change advisory boards were still scheduling the meeting.
The same model, different last days
Here is the mechanism, in the companies’ own words, before any example.
Anthropic’s page says that its dates apply to Anthropic-operated platforms, which it lists as the Claude API, Claude Platform on AWS, and Microsoft Foundry, and then says this: “Partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules, so a model’s lifecycle status and dates can differ.”
Amazon’s page says the same thing from the other side, and more bluntly: “Model lifecycle dates on this page are specific to Amazon Bedrock and may differ from dates published by model providers (such as Anthropic or Cohere). For Amazon Bedrock usage, only the dates on this page apply.”
Nobody is hiding this. Both parties document it, voluntarily, on public pages, in plain sentences. It is simply that almost nobody has read either one.
Two live examples, because the ones that have already happened are easy to file under history.
Claude Sonnet 4 stopped answering on Anthropic’s API on June 15. On Amazon Bedrock it runs until October 14, which is twenty-two days from now. Claude Opus 4.1 stopped answering on Anthropic’s API on August 5. On Amazon Bedrock it runs until January 8 of next year.
Nothing about those models changed on the day they went dark in one place and kept answering in another. If two teams in your organization are both running “the same model” and one of them bought it through a cloud marketplace, they are not on the same schedule, and the gap is a hundred and twenty-one days in the first case and a hundred and fifty-six in the second.
The completed version of this is a receipt rather than a forecast, and I am not the first to find it. Glevd published it at BenchLM on August 31 under the headline “One Model, Three Retirement Dates,” and their line on it is better than mine: pinning “froze the model version, which was the easy half. It did not freeze the calendar.”
Claude 3 Haiku was deprecated on Anthropic’s own API on February 19 and retired on April 20. Google deprecated it on February 23 and shut it down on August 23. Amazon moved it to Legacy on March 10 and ended it on September 10. Three deprecation announcements inside nineteen days of each other, and then a hundred and forty-three days between the first shutdown and the last. Everybody started the clock in the same three weeks. One channel gave sixty days of runway, one gave a hundred and eighty-one, one gave a hundred and eighty-four.
None of this is particular to one company, and it is worth showing that, because a pattern that only appears at one vendor is a story about that vendor.
AI21 Labs makes a model called Jamba 1.5 Large. Google deprecated it in August 2025 and shut it down on February 27 of this year. Amazon moved it to Legacy in May 2026 and ends it on November 26. Two hundred and seventy-two days between the two last days, for a model neither of them built.
And here the numbers fall out the other way, which is the part worth noticing. Both platforms gave exactly a hundred and eighty-four days of notice. Identical runways. The entire gap comes from the fact that the two clocks started nine months apart. With the Claude model the announcements were near-simultaneous and the runways differed. With this one the runways matched and the announcements did not. There is no single mechanism to learn, which is rather the point: there is no rule that produces the date, only a contract that names it.
One honest caveat on that example. Google lists Jamba 1.5 Large at a Preview launch stage, and Amazon’s table does not state a stage at all. A preview offering having a shorter life is not surprising. But what stage you bought a model at is itself a procurement term, and most buyers could not tell you what stage they are on.
There is a smaller trap sitting next to the large one. Amazon’s page states that during the Legacy period, “New customers can’t use Legacy models and existing customers may lose access to Legacy models after 15 days of inactivity.” A model you keep warm for failover, and therefore do not call, can become unavailable to you because you did not call it. The fallback you were relying on is the one most likely to be gone.
Two weeks ago, the number moved onto the model card
Everything above describes how this worked until September 7.
On that date Amazon split its model lifecycle policy in two. Models that launched on Bedrock before September 7 stay under the old page, which carries a twelve-month minimum deployment floor and a Legacy period of at least six months before end of life. Models launched on or after September 7 fall under a new page, and the new page does not work the same way.
It says: “Before using a model, review the model card for its EOL policy, including how much notice you will receive before the model is deprecated.”
And then: “There are two Legacy periods: 6 months and 45 days. Most models have a 6-month Legacy period.”
Read that again. How much notice you get is no longer a platform policy. It is now a term on an individual model’s card, it has two possible values, and the short one is forty-five days. That is below the sixty-day floor Anthropic publishes for its own operated platforms. Be precise about what that does and does not mean. The card carrying the short term is not an Anthropic model, and nothing here says an Anthropic model on Bedrock would get forty-five days. What it says is that Bedrock now has a setting below sixty.
The new page does not restate the twelve-month deployment floor. It does not restate the extended access provision. That does not mean they were removed, and I am not going to say they were. It means the page that governs a model you adopt today does not contain them, and the page that governs the model you adopted last year does.
Julien Simon found this and published it on September 20, along with a count: of a hundred and twenty-eight models he reviewed, exactly one currently carries the forty-five day term. I read that model’s card myself rather than take the count on faith. It says, verbatim, “EOL no sooner than: Not Applicable, at least 45 day EOL Notice will be provided.” The model launched on September 18. Four days ago.
One model out of a hundred and twenty-eight is not a crisis. That is not the point. The point is that a number which used to be a property of the platform is now a property of the product, it is disclosed before purchase, it has a short setting, and the short setting is in use.
Which means it is now a thing you read before you buy, or a thing you find out about later.
Your model’s lifespan is a procurement outcome, not a technology fact
That is the whole argument, and it is worth sitting with, because most organizations have this filed under the wrong department.
Nothing above is a technology problem. No model got worse. No benchmark moved. No version identifier changed. What changed, three separate times, on three separate dates, was which agreement the request was traveling under.
So when somebody in your organization asks how long you have on a given model, the honest answer is a question: which contract are you on. And if nobody can answer that, then “which version made it” has no owner, and neither does the day it stops answering.
Notice what that does to the other three questions. Who approved putting it there. Whether a person checked it. What it drew on. Every one of those is a record, and every record has to be written while the system is running.
Be careful about what retirement actually takes, because it is not the record. AWS can write Bedrock invocation logs, including the model ID and the request metadata, into a CloudWatch or S3 destination you control, and they sit there until you delete the configuration. What retirement takes is the ability to run it again. You may still be able to show what the system did. You may no longer be able to reproduce it, test whether a different input would have changed the answer, or ask the model anything at all about a decision somebody is now disputing. So the instruction is not to write everything down before the console goes quiet. It is to decide now what you will have to prove later, keep it under retention you own, and know which of those four questions stops being answerable on the day the model does.
Four things you already have the right to do
None of this needs a regulator, a standards body, a new budget line, or anyone’s permission. It needs somebody to open four pages and write down what they find. All four of these are available this afternoon.
Pin the version. Every platform named in this piece exposes dated, version-specific identifiers. Running production against a floating alias is a decision, and it is usually a decision nobody made on purpose. Google’s own documentation is blunt about why that matters: a model alias is “a mutable, named reference,” and aliases “can be moved from one model version to another.” Pin it, log the version each call actually resolved to, and then write down where the pin lives, because a pin nobody can find is a pin nobody can update.
Know which clock you are on. This is the one that pays for the afternoon. Anthropic’s published dates do not govern you if you buy through Amazon Bedrock or Google Cloud, and both of those platforms say so themselves on their own pages. There is a further wrinkle worth checking: Anthropic lists Claude Platform on AWS as one of its own operated platforms and Amazon Bedrock as a partner platform, which means there are two ways to buy the same model on the same cloud provider’s infrastructure, and they run on different schedules. Find out which one your requests actually reach. For anything adopted after September 7, read the model card, not the policy page.
Run the audit you are already entitled to. Anthropic’s console has a Usage page with an Export button, and the CSV it produces breaks usage down by API key and model. That is a partial inventory, covering the Anthropic API usage visible to your organization and nothing else, which is a great deal more than most teams have written down. If nobody can tell you which AI models are running inside your organization, that button is where to start.
Ask what survives, and ask what it costs. Two threads here, and they are different. Anthropic has published commitments on model deprecation and preservation, including preserving the weights of publicly released models for at minimum the lifetime of the company. Read that carefully before you rely on it, because it is a commitment about preservation, not about your access. On the other side, OpenAI’s page says that in some cases developers may be able to provision dedicated capacity for continued access after a model’s shutdown date, and that to explore it you contact sales. Amazon’s page refers to a private arrangement between you and the provider for continued access, and notes that during extended access “you should expect higher pricing, which will be set by the model provider.”
That last cluster is the part I would put in front of a CFO. Continued access to the model your organization built a process around may be available, it is a commercial conversation either way, and you will be having that conversation from inside a dependency you already built. That is not a scandal. It is how supply works. It is also something you would rather know in the quarter you design the system than in the quarter it goes dark.
The room you already own
Every one of those four things was published by the company it describes, on purpose, in public, in language a non-specialist can read. Nobody buried anything. The gap is not disclosure. The gap is that the disclosure is sitting in a documentation page and the decision is sitting in a procurement conversation, and in most organizations those two things have never been in the same room.
The standard is being written somewhere you do not control. That is normal, it has always been normal, and spending your attention on it is a way of feeling involved in a decision that is not yours to make.
The contract is being written in a room you already own. Somebody in your organization signs it, or clicks through it, and sets the date your system stops answering. Whether that person knew they were setting it is the only real question here.
Open the four pages. Write down what you find. Then go and look at who signed.
Next step. If you want a structured read on where decision ownership actually sits in your organization, the Decision Ownership Check is free: ten questions, about two minutes. You get an AI Governance Exposure score from 0 to 100, your tier, and the right next step. A directional read, not a validated diagnostic. It is at fellowshipintelligence.com/decision-ownership-check.
Sources
OpenAI, “Deprecations,” developers.openai.com/api/docs/deprecations.
Anthropic, “Model deprecations,” platform.claude.com/docs/en/about-claude/model-deprecations.
Anthropic, “Commitments on Model Deprecation and Preservation,” 4 November 2025.
Amazon Web Services, “Model lifecycle (Legacy),” Amazon Bedrock User Guide.
Amazon Web Services, “Model lifecycle,” Amazon Bedrock User Guide.
Amazon Web Services, Kimi K3 model card, Amazon Bedrock User Guide.
Amazon Web Services, “Monitor model invocation using CloudWatch Logs and Amazon S3,” Amazon Bedrock User Guide.
Google Cloud, “Partner model deprecations,” page last updated 18 September 2026. The page renders its tables with JavaScript, so it has to be opened in a browser rather than fetched.
Google Cloud, “How to use model version aliases.”
DeepMind Institute, launched 17 September 2026, institute.deepmind.com. Inaugural essay by Demis Hassabis proposing a pre-release evaluation framework for frontier models.
Glevd, “One Model, Three Retirement Dates: Bedrock vs Vertex vs First-Party,” BenchLM, 31 August 2026.
Julien Simon, “At Least 45 Days,” 20 September 2026.
A note on sourcing
Unless attributed to somebody else, every date, quotation and policy statement above was read at the provider’s own documentation page on 20 September 2026 and re-checked at the same pages on 21 September 2026. Dated captures of each page were kept. Documentation pages change; the dates in this piece were accurate on that second reading and are worth re-checking before you act on any single one of them.
Three things above are not provider documentation. The quoted line about freezing the calendar is Glevd’s, from the BenchLM piece cited above. The count of one hundred and twenty-eight Bedrock models reviewed is Julien Simon’s, published two days before this edition, and has not been independently reproduced here; the forty-five day term itself was read directly on the model card rather than taken from that count. The day counts throughout were computed from the published dates rather than quoted from anyone.
This piece makes no claim about why any particular model carries any particular notice period, and no claim about the intentions of any company named. Every provider fact in it was published voluntarily by the company it describes, on a page anyone can open.
The author is not a lawyer and nothing here is legal advice.
