Why the useful response to OpenAI’s board crisis was a days-to-switch number

The week

On Friday, November 17, 2023, OpenAI’s board did something few people outside the company saw coming. It announced that it had removed Sam Altman as chief executive, saying he had not been consistently candid in his communications with the board.

Hours later, Greg Brockman, the company’s president, was removed as board chair and then resigned from the company. Mira Murati, the chief technology officer, was named interim chief executive. Several senior researchers resigned in the following hours.

OpenAI was, by then, the best-known name in generative AI, the kind of artificial intelligence that writes text, answers questions and summarizes documents in response to plain-language instructions. Its models were available to businesses through an API, short for application programming interface. An API is a doorway one piece of software uses to talk to another. A company’s own system sends a request through it and gets the model’s answer back, without a person ever opening a chat window. Thousands of businesses were building products this way.

The upheaval came less than two weeks after OpenAI’s first developer conference, DevDay, on November 6. There the company had announced GPT-4 Turbo, a cheaper version of its most capable model, along with an Assistants API and custom versions of ChatGPT. Two days later, ChatGPT and the API suffered outages that OpenAI attributed to abnormal traffic consistent with a distributed denial-of-service attack. Enterprise developers had spent the month absorbing new features and new prices, and had already seen the service go down once.

What followed played out in public, almost hour by hour. Over the weekend and the following days, most of the company’s employees signed a letter threatening to leave unless the board resigned. Microsoft, OpenAI’s largest investor and cloud provider, said it would hire Altman and colleagues to lead a new AI research group. For a moment it looked possible that much of the talent behind the technology might simply move across the street.

The sequence moved quickly. On Sunday, November 19, the board named Emmett Shear, a former chief executive of Twitch, as interim chief executive in place of Murati. On Monday, Microsoft chief executive Satya Nadella announced that Altman and Brockman would join Microsoft. By then the employee letter carried the names of nearly all of OpenAI’s roughly 770 staff. Among them was Ilya Sutskever, a board member who had backed the removal and then said he regretted it.

Then, late on November 21, OpenAI announced an agreement in principle for Altman to return as chief executive with a reconstituted initial board. The whole episode lasted about five days, and it unfolded in the week of the U.S. Thanksgiving holiday, when many executives were trying to leave the office.

The new initial board was chaired by Bret Taylor, a former co-chief executive of Salesforce. Its other members were Larry Summers, a former Treasury secretary, and Adam D’Angelo, chief executive of Quora, who had served on the previous board. Altman and Brockman did not take board seats.

Customers did not wait for the outcome. The Information reported that more than 100 OpenAI customers contacted Anthropic in the days after the removal, and that others reached out to Google Cloud, Cohere and Microsoft Azure. For many enterprise teams, those days were the first time anyone had asked how hard a move would be.

The policy backdrop was shifting at the same time. President Biden had signed an executive order on AI on October 30, and the Office of Management and Budget had issued draft guidance on federal agencies’ use of AI on November 1. In Europe, negotiators on the AI Act were still arguing over how to treat the most capable general-purpose models.

For most people it was a dramatic piece of corporate theater. For banks, health systems and government agencies that had begun piloting AI tools built on OpenAI’s models, it raised a more practical question. If the company supplying a technology you are starting to rely on can be turned upside down over a weekend, how exposed are you, and what could you do about it?

The services kept running. But the week offered a free test, and the organizations that took it seriously learned something about how locked in they already were.

By late 2023, banks, health systems and agencies were piloting generative AI, many through OpenAI models reached directly or through Microsoft’s Azure OpenAI Service, a version of those models hosted inside Microsoft’s cloud. For a few days that November it was reasonable to ask whether the company behind a fast-growing set of enterprise deployments would hold together.

Services ran normally throughout. The episode still made a point that third-party risk programs had not absorbed. Third-party risk programs are the processes regulated organizations use to vet and monitor their suppliers, usually through questionnaires, audits and contract reviews. They are built to catch things like weak security or shaky finances. The governance of a model developer was something else: unusual, opaque from outside, and capable of changing over a weekend. No questionnaire would have scored that risk accurately.

