On October 23, 2026, sixteen days after this post goes up, OpenAI will shut off API access to legacy versions of gpt-4, gpt-4-turbo, o1, o1-pro and o3-mini. OpenAI announced the shutdown on April 22, 2026, and it has been on a public page ever since. On the morning of the 24th, any system still calling those model names will get an error back. Some teams will learn about it from that error. Some always do.
We call this problem lock-in, and I think the word points executives at the wrong fear. In the database era, lock-in was a cage. The vendor wanted you to stay forever, so avoiding vendor lock-in meant keeping a door open in case you needed to leave. AI vendors have the opposite problem with you. They want you off the thing you bought. They retire models to free up capacity for new ones, and they publish the date your current system stops working. In 2026, avoiding AI vendor lock-in is mostly about surviving eviction: someone else's calendar moves you into a model you haven't tested, at a price you didn't negotiate.
That risk needs a different fix. Most of the firms I talk to are still buying the fix for the old one.
The landlord renovates every season
Here is what happened in the last thirty days.
On September 11, 2026, OpenAI deprecated gpt-5.4-cyber and set its removal from the API for October 1, 2026. OpenAI's deprecations page lists the replacement as "The most capable cyber model available to you." The notice ran less than three weeks, and the replacement depends on whatever your account happens to have access to.
On September 22, 2026, OpenAI released GPT-6 Sol and GPT-6 Luna. VKTR reported that they replace the GPT-5.6 tier at half the price. Sol costs $2 per million input tokens and $10 per million output tokens, down from $4 and $20. Luna fell to $0.10 and $0.50. Nine days later, on October 1, OpenAI announced that gpt-5.3-codex, gpt-5.1 and gpt-5.4-nano will shut down on April 1, 2027, with gpt-6-sol and gpt-6-luna as their replacements. On the same day it set January 6, 2027 as the end date for tts-1, tts-1-hd and two gpt-4o-mini-tts snapshots. On August 26 it had already scheduled whisper-1 and the gpt-4o transcription models to shut down on February 26, 2027.
Anthropic runs the same play with better manners. On September 30, 2026, it told developers that claude-sonnet-4-5-20250929 will retire on November 30, 2026, and named claude-sonnet-5-5 as the replacement. Its documentation promises "at least 60 days' notice before model retirement for publicly released models." The same table lists claude-haiku-4-5-20251001 with a tentative retirement date of "Not sooner than October 15, 2026." That floor arrives eight days from now. No deprecation notice has gone out for Haiku 4.5 yet, so the 60-day promise pushes its real end date later. Still, a team running a high-volume pipeline on Haiku 4.5 should already have the replacement under test.
I don't see malice in any of this. On the same page, Anthropic writes that it retires models "to ensure capacity for new model releases," and it has committed to long-term preservation of model weights. OpenAI cut prices in half with its new tier. The new models are better. In their seat I would make the same call. Compute is finite, and every GPU serving a 2025 model is a GPU that can't serve a 2026 one.
Now look at it from your side of the table. Every one of these notices becomes a project on your roadmap that you didn't choose, with a deadline you didn't set. Sora 2 and the Videos API went dark on September 24, 2026, six months after OpenAI told developers on March 24. If you built a product on that endpoint, OpenAI set the end date for your product line, and it did so in a changelog.
Read the calendar as the contract
Executives read the master services agreement. Almost none of them read the deprecations page, and that page is where the terms that matter most actually live.
The MSA covers price, uptime, data handling and indemnity. The deprecations page tells you how long the thing you're paying for will exist. For ordinary deterministic software that would be a detail. For a model it is close to the whole deal. The model is the behavior, and you built everything against that behavior: your prompts, your evaluations, the parsers that read its output, and the compliance sign-off your general counsel gave in March. Change the model and every one of those becomes an assumption again.
The notice periods I read this week ranged from September 11 to October 1 for gpt-5.4-cyber up to six months for Sora 2 and the gpt-4 family. Anthropic lists its active models with retirement floors a year or so out. claude-opus-5-5 is "Not sooner than September 22, 2027" and claude-sonnet-5-5 is "Not sooner than September 28, 2027." Those dates are floors, and nothing guarantees a single day beyond them. For illustration, treat every frontier model you adopt as a lease of about a year, and plan your engineering capacity as if the lease will not be renewed.
The language of these pages tells you something too. Anthropic's docs warn that "Deprecated models are likely to be less reliable than active models." So the period between deprecation and retirement is a grace period, and the vendor has already told you service may degrade during it. Once the notice lands, your old model is living on borrowed time and borrowed attention.
The cyber model got less than three weeks
The gpt-5.4-cyber notice deserves a second look. It was a specialized model, the kind a security team picks because general models refuse the work or fumble it. Enterprises build their deepest dependencies on specialized models, because those are the models with no obvious substitute. This example shows they can also disappear fastest. The replacement text, "The most capable cyber model available to you," amounts to the vendor admitting that your substitute depends on your account tier, which the vendor also controls.
A security operations team that wired gpt-5.4-cyber into triage over the summer had until October 1 to find, test and approve something else. For most enterprises, the change-management board alone takes longer than that.
Same model, different funerals
Anthropic's docs say its deprecation dates "apply to Anthropic-operated platforms," and that "Partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules." So the same Claude model can retire on different days depending on which cloud you bought it through.
Picture a company that hedged by running Claude through both the Claude API and Amazon Bedrock. It now watches two calendars for one model and may run two migrations for one behavior change. Multi-cloud was meant to reduce exposure. Here it doubles the paperwork and splits the dates you need to track.
Why the usual advice on avoiding AI vendor lock-in misses
The standard playbook says to put an abstraction layer between your code and the model, adopt the open protocols, keep two or three vendors live, and you're free. Gateway companies sell this. Consultants sell this. I have sold a version of it myself, and I still think the gateway is worth having.
The gateway handles the easy part. Changing a model name in a config file takes a minute. The hard part is that the new model behaves differently, and the old behavior was what your business depended on.
TechTarget's Liz Hughes made this case to CIOs on October 5, 2026, in a piece headlined "AI vendor lock-in moves beyond the model." Ryan Gross, VP of Anthropic Consulting & Engineering at Caylent, told her: "Swapping the model is rarely where the lock-in sits." Lian Jye Su, chief analyst at Omdia, said: "A system can be fully MCP- and A2A-compliant and still trap context and policy inside one vendor's control plane." Su put the biggest risk this way: "The biggest risk lies in context engineering, memory management, and harness engineering."
I agree with both of them, and I want to go one step further. Say you own every one of those layers: your context store, your memory, your harness, your identity model. The vendor still controls the clock. You can be fully portable and still be forced to port, several times a year, by every vendor you use. Portability lowers the cost of each move. It does nothing about how often you are made to move.
Avoiding AI vendor lock-in therefore has two halves. One is the familiar half: keep your context, your data and your logic out of any single vendor's control plane. The other half almost nobody budgets for: build the capacity to absorb forced upgrades at a pace you choose. A company with the first half and not the second is fully portable and constantly on fire.
The knob that turned into an error
A small detail in Anthropic's docs tells you more than any benchmark. The parameters temperature, top_p and top_k are deprecated for Claude Opus 4.7 and later. On those models, setting any of them to a non-default value "Returns a 400 error." The Python SDK, from v1.0, removes them entirely, so passing them raises a TypeError. Anthropic's recommended replacement is to leave them out and steer the model with prompting.
Now picture a team that spent 2025 tuning temperature to get stable, repeatable outputs from a claims workflow or a contract extractor. Their stability lived in a setting, and the setting is gone. For a workload on Sonnet 4.5, the forced move to Sonnet 5.5 changes the model and also removes a control the team relied on. An abstraction layer can't save them, because it would have to fake a knob the model no longer has.
That is how AI lock-in works in practice. You depend on a behavior, the behavior lives inside weights you will never hold, and the owner of those weights retires them on a schedule. The contract you signed covered the API. Your business ran on the behavior behind it.
There is a quieter version of the same problem. Every prompt your team wrote was, in effect, tuned to one model's quirks. The phrasings that got a clean JSON object out of Sonnet 4.5, the few-shot examples that stopped it from over-explaining, the system prompt that kept it from hedging on refunds: all of it is accumulated adaptation to one specific mind. When that mind is retired, the adaptation becomes a liability. It might still work on the successor. It might also quietly make the successor worse, because the new model doesn't need the workaround and takes it too literally.
Europe regulated the exit and left the eviction alone
The European Union saw lock-in coming and legislated against the old kind. McCann FitzGerald's summary of the EU Data Act says cloud switching charges are to be phased out by 12 January 2027. Until then, providers can charge only fees that "must not exceed the costs incurred by the provider that are directly linked to the switching process." Customers can be asked for at most two months' notice before switching, and providers must complete a switch within 30 calendar days unless that is technically unfeasible.
That is a serious tool against a vendor that holds your data hostage, and it arrives in three months. Free egress makes moving data cheaper, which matters for anyone running retrieval over large document stores.
I know of no statute that gives an enterprise the right to keep calling a model it has validated. The Data Act treats lock-in as a door you need help opening. In AI the floor itself moves under you, and the law says nothing about the floor. The expensive part of every forced move is re-validation, and the Data Act doesn't touch it.
So a European board that reads the January 2027 date as "lock-in solved" has misread its exposure. Leaving gets cheaper. Being made to move costs as much as it did before, and it happens more often each year.
Own the cadence
I give clients five pieces of advice, roughly in order of how much they matter.
Treat the eval set as the asset
The one thing that makes a forced migration cheap is a test suite that tells you, within hours, if the new model does your job as well as the old one. That means hundreds of real cases from your own operations, with known-good answers, graded automatically and rerun every time anything changes. Most companies I meet have a demo script and someone's gut feeling.
The TechTarget piece lists evaluation sets among the layers CIOs should keep under their own control, and I would put them first. The eval set belongs to you. It outlives every vendor. It turns a retirement notice from a crisis into a test run. It also gives you the means to say no. When a vendor announces that the replacement is "better," your eval set lets you answer "better at what" with numbers from your own work.
Build it from production traces you already have. Every escalated ticket, every corrected extraction and every contract clause a lawyer had to fix is a labeled example you paid for once and can reuse for as long as you keep it.
Put migration on your calendar before the vendor does
Say you run AI in six production workflows across two vendors, and each vendor retires something you depend on twice a year, which works out to a forced migration about once a quarter. At that frequency, migration is a standing operation, and it should be staffed like one. That means a small crew whose job is to read the deprecation pages, run each new model against the eval set the week it ships, and move workloads on your schedule.
The timing this fall shows why. GPT-6 Sol shipped on September 22. The deprecation of the models it replaces came on October 1. A team that tested Sol in those nine days started with nearly the full runway to April 1, 2027. A team that waited for the email started nine days behind, and it will spend part of its runway arguing about the budget.
The goal is to run your migrations on a rhythm you set, slightly ahead of the vendor's. Migrating on your own initiative feels like maintenance. The same migration forced on you by a deadline feels like an incident.
Write the clock into the contract
If you spend enough, you have more leverage than you think. Ask for minimum availability terms on the specific model snapshots you run in production, with notice periods longer than the public floor. Ask what happens to a snapshot on Bedrock or Google Cloud when the first-party API retires it, and get the answer in writing. Ask that the replacement be named, priced and available for testing before the notice clock starts.
Some vendors will refuse. A refusal is still information, and it belongs in your risk register next to the workload it affects. A model whose lifespan you can't pin down should carry a contingency budget, just as a supplier with a single factory would.
Keep one model nobody can take away
For workloads where stable behavior matters more than peak capability, run an open-weight model you host yourself, pinned to a fixed version. It will be worse than the frontier. It will also be exactly as good next year as it is today, and for a regulated extraction task that may be the property you need most.
Anthropic says it hopes to make past models publicly available again at some point. Until that happens, the only model you can count on keeping is one whose weights sit on your own disks. Most companies need very few workloads like this. Each of them needs a model it controls.
Price the move into the decision
When OpenAI cut Sol to half the price of GPT-5.6 Sol, the savings were real. So is the cost of migrating, and few finance teams book it. For illustration, a team spending $40,000 a month on a model that moves and saves half gets $20,000 a month back, and if re-validation ties up two engineers for six weeks, the move pays for itself fast. For illustration, the same move on a $3,000-a-month workload may never pay for itself.
A vendor's price cut is a reason to move only where your volume is large. Everywhere else, the cheapest model is the one you've already validated, right up until the day it's retired. Then the migration cost lands anyway, and the only choice left is whether you paid for the eval suite in advance or pay for the incident afterward.
The new shape of the trap
The old fear was being trapped. The current risk is being moved, again and again, by vendors acting in good faith, toward better models, at lower prices, on deadlines that have nothing to do with your business. Each move looks small. Together they make your AI stack a permanent construction site, and the vendors control the permits.
The companies that do well here will not be the ones with the most vendors or the cleverest gateway. They will be the ones that made model migration routine work: an eval set they own, a crew that runs ahead of the notices, contract terms that pin down the clock, and a few pinned models kept in reserve. All of that is architecture. None of it comes in a box.
Buying a multi-model gateway is a purchase. Building the capacity to absorb a forced upgrade every quarter without dropping a customer is a design decision, and it touches engineering, finance, legal and the people who own each workflow. A tool vendor can't make that decision for you, because a tool vendor is one more party with a deprecation calendar.
That design work is what Agor AI Advisory does. We map every model your business depends on to its retirement floor, build the eval sets that turn notices into test runs, write the contract terms that pin down the clock, and set up the migration routine so the next notice lands on a team that is already moving. The next retirement date is already published. You can find it now or hear about it from an error.
Sources
- OpenAI API Deprecations, accessed October 7, 2026
- Anthropic, Claude Platform Docs: Model deprecations, accessed October 7, 2026
- TechTarget, "AI vendor lock-in moves beyond the model," October 5, 2026
- VKTR, OpenAI launches GPT-6 Sol and Luna, cuts API prices in half, September 22, 2026
- McCann FitzGerald, EU Data Act: Switching Cloud Provider, September 17, 2025