In Brief: An AI service exit plan is a pretested procedure for moving data, prompts, tools, security rules, and the business workflow to an alternative setup. Having a second API in the settings does not yet mean you are ready: a transition only counts as real if the backup system passes critical scenarios within an acceptable time and with known limitations.
This material is intended for process owners, CTOs/CIOs, procurement, information security, and AI product teams. It covers dependence on an external AI service and preparing a switch. Legal interpretation of specific contracts, vendor selection, and cost calculations for an individual company are out of scope.
Contents
- What happened between OpenAI and Cursor
- Why this matters beyond Cursor users
- What vendor lock-in means in AI
- Five layers of dependence on an AI vendor
- Stay, prepare, or switch
- The ZAPAS method for exiting an AI service
- How to run a transition rehearsal
- What to lock in through procurement and contract terms
- What portability does not guarantee
- Analysis limitations
- Frequently asked questions
- How AI Dawn helps prepare a backup environment
- Conclusion
What happened between OpenAI and Cursor
On August 28, 2026, OpenAI said it intended to stop contractually supplying its models to Cursor. In a public statement from OpenAI the proposed cutoff date was November 12, 2026. The company linked the decision to a change in control and the terms of the custom agreement; the future Astra model is not planned to be provided to Cursor.
Cursor previously, on August 14, confirmed the acquisition had been completed by SpaceX. Cursor also said it had access to SpaceX compute infrastructure and was developing its own models. As of observation on August 30, no separate public response from Cursor to OpenAI’s statement was found on the official blog.
| Observed fact | Date | What it proves | What it does not prove |
|---|---|---|---|
| Cursor confirmed the SpaceX acquisition | 08/14/2026 | the change in control took place | that all vendors will change their terms |
| OpenAI announced its intention to end the contract | 08/28/2026 | model supply depends on more than just the API | that the Cursor service will shut down |
| Proposed date — 11/12/2026 | 76 calendar days after the announcement | there is a limited preparation window | that this is a contractual deadline for every customer |
| Cursor publicly supports several model families | observation on 08/30/2026 | the product has alternative model surfaces | that results and features are fully equivalent |
76 days is the calculation between the public announcement date and the proposed cutoff date. It is not an assessment of whether the window is sufficient and not an SLA confirmed by both sides.
Why this matters beyond Cursor users
This event shows the difference between access to an interface and control over the supply chain. A customer can buy a packaged AI service, while that service depends on a separate model developer, cloud provider, vector store, evaluator, and external tools. A contract change at one layer changes the capabilities of the entire stack.
NIST AI RMF Core recommends having contingency processes for failures and incidents in third-party AI systems. NIST AI RMF Playbook adds regular testing of bypass procedures, backup systems, change management, and decommissioning components that exceed acceptable risk.
That does not mean every company needs to pay for three models at once. A backup environment costs money and may be lower quality than the primary one. The question is not “how do we eliminate dependence entirely,” but what dependence the company consciously accepts, how it measures the cost of exit, and what triggers a transition.
What vendor lock-in means in AI
AI vendor lock-in is a dependency in which changing providers requires a disproportionately expensive or time-consuming rework of data, logic, integrations, controls, and team skills. In AI, it does not arise only from a closed API. The same prompt on a different model can change the response format, refusal behavior, tool calling, and performance on long context.
The UK guidance Managing technical lock-in in the cloud suggests not automatically banning lock-in, but comparing its benefits with the cost of exit, documenting migration time, and periodically testing critical components with another provider. That logic can be applied to AI, but the specific GOV.UK rules apply to the UK government context.
A useful decision formula:
Acceptable dependence = the value of the vendor’s unique capabilities − the expected harm from being unable to exit on time.
Both parts need to be measured using your own scenarios. You cannot plug in a universal percentage or the cost from someone else’s case.
Five layers of dependence on an AI vendor
| Layer | What is usually tied to it | Portability check |
|---|---|---|
| Model | system prompt, context, structured output, safety behavior | paired runs of frozen test cases |
| Wrapper | tool calling, retries, routing, budgets, memory | replay of actions and errors |
| Data | files, embeddings, labels, conversation state | full export and validation import |
| Control | logs, approvals, moderation, evaluator | preservation of required evidence |
| Contract and people | timelines, rights, support, competencies | exit register, owners, and rehearsal |
API abstraction reduces the cost of replacing an endpoint, but it does not normalize meaning. For example, two providers may accept the same JSON Schema but decide differently when to call a tool, stop, or hand the task to a human. That is why the article about AI agent harnessing recommends accepting a frozen model–harness bundle, not the model name on its own.
The hidden dependency is often in the data. If vendor-managed memory, embeddings, or traces cannot be exported in a readable format, a formally available backup model starts without context. If a business decision requires an approvals log, switching without preserving the evidence trail can be worse than a short outage.
Stay, prepare, or switch
| State | Observable conditions | Reasonable action |
|---|---|---|
| Stay | the contract is stable, exit time fits within tolerance, the backup was tested recently | continue the primary path and reassess risk |
| Prepare | a change in control, terms, price, region, or model roadmap; the backup test is outdated | freeze cases, update the export, conduct a rehearsal |
| Switch | confirmed termination, unacceptable change, or breach of the risk threshold | launch the agreed cutover and tighten oversight |
| Stop the function | no alternative meets the critical requirements | move back to a manual process or limit the scope |
A change in control is a review trigger, not an automatic order to migrate. In the case of OpenAI and Cursor, the change-of-control window, according to OpenAI, made it possible to cancel the custom agreement. But a customer of another service must read its own contract and actual architecture.
Automatic switching also is not right for everyone. For draft summarization, moderate degradation may be acceptable. For payments, medical text, or access-right changes, it is safer to stop automation than to quietly send the task to a model with a different error profile.
The ZAPAS method for exiting an AI service
We propose the ZAPAS. This is an editorial synthesis of vendor management, cloud exit planning, AI evaluation, and change management; it is not a standard from OpenAI, Cursor, NIST, GOV.UK, or the EU.
Z — Dependencies and triggers
Map not vendor logos, but the full path of one critical request: input data, preprocessing, model, tools, memory, policy, evaluator, logs, and business impact. For each dependency, define triggers: service termination, change of owner, price, processing region, data terms, capability, or security posture.
A — Company-controlled artifacts
Keep portable copies of system prompts, JSON schemas, tool definitions, acceptance cases, policies, retrieval configurations, and reference data. Document the export format, frequency, owner, and deletion procedure with the old provider. Secrets and personal data should not be included in the portable package without a legal basis and access controls.
P — Validation set
Assemble a small frozen set of common, rare, critical, adversarial, and impossible cases. For each one, define an acceptable response, required refusal, tool call, human approval, and prohibited effect. Compare not only the text, but also the completion of the business task.
A — Alternative build
Prepare a specific combination: model, adapter, prompts, tools, limits, safeguards, and observability. "We’ll plug in another model later" is not a backup. The alternative is considered ready only after deployment, granting minimum permissions, and pair testing with the primary system.
S — Timing and switching decision
Assign a cutover owner, quality thresholds, maximum downtime, acceptable degradation, and recovery time. The decision should distinguish four outcomes: continue, switch part of the traffic, move fully, or stop automation. Document rollback and user communication.
A minimal exit register fits in one table:
| Field | Example content |
|---|---|
| Critical function | classification of incoming complaints |
| Primary build | provider/model/harness version |
| Alternative | provider/model/harness version |
| Data and export | formats, last check, owner |
| Acceptance set | version, segments, prohibited effects |
| Exit time | result of the last rehearsal, not a promise |
| Trigger | notice, breach, threshold, change of control |
| Decision maker | full name/role of the risk owner |
How to run a transition rehearsal
Do not start a rehearsal during an incident. Choose 20–50 representative cases — this range is an editorial recommendation, not a standard — and complete six steps.
- Freeze the primary and backup manifests. Record the model ID, prompts, tools, policies, and budgets.
- Export the state. Check not for the presence of a button, but for readability, completeness, and data recovery in a test environment.
- Run paired evaluation. One case goes through both builds; a common rubric reviews the results.
- Measure the impact. Capture completion, critical errors, approvals, latency, and actual costs only where the data is available.
- Rehearse the cutover. Switch a limited shadow traffic stream or a reversible process, and verify logs and rollback.
- Sign off on the decision. Specify residual risks, the date of the next review, and the events that would trigger an unscheduled run.
We applied this logic to a public event as a desk test: we reviewed seven primary/official sources, separated the statement date from the deal date, broke the dependency into five layers, and built a trigger matrix. We did not have access to OpenAI–Cursor contracts, clients’ internal architecture, production traces, or measured migration costs; therefore, the conclusions are limited to the risk-management process.
The key metric is not “matching answers,” but the share of critical scenarios completed within tolerance without a prohibited effect. Parity across every word is usually impossible and unnecessary. What matters is preserving function, control, and evidence.
What to lock in procurement and the contract
The UK Digital, Data and Technology Playbook recommends linking the outgoing supplier’s exit plan with the new supplier’s mobilization and including actions, deadlines, roles, risks, dependencies, and transfer of assets. For Russian businesses, this is a useful management template, not applicable law.
For an AI procurement, discuss with lawyers and architects:
- notice on model termination, material changes in terms, and change of control;
- a list of exportable data and digital assets, the format, frequency, and cost of export;
- access to logs, prompts/configs, labels, and evidence owned by the customer;
- support for transition, deletion of copies, confirmation of deletion, and the fate of backups;
- the possibility of a temporary overlap of two suppliers;
- model/version change notices and a regression window;
- restrictions on transferring the supplier’s protected intellectual property.
EU Data Act contains contractual requirements for switching data-processing services, exporting data and digital assets, continuity, and open interfaces. Its applicability depends on the service, territory, and exceptions; this is not a legal assessment of any specific LLM API. The right to export also does not automatically create functional equivalence of the model.
What portability does not guarantee
An exit plan reduces operational risk, but it does not provide five guarantees.
- Equal quality. Models reason differently, refuse differently, and call tools differently.
- Zero downtime. Exporting, access verification, and re-indexing take time.
- The same security. Safeguards and logging differ.
- Legal sufficiency. Technical export does not replace contract and data review.
- Savings. Backup, rehearsal, and dual operation can increase costs.
It is also not necessary to build a “universal layer” for everything. The more abstraction hides model differences, the higher the risk of losing useful capabilities and important safety signals. Often it is better to standardize inputs, evidence, and acceptance tests, while keeping provider-specific adapters explicit.
A related topic is an AI model router. A router can distribute tasks, but it does not replace an exit plan: it too becomes a component that must be versioned, tested, and bypassed when needed.
Analysis limitations
OpenAI’s public statement reflects the position of one side. The full custom agreement, negotiations, and client plans have not been published. The date of November 12 is described as the proposed shutoff date; this article does not claim the shutdown will definitely happen exactly then.
Cursor publicly supports several models, but that does not prove equivalence of features, pricing, latency, privacy, safety, or results after a possible cessation of OpenAI supply. We did not measure user traffic, failures, switching costs, or business impact.
The NIST AI RMF is voluntary. GOV.UK and the EU Data Act have their own government and territorial context. For a Russian contract, separate legal, information security, and tax assessments are needed. Search volume, difficulty, rankings, traffic, CTR, backlinks, and AI citations for the topic remain Unknown.
Frequently asked questions
What is an AI service exit plan?
It is a documented and tested procedure for transferring data, configurations, control, and the business function to an alternative build or a manual process. It includes triggers, timelines, owners, acceptance tests, cutover, and rollback.
Is it enough to connect a second LLM API?
No. You need to check prompts, structured output, tools, memory, safeguards, logs, and the business effect. A second endpoint without testing can create silent degradation instead of resilience.
Do you need to keep two models in production all the time?
Not always. For a noncritical function, regular rehearsals and a ready manifest may be enough. For a continuously critical function, warm standby or traffic splitting may be needed.
Does a change in ownership of an AI service always require migration?
No. It is a reason to review the contract, data, roadmap, security posture, and exit timeline. Switching is triggered only by an agreed trigger or by exceeding tolerance.
What should be tested when switching between models?
Test completion by segment, critical errors, mandatory refusals, tool calls, approvals, latency, costs, and preservation of the evidence trail. An average quality score without critical segments is not enough.
How often should the backup setup be tested?
There is no single frequency. Run a test after any material change to the model, harness, data, or contract, and also at an interval shorter than the acceptable staleness of the backup for your process.
How AI Dawn helps prepare a backup setup
AI Dawn can connect the exit plan to a real AI build:
- audit one process and map the models, data, tools, and rights;
- prepare portable prompts, retrieval artifacts, tool schemas, and acceptance criteria;
- assemble an alternative LLM/RAG or on-prem build with limited permissions;
- run a paired test, cutover rehearsal, and record the results for the risk owner.
A safe first step is to choose one process, document its current baseline, data sources, constraints, and acceptance criteria.
Conclusion
The OpenAI and Cursor story shows that access to an AI model depends not only on API quality, but also on contracts, owners, and the supply chain. However, the sensible response is not a panicked migration or mandatory multi-model support for every function.
First, document dependencies and triggers, bring artifacts under control, assemble a validation set, deploy a specific alternative build, and measure the transition time. Then the exit plan becomes an operational capability, not a contract section that is read for the first time on the day of shutdown.