What a buyer could manage was its exposure, measured as the cost and time of moving a given use to another model. That cost has three components: what the contracts allow, what the architecture allows, and what the operation can do while a move happens. Together they produce a single number a board can ask for.

Why one model is not a drop-in for another

A large language model is a very large piece of software trained on vast amounts of text to predict and produce language. Companies such as OpenAI build these models, a process that takes enormous computing power, and then rent access to them. An organization rarely runs the model itself. Instead its applications send text to the provider and receive text back, paying by volume.

In principle, that makes models look interchangeable, like electricity from different utilities. In practice, they are more like experienced employees with different habits. Two models given the same instruction will produce different answers, with different strengths, quirks and failure modes. An instruction carefully tuned to get good results from one model, known as a prompt, may get mediocre results from another.

Many applications also use a technique called retrieval. The organization’s own documents are converted into a numerical form, called embeddings, so the system can find relevant passages and hand them to the model. Embeddings produced by one provider’s tools are often not compatible with another’s, so moving can mean reprocessing a whole document library.

Switching models therefore resembles replacing a trained team member more than swapping one printer for another. It can be done, but only quickly if it was planned for.

What changes when the model changes

The differences run deeper than writing style. Models break text into units called tokens in different ways, so the same document costs a different amount on each, and fits differently within each model’s limit on input size, its context window. Providers price input and output tokens separately, and the ratio differs. A workload that is cheap on one model can be expensive on another for reasons unrelated to quality.

Applications also depend on structured behavior. Many ask the model to return data in a fixed format, or to call a function in the organization’s own systems, a feature providers call function or tool calling. Each provider defines those formats its own way. Safety filters differ too. A request one model answers, another may decline, which matters in health care and law enforcement, where legitimate work involves sensitive topics.

Some of the deepest lock-in comes from customization. An organization that fine-tunes a model, further training it on its own examples, usually gets a version that exists only on that provider’s platform. The training data can move. The tuned model cannot.

Change arrives even without switching vendors

Providers update and retire their own models. A version an application was tested against may be replaced by a newer one, and older versions are typically withdrawn on a published schedule. An organization that never changes provider will still change models every year or so. Everything that makes a switch to another vendor expensive also makes a routine upgrade risky, so portability work pays off even for buyers content with their current supplier.

Three routes to a model, three sets of terms

Organizations reached models by several routes. Some signed direct API agreements with developers. Others used cloud platforms hosting those models under the cloud provider’s enterprise terms, or software products with AI features built on someone else’s model. The routes carry different continuity profiles.

• Through a cloud platform. A model hosted in a cloud provider’s environment, under that provider’s agreement, may keep running even if the developer is in turmoil.
• Direct from the developer. A direct agreement depends on the developer itself.
• Embedded in other software. An embedded feature depends on a software vendor whose own model supplier the customer may not know. A customer relationship tool that offers “AI summaries” is using someone’s model, and the customer may not be told whose.

Procurement and legal teams can map each AI use to its route and read the relevant terms on four points:

1. Notice before a model is retired or materially changed.
2. Data retention and deletion at exit: what happens to your prompts, documents and outputs when you leave.
3. Transition assistance: whether the provider will help you move.
4. Exclusivity: whether the contract restricts using another provider’s model for the same function.

For embedded AI, the questions go to the software vendor in writing: which model provider it uses, whether it can switch, and how customers will be told.

Regulators were already pointing in this direction. Interagency guidance on third-party risk, finalized by the banking agencies in June 2023, already expected banks to consider concentration and continuity for critical vendors. A model provider becomes one when a use is important to operations, even if the contract is small. The trap is that an AI pilot may start on a modest budget line, well below the threshold that triggers a full vendor review. It can then become part of how work gets done before anyone has looked at it.

