On August 26, 2026, OpenAI shuts down the Assistants API. Every call to /v1/assistants, /v1/threads, and /v1/threads/runs will return an error. No degraded mode. No grace period. No extension. OpenAI has said publicly there will be no automated migration tool from Threads to Conversations. Teams that built on the Assistants beta have six days to be done.
The same week, Google's Gemini Enterprise Agent Platform retires the Grok 4.1 model family on August 20. Kore.ai retires six network types on August 29. Two months earlier, Anthropic retired Claude 3 Opus on June 15. A set of billing parameters on the Claude API changes on November 3. That is a single calendar quarter of sunsets across four vendors.
If you signed a vendor contract in early 2026, half of what you signed for is already scheduled to disappear.
That is the thing most enterprise buyers still miss when they run a bake-off. Capability is the free variable. Sunset cadence is the paid one, and the invoice arrives in the form of engineering time you did not budget.
Choosing between AI vendors is choosing between sunset cadences
The polite version of the enterprise AI vendor conversation still centers on benchmarks. Which model scores higher on the coding eval, which model wins on the reasoning suite, which one has the longer context window this month.
That conversation was already stale two versions of every model ago. On any published benchmark that matters, the top four labs cluster within a few points of each other, and the ordering flips every quarter. Buying on benchmark is buying on a snapshot that will not survive the audit period.
The real variable when you are choosing between AI vendors is the sunset clause. Not written into the MSA. Written into the vendor's public model deprecation policy, which no one on the procurement call has read.
Anthropic commits to at least 60 days' notice before retiring a publicly released Claude model. OpenAI commits to at least six months for generally available models, three months for specialized variants, and as little as two weeks for previews. Google publishes retirement dates per model on Gemini Enterprise, and the schedules diverge from the same model's schedule on Vertex or Bedrock. AWS runs its own clock on top of that.
You do not get to negotiate that clock. You inherit it.
The math of a sunset
Every sunset is a migration bill. That bill has a fixed floor and a variable ceiling.
The fixed floor is the engineering work to swap the model, re-run every eval you own, re-tune every prompt, re-tune every retrieval config, re-tune every tool schema, and re-issue every human-facing artifact that mentioned the old version. On a serious production deployment with a hundred tools and a few thousand prompts, that is a real quarter of work for a real team.
The variable ceiling is what breaks. Prompts silently regress. Tool calls change shape. A retrieval strategy that worked on the old model produces empty answers on the new one. A router that scored calls one way starts scoring them another. Customers file support tickets that read like feature regressions because they are.
If your vendor sunsets a model on 60 days' notice, that bill lands twice a year at that vendor's pace. If your vendor sunsets on six months, that bill lands once a year at that vendor's pace, and you can plan around it.
Both are legitimate business models. Both cost real money. The number you are buying is the frequency, and the frequency is a decision you cannot delegate to the eng team once the contract is signed.
The reference customer vanished
For decades, the classic move on any enterprise software selection was to ask for reference customers. Big Corp signed a five-year deal on this product two years ago. Call them. Ask them what broke.
That move does not survive a 60-day sunset. A reference customer running Claude 3 Sonnet in production a year ago is running something else today. Their answer to "how has it been" is about the six migrations they ran, not about the product you are being sold.
The same problem applies to case studies. A published case study from May 2026 about a bank running an OpenAI Assistants API workflow is a case study about work that is being ripped out this month. The bank that made the presentation on stage in the spring is running something else in the fall.
The old reference signal was: this product works in the wild. The current reference signal is: this customer has survived one migration cycle at this vendor's cadence. That is a different fact about a different asset, and enterprise buyers who read it as the old fact will be surprised twice a year.
The three questions that actually matter
If the deprecation schedule is what you are actually buying when you are choosing between AI vendors, then the diligence flips.
The first question is the notice window. In writing, on the vendor's public policy page, how many days before shutdown does the vendor commit to warning you. Anthropic says 60. OpenAI says 180 for GA, 90 for specialized, 14 for previews. Google publishes per-model. Ask for the specific number for the specific model tier you plan to run. If the answer is a marketing paragraph and not a number, that is the answer.
The second question is the migration path. When the current model retires, what replaces it, and can you point to a customer who ran the migration cleanly. The OpenAI Assistants-to-Responses migration is instructive here. There is no automated tool. Assistants become Prompts. Threads become Conversations. Runs become Responses. Every line of glue code you wrote against the old shape you rewrite against the new one. That is a vendor telling you, quietly, that the migration bill is yours.
The third question is the divergence. If the same model is offered through more than one platform, do the schedules match. They do not, ever. A Claude model on the Anthropic API, on AWS Bedrock, and on Google Vertex is three different sunset schedules. If your architecture assumes those are the same product, you own three surprises for the price of one.
What the multi-model discipline is actually solving for
A 2026 survey of 100 enterprise CIOs found that 37% were running five or more AI models in production, up from 29% the year before. In parallel, 81% of U.S. enterprise executives reported being at least somewhat concerned about their dependency on a specific AI vendor, and 47% said losing their primary AI vendor entirely would disrupt a key business function.
The trade press reads those numbers as a cost story. The real story is a sunset story.
If a single vendor's next retirement notice can take down a key business function, you are running a demo that happens to have real users on it, and the vendor's next sunset schedule will tell you so. Multi-model discipline exists to keep any one vendor's sunset from taking a business function down. Cheap-token routing falls out of the same seam.
The routing layer that lets you send a summarization task to one vendor and a tool-use task to another is the same routing layer that lets you divert traffic in a week when one of your vendors ships a surprise deprecation. If you already have the seams cut, the sunset costs you a Tuesday. If you do not, it costs you a quarter.
Cutting those seams is a build problem. It is not a purchase.
The RFP was designed for a different asset
Traditional enterprise software procurement assumes the thing you are buying has a stable identity across the contract term. A CRM licensed in 2016 is still, in essential shape, the same CRM in 2020. The identity persists. The RFP that evaluates it can score it.
An AI model has no such identity. The vendor decides, on its own schedule, when the model you signed for stops existing. The model is a subscription to a moving target held by the vendor's product team. The RFP that scored the model at time of signature is scoring a snapshot the vendor already plans to overwrite.
That is why the enterprise procurement checklist that worked for SaaS is producing bad AI vendor decisions. It scored capability, price, and reference customers. All three of those variables now depend on when the vendor next chooses to move the target. None of them are visible to the checklist.
The checklist that works asks a different question set. What is the notice window in writing. What has the vendor sunset in the past twelve months. How many active models has the vendor kept in the field simultaneously. What is the vendor's public track record on honoring the notice window. Have they ever pulled a model early. Have they ever extended a sunset when customers pushed back. Do their platform partners follow the same schedule.
That question set produces a different vendor short list than the benchmark-driven one, and the short list survives the year.
The build that outlasts the vendor
There is one architectural pattern that survives every vendor sunset, and it is the one most enterprise deployments still refuse to invest in.
You separate the interface from the implementation. Every AI-touching feature in your system calls an internal contract that describes the task in your language. Summarize this document. Extract these entities. Draft this reply. Route this ticket. Behind that contract, a routing layer chooses which vendor, which model, and which prompt to use for that specific task, at that specific time, for that specific customer segment.
When the vendor sunsets the model the router was calling, the router changes. Nothing above the router changes. No product code changes. No prompts in a hundred places change. The feature does not regress because the feature was never coupled to the model.
That pattern is old. It is the same pattern that made database abstraction layers survive vendor changes, that made queue abstractions survive queue changes, that made object storage abstractions survive S3-competitor cycles. It works.
What is new is that most enterprise AI deployments skipped it. The first version of every AI feature was hard-coded to a specific vendor's SDK, with a specific vendor's model name, and with prompts tuned to that specific model's quirks. That code shipped fast, which felt like a win. It also shipped a permanent dependency on that vendor's sunset schedule, which is the loss the team will feel every time the vendor issues a notice.
The right time to introduce that separation is before the first sunset lands. The wrong time is during the migration, under deadline, with a support queue filling up.
What the sunset says about the vendor
Read the sunset schedule as a signal about who the vendor thinks its real customer is.
A vendor that ships two-week notice on previews is telling you it optimizes for research velocity. Its real customer is the researcher and the early startup. If you are a bank, you are the wrong audience, and the two-week notice will land at the worst possible time for you.
A vendor that ships six-month notice on GA is telling you it optimizes for enterprise stability. Its real customer signs annual contracts and needs a quarter to plan. That vendor will feel slower on the frontier, and that is a feature of the same policy.
A vendor whose sunsets diverge across platforms is telling you the platform partner controls the calendar, and the platform partner has different customers with different priorities. You inherit the intersection of both roadmaps.
None of these postures disqualify a vendor. Each is informative. The mistake is treating them as interchangeable and choosing on capability. Capability converges. Posture does not.
Why negotiation does not fix this
The temptation, faced with a sunset schedule, is to negotiate it. Ask the vendor for a longer notice period in the MSA. Get the AE to promise something in a side letter. Push for an SLA credit if the vendor breaks its own policy.
That approach reads like diligence and produces almost nothing. The vendor's public deprecation policy is what the vendor will actually do. The side letter is what the vendor's legal team will settle over when the sunset lands. The AE will offer a service credit against the outage. That credit is a rounding error against what the migration cost your team.
The remedy is architectural. Build the seam. Own the routing layer. Keep the interface stable inside your walls even when the implementation churns outside them. That is a build the vendor cannot sell you, will not sell you, and does not want you to prioritize.
It is also the only work that compounds. Every sunset you survive with the seam intact is a sunset the next team through the door does not have to fear. Every hard-coded integration you ship without the seam is a dependency you will pay for the next time the vendor moves the target.
Nine months from now, the specific vendors will be different. The specific model names will be different. The sunset dates will be different. The build that owns the seam will still be running.
The consultation that starts here
Choosing between AI vendors is an architecture decision that a lot of buyers still route through procurement. That is how you end up with a five-year commitment to a sunset schedule you never read.
The right partner architects the seam between your business and every vendor, so no single vendor's calendar becomes your calendar. That is a design job before it is a purchase, and it pays back every time a public deprecation notice lands in your inbox.
Agor AI Advisory architects that seam. We read the deprecation policies your procurement team missed. We build the routing layer that keeps the next sunset inside a Tuesday. We keep the interface stable inside your walls while the vendors churn outside them. And we do it before the notice lands, when the work is cheap, rather than after, when the work is a crisis.
Sources
- OpenAI Assistants API beta deprecation, August 26 2026 sunset
- OpenAI Assistants migration guide
- Anthropic Claude model deprecations policy
- AI Model Deprecations 2026: Dates and Replacements (benchr)
- Gemini Enterprise Agent Platform release notes
- Buying AI Tools: The Procurement Checklist for 2026 (Digital Applied)
- Why Enterprises Need a Multi-Model AI Strategy (Kai Waehner, August 2026)
- Avoid AI Vendor Lock-In: A Multi Model AI Strategy 2026 (AvePoint)