Contracts also shape the price of leaving. Committed-spend agreements are promises to spend a certain amount with a cloud provider over several years in exchange for discounts. They can make a second provider’s model look expensive even when it performs better. Free credits for a pilot can create a dependency before anyone has decided to accept one. Finance should know which AI commitments run past the next two years and what share of each is tied to a single model family.

The same route means different things by sector

The route also determines which compliance obligations a buyer can meet, and that narrows the set of real alternatives.

• Banks. Third-party risk guidance applies on every route. When a model informs decisions such as credit, fraud or complaints handling, model risk management guidance (SR 11-7 at the Federal Reserve, with a parallel OCC bulletin) expects validation, ongoing monitoring and documented limitations. An alternative model has to pass the same review before it can take over.
• Broker-dealers and investment advisers. Supervision and recordkeeping obligations follow the communications an AI tool helps produce. A replacement model must fit inside the same supervisory and archiving controls.
• Health systems. A provider that processes protected health information for a covered entity is a business associate under HIPAA and needs a business associate agreement. Whether a route offers one, and on what terms, can rule out alternatives entirely.
• Federal agencies. Cloud services generally need a FedRAMP authorization at the right impact level. In late 2023 that narrowed the field considerably, so an agency’s realistic fallback list could be much shorter than the market’s.
• State and local governments. Purchasing often runs through cooperative contracts and state IT approvals. Systems that handle criminal justice information must also meet the FBI’s CJIS Security Policy.

Where the data goes on each route

Data handling was one of the clearest differences in 2023. OpenAI had said in March 2023 that it would not train its models on data submitted through its API by default. Microsoft’s Azure OpenAI Service kept prompts for up to 30 days for abuse monitoring, with an application process for eligible customers to have that turned off. Those terms change over time, and they differ between routes to the same underlying model. A move between routes can therefore change a privacy assessment even when the model stays the same.

A thin layer and a test set

An application built tightly against one provider’s API, prompt conventions and proprietary features is expensive to move. Compare an application with a thin abstraction layer between business logic and the model, and prompts stored as versioned configuration. An abstraction layer is a small piece of software that sits in the middle and translates; the business application talks to it, and it talks to whichever model is plugged in. Storing prompts as versioned configuration means keeping them as managed settings rather than burying them in code, so they can be adjusted and tracked. If the application’s retrieval pipelines also avoid one provider’s embedding format, it can be pointed elsewhere far faster.

The piece most often missing is an evaluation suite: a set of the organization’s own tasks, with expected outputs or scoring rules, that measures whether a model is good enough for a specific use. It is built from the organization’s own work rather than a generic benchmark.

For a contact center summarization tool, it might be a few hundred real call transcripts, de-identified, with summaries rated by supervisors. For a document classification workflow, it might be a labeled sample with accuracy thresholds set by the business owner. Without a suite, nobody can say whether an alternative model is acceptable, and switching becomes a leap of faith. With one, switching is a test run that takes days.

The suite also earns its keep in ordinary times. Providers update models regularly, and behavior on a specific task can change without notice. Running the suite on each new version catches regressions, things that used to work and no longer do, before customers or caseworkers do. It also gives banks evidence for model risk management reviews, since supervisory model risk guidance such as SR 11-7 can reach generative AI uses that inform decisions.

Take a regional bank that uses a model to summarize customer complaints for its compliance team. Version one was built directly against a single provider, with prompts written into the code and no test set. Moving it would take months of rework and argument about whether the new summaries were “as good.” Version two routes requests through a small internal gateway, keeps prompts in a managed library, and comes with two hundred anonymized complaints whose ideal summaries were approved by the compliance team. The bank can now try an alternative model in an afternoon and have a scored answer by the end of the week.

What goes into an evaluation suite

A useful suite has four parts. The first is a set of real cases, drawn from the work and stripped of identifying details where needed. The second is a scoring method: exact answers where they exist, rubrics where judgment is required, and a sample reviewed by people who do the job. The third is a pass threshold set by the business owner before any model is tested, so the bar does not move to fit a favored option. The fourth is a record of every run, showing which model version was tested and what it scored.

Uses that affect customers need extra slices. A bank testing a model that drafts responses to complaints should check whether quality holds across products and customer groups, because fair lending and consumer protection rules do not relax for automated drafts. A health system should test the clinical edge cases its own staff worry about, alongside typical notes.

Some teams use a second model to grade the first, which is faster than human review. That works for screening, but it inherits the grader’s blind spots, so human review of a sample should stay in the loop for important uses.

The cost is mostly people’s time. Subject-matter experts have to select cases and agree what a good answer looks like, and that work competes with their day jobs. Once built, a suite is cheap to run and needs only periodic refreshing as the work changes.

The trade-offs of building for portability

Portability has costs, and its critics have a fair case. A thin abstraction layer tends to expose only features every provider supports. Teams that want a provider’s newest capability may have to work around their own gateway to use it. The gateway is one more component to secure, patch and keep running, and if it is bought rather than built, one more vendor.

Another route to independence is an open-weight model, one whose trained parameters are published, such as Meta’s Llama 2, released in July 2023 with a license allowing commercial use. An organization can run such a model on its own infrastructure as a fallback. That removes dependence on a model provider’s operations but adds the cost of computing capacity and the skills to run it. In 2023, open models also generally trailed the leading commercial ones on harder tasks.

The sensible balance differs by use. A drafting assistant used by a few staff may justify none of this. A tool embedded in a regulated process probably justifies most of it.

Keeping the work going while the model changes

Even with good contracts and architecture, a move takes time, and the third component is what happens in the meantime. For low-stakes uses such as drafting assistance, staff can work without the tool for a while. For uses embedded in customer service, claims intake, prior authorization or case management, the organization needs a defined degraded mode, meaning a planned, lesser way of keeping the service running. That could be a second model already approved for the use, a reduced feature set, or a return to manual processing with enough staff who still know how.

Continuity planning for AI can follow the logic used for any important business service. Identify which uses would cause harm if they stopped, set a tolerance for how long each can be unavailable, and test the fallback at least once a year.

The test has a useful side effect. If a team cannot describe how its process runs without the model, it may be relying on the model in ways nobody has reviewed. That is a governance finding in its own right. Say a county benefits office uses an AI tool to draft letters to applicants. When asked to run a day without it, the team discovers that two newer caseworkers have never written one of those letters by hand. It also finds that a template the tool relied on is no longer approved. Neither problem had anything to do with OpenAI. Both came to light only because the office tested a day without the tool.

Degraded modes by type of use

• Internal drafting and summarization. Staff work without the tool and accept slower output. The plan only needs to say so, and to confirm that the templates the tool relied on still exist.
• Customer-facing chat. The service falls back to static answers and a human queue. The contact center has to absorb the overflow, so the plan should say who calls in extra staff.
• Decision support. Where a model helps triage claims, alerts or applications, the fallback is usually the rules or manual review that preceded it. Backlogs build quickly, so the plan should set which cases go first.
• Batch processing. Overnight jobs, such as classifying documents, can often wait a day or two. The risk is a backlog that collides with a deadline, such as a regulatory filing or a benefits payment cycle.

Capacity belongs in the fallback plan

A second model approved on paper may not be usable on the day. Cloud providers allocate model capacity in quotas, and raising them can take time, especially when many customers are trying to move at once. An organization relying on a standby model should arrange the access and the quota in advance and send a little real traffic through it, so the fallback is known to work. Rate limits matter as well. A standby model sized for testing may throttle a full production load, so the plan should state the volume the fallback must carry and confirm it can.

Operational resilience rules were heading the same way. The EU’s Digital Operational Resilience Act, adopted in late 2022 and applying from January 2025, requires financial entities to have exit strategies for technology services that support critical or important functions. UK regulators’ operational resilience rules ask firms to set impact tolerances for important business services. U.S. supervisors had no AI-specific equivalent, but the logic of tolerances and tested fallbacks carries over directly.

Days to switch, use by use

The three components only become useful when they are combined into something an executive can compare and act on. Suppose a health system sets out to build its days-to-switch figures.

It has four AI uses that matter. It starts by listing each one, the route by which it reaches its model, and who owns it.

• Clinical note drafting, reached through a cloud platform under the health system’s existing enterprise agreement.
• Prior authorization letter drafting, built by an internal team directly against one developer’s API.
• Patient portal chat, a feature inside a vendor’s patient engagement product.
• Policy search for staff, an internal tool that retrieves passages from the system’s policy library.

For each use, the owner answers three plain questions: what the contracts allow and how quickly, what the engineers would have to change, and how the work would continue while they did it.

The answers vary sharply. Clinical note drafting turns out to be relatively portable: the cloud platform offers more than one approved model, the team built a small gateway, and there is a scored test set of de-identified notes. Estimated days to move: about ten. Policy search looks simple but is stuck on one provider’s embedding format, so the whole library would need reprocessing and retesting; estimate, forty. The prior authorization tool has prompts buried in code and no evaluation suite. Nobody can say what “good enough” means for an alternative, so the honest answer is “unknown, probably months.” The patient portal chat is the most surprising. The vendor has not said which model it uses, and the contract is silent on switching. Days to move: not in the health system’s control at all.

Those four lines, reported to the risk committee, do more than any questionnaire. They show the board that the riskiest dependency is not the most visible one, and that the cheapest fix is a written question to a vendor. They also show that the prior authorization tool, which affects patients waiting for care, needs an evaluation suite and a manual fallback before it grows further. The figures are estimates, and everyone knows it. Their value lies in the conversations they force and the trend they show from one quarter to the next.

Notice, too, what the exercise does not require. The health system did not need to predict whether any provider would have a crisis. It only needed to know what a crisis would cost it, use by use.

The second quarter shows what the figures are for. In this illustration, a letter to the patient engagement vendor produces the name of its model provider and a commitment to give notice before any change. The prior authorization team moves its prompts into a managed library and assembles a first test set of a hundred de-identified cases. Neither step is expensive. Both turn an unknown into a number, which is what the committee needs to set priorities, and the next report shows the longest figures getting shorter.

How to estimate the number

A days-to-switch figure is the length of the longest chain of work needed to move a use, not the sum of every task. Four stages usually run partly in sequence.

1. Commercial and legal. Confirm whether an alternative is already under contract with the data terms the use requires. If not, add procurement, security review and, in health care, a business associate agreement.
2. Engineering. Change the integration, adapt prompts, and reprocess any document library tied to one provider’s embeddings.
3. Validation. Run the evaluation suite and, for uses under model risk management, complete whatever review the policy requires before production use.
4. Rollout. Move traffic in stages, watch quality and cost, and keep the old route available until the new one has proved itself.

Ranges are more honest than single numbers. The longest stage is often validation or contracting rather than code, and teams that report only engineering effort will understate the figure every time.

The best way to improve the estimate is to run a real switch. Moving one modest use to an alternative model once a year, even temporarily, tests the contracts, the gateway, the suite and the people. It also turns a guess into a measurement.

The case against measuring it

The objections are serious. Dual-sourcing costs money and engineering time, and the most capable model at any moment may be meaningfully better than the alternatives. A bank that holds itself to the lowest common denominator may deliver a worse service. The market also has few frontier developers, so diversifying away from one may only shift concentration to another, or to the cloud platform that hosts them all.

The answer is that the metric does not require dual-sourcing. It asks what a move would cost and lets the risk committee decide, case by case, whether that cost is acceptable. For many uses the answer will be yes. The danger lies in uses where the cost is high and nobody knows it.

The concentration objection deserves a direct answer too. A health system whose four uses all depend on one cloud platform has not escaped concentration by choosing two models on that platform. The exercise should record the platform as well as the model, so that shared dependencies show up.

Money, risk, regulators and staff

Model portability is more than technology housekeeping. The stakes reach money, risk, customers, regulators and staff.

• Money. Lock-in weakens negotiating power. A buyer that can credibly move has a better conversation at renewal than one that cannot.
• Risk. A sudden change at a supplier, whether governance turmoil, a pricing change or a model retirement, lands hardest on the organizations with no alternative ready.
• Customers and citizens. If an AI tool sits inside claims, service or benefits processes, an interruption reaches real people quickly.
• Regulators. Banking supervisors already expect concentration and continuity to be considered for critical vendors, and model risk expectations can reach AI that informs decisions. Being able to show an evaluation suite and a tested fallback is a far stronger answer than a vendor questionnaire.
• Staff. Skills fade. A fallback that depends on manual work needs people who still know how to do it.

Prices moved fast, in both directions

The commercial side of portability was already visible that month. At DevDay, OpenAI priced GPT-4 Turbo well below the GPT-4 model it improved on. Buyers able to test and adopt the new model quickly captured the saving. Buyers whose applications were tied to an older version, with no way to test the change, paid more for longer.

Prices can also move against a buyer. Discounts tied to committed spending, changes in which models a subscription includes, and the retirement of a cheaper model all shift costs. A buyer with a credible alternative has more options when that happens.

What an examiner or auditor would ask to see

For a bank, an examiner reviewing an AI use would expect to find it in the third-party inventory, with a risk rating that reflects its importance rather than its spend. They would look for due diligence on the route, contract terms on data and termination, and ongoing monitoring. For uses that inform decisions, model risk documentation applies as well. For a health system, auditors would start with the business associate agreements and the security risk analysis. For a federal agency, inspectors general would look first at the agency’s AI use case inventory and the risk practices attached to each use.

Different organizations, different first moves

The starting point depends on how an organization reaches AI. A community bank or credit union in 2023 mostly met generative AI inside products from its core, digital banking and contact center vendors. Its exposure was almost entirely embedded, and its first move was a letter to each of those vendors asking whose model they used and what would happen if it changed.

A large bank building its own tools faced the opposite problem. It needed an internal gateway, a shared evaluation practice and a model risk process that could approve alternatives quickly. Health systems sat in between. Epic and Microsoft had announced in April 2023 that they would bring Azure OpenAI into Epic’s software, beginning with drafting replies to patient messages. Many health systems would therefore meet generative AI first through their record vendor’s roadmap. Agencies had to add FedRAMP status and their AI use case inventories to every list.

Where portability is won or lost

A prepared organization has an inventory of AI uses, each mapped to its contract route, and contracts with notice, exit and transition terms. Its applications are built with a thin layer between the business and the model. Each important use has an evaluation suite and a defined degraded mode, and a regular report goes to the risk committee.

Portability is usually lost in small ways. A small contract gets treated as a small risk, when importance to operations, not spend, should decide how closely a supplier is managed. Nobody asks whose model is inside a product, and embedded AI is the easiest dependency to miss. Pilot credits are accepted without an exit plan, though free is not the same as costless. The evaluation suite is skipped, leaving every switch, and every model update, to guesswork. And the old manual process is assumed to work without anyone testing it.

A simple metric ties the three components together. For each important AI use, record the estimated days to move it to an approved alternative, and report the longest figures to the risk committee. The figure will rarely be precise. It shows where an event like November 2023 would hurt.

Who owns the number

Each figure needs an owner who can change it. For most uses that is the business owner of the process, supported by the engineering lead who built it. Procurement owns the contract terms, model risk or compliance owns the validation path, and the chief information security officer owns the security review of any alternative. The chief risk officer, or the equivalent in an agency or health system, owns the report and decides which figures are too long.

Embedded AI needs a different owner. The vendor manager responsible for the software product is the person who can get written answers about the model inside it. Without that assignment, embedded uses tend to fall between the AI program and the vendor program, with neither tracking them.

A first ninety days

An organization starting from nothing can get a credible first report within a quarter. In the first month, it lists its AI uses, including embedded features, and sends written questions to the vendors behind the embedded ones. In the second, it reviews contract terms for the most important uses and builds an evaluation suite for the one with the highest stakes. In the third, it estimates days to switch for each use and presents the longest figures, with an owner and a plan for each. The numbers will be rough. The second report, a quarter later, is where they start to mean something.

Every important AI use needs a route, a switch time, a test set and a fallback

• Which of our important processes now use an AI model, and through which route: direct, cloud platform or embedded in another product?
• For each, how many days would it take to move to an approved alternative, and which use has the longest figure?
• Do our contracts give us notice before a model changes, and say what happens to our data when we leave?
• Do we have an evaluation suite, built from our own work, for each important AI use, and who owns it?
• If the AI tool stopped tomorrow, how would each team keep working, and when did we last test that?

Asking these questions requires no technical expertise. They require only that someone be expected to answer them, and that the answers come back to the same committee each quarter.

With hindsight

The crisis ended within days, and OpenAI’s services were not interrupted. For buyers, the immediate scare passed quickly. The structural questions it raised did not.

OpenAI’s corporate structure remained under debate, and in October 2025 it completed a recapitalization that made its for-profit arm a public benefit corporation controlled by the nonprofit foundation. A public benefit corporation is a for-profit company whose charter also commits it to a stated public purpose. For customers, the details matter less than the reminder that the governance of an important supplier can keep changing long after a crisis fades from the headlines.

The relationship with Microsoft loosened as well. In January 2025, Microsoft gave up its position as OpenAI’s exclusive cloud provider in favor of a right of first refusal, as OpenAI announced large data center plans with other partners. The October 2025 restructuring came with a new agreement between the two companies. Competition authorities took an interest along the way. The UK Competition and Markets Authority opened a preliminary review of the partnership in December 2023, and in March 2025 concluded that it did not qualify for merger review. In January 2024 the FTC began a study of investments by cloud providers in AI developers.

The market moved toward multiple models. Major cloud platforms expanded their catalogs from several developers, and in September 2025 Microsoft began offering Anthropic’s models alongside OpenAI’s in parts of Microsoft 365 Copilot and in Copilot Studio. Model gateways, the abstraction layers that let an application switch between models, and evaluation tooling became standard elements of enterprise AI platforms.

Model retirement proved to be the more routine source of forced change. When OpenAI launched GPT-5 in August 2025, it initially removed older models from ChatGPT, then restored GPT-4o for paying users after complaints. API customers met the same pattern on published deprecation schedules. Teams with evaluation suites treated those dates as scheduled work. Teams without them treated each one as a small crisis.

Public buyers moved toward choice by design. In April 2025, OMB’s memo on AI acquisition directed agencies to guard against vendor lock-in in AI contracts. In August 2025 GSA launched USAi, a platform on which agencies could test models from several developers side by side.

In practice the main return on portability was commercial. Organizations with evaluation suites could adopt better or cheaper models as they appeared, because they could prove in days that a new model did the job. The same preparation that protects against a supplier crisis also turned out to be the best tool for getting value from a crowded, fast-moving market.

Supplier disruption did return in a different form in February 2026. A presidential directive told federal agencies to stop using an AI developer’s technology, and GSA removed it from its schedules, forcing some agencies and contractors to plan an exit. GSA said it had removed the developer from both USAi and its Multiple Award Schedule. This time the trigger was government policy rather than boardroom drama, but the question for affected organizations was the same one November 2023 posed: how many days to move?

One assumption held up less well. Many teams in 2023 expected a move to be mostly about prompts. As uses grew to include tool calls, multi-step workflows and connections to internal systems, the integration code around the model became the expensive part of any move. Estimates that counted only prompt changes would have understated the work for that reason, sometimes badly. The figure itself held up as a measure, because it never depended on predicting the cause of the next disruption.

Nobody can predict which kind of shock will come next. An organization can know, in advance, what it would cost to respond.