OpenAI Plans to Leave Cursor on November 12. Rehearse the Provider Exit Now

OpenAI has proposed November 12, 2026, as the day it stops providing models through Cursor. For a team reading this on August 30, that creates a 74-day migration window. The useful unit is not “days until the model picker changes.” It is the number of representative coding tasks the team can replay before its current route disappears.

OpenAI says the date gives the maximum notice available under its contract. It also says Cursor will not receive future OpenAI models. The announcement describes an intended wind-down rather than a completed cutoff, and the outcome may still move: Reuters reported on August 29 that Cursor co-founder Michael Truell was speaking with OpenAI to resolve the situation and that Anthropic planned to make more Claude compute available to Cursor.

That uncertainty is a reason to rehearse, not a reason to wait. Cursor already offers models from several providers. A provider exit still reaches the rules, tools, context, acceptance tests, cost controls, and data requirements wrapped around the selected model. The plan below turns the announced runway into a fixed-workload comparison and a staged cutover with a tested return path.

November 12 starts the rehearsal clock

The sequence is short enough to manage and long enough to waste.

Date	Confirmed event or planning point	Operational consequence
August 14, 2026	Cursor announced that its acquisition by SpaceX was complete.	Record the ownership change separately from any later model-access decision.
August 28, 2026	OpenAI announced its intent to wind down the Cursor contract, proposed November 12, and said it would withhold future models from the product.	Treat November 12 as the current external deadline while preserving the announcement’s proposed status.
August 29, 2026	Reuters reported continuing talks between Cursor and OpenAI, plus Anthropic’s plan to allocate more Claude compute to Cursor.	Keep the source situation under review, but do not make successful negotiations the continuity plan.
November 12, 2026	Proposed end of OpenAI model access through Cursor.	Finish the production canary and rollback rehearsal before the date; do not schedule first discovery for then.

OpenAI frames its decision around contract terms and the change in Cursor’s ownership. That explanation matters for the commercial record, but it cannot tell an engineering team which replacement will preserve its workflow. The team needs its own evidence before the contract window closes.

The provider switch reaches seven coupled surfaces

Cursor currently documents models from OpenAI, Anthropic, Google, SpaceXAI, and Cursor. That catalog supplies candidates. It does not transfer the behavior of the surrounding system to them automatically.

Freeze these seven surfaces before comparing a baseline with a candidate:

Surface	What to freeze or record	Failure gate
Model route	Exact model, selection mode, date, plan, client version, and any automatic routing	The provider or actual route is unknown, unavailable to the target accounts, or changes during the trial
Instructions	Repository, team, user, and agent rules; prompt and policy versions	A required instruction disappears, conflicts, or is followed inconsistently
Context	Repository commit, indexed files, retrieved material, exclusions, and context limits	The candidate misses required evidence or exposes excluded material
Tools and permissions	MCP servers, commands, approval boundaries, credentials, and allowed network or filesystem scope	A tool call fails, escapes its allowed scope, or asks for broader authority
Output acceptance	Target tests, full suite, lint, type checks, security checks, protected paths, and review criteria	The patch fails a blocking check or changes files outside the task
Performance and capacity	Wall time, retries, rate limits, provider usage, and cost per accepted task	Latency, capacity, retry volume, or accepted-task cost crosses the team’s limit
Data and operations	Retention, residency, telemetry, incident ownership, support route, export, and rollback configuration	A policy requirement has no evidence, or the team cannot restore the previous supported route

Instructions and tools deserve separate rows. Cursor Rules are included at the start of model context, so a provider comparison that changes the rule bundle has changed two variables. MCP configurations add external tools and data connections; a model that writes plausible code but mishandles an approval or tool schema has failed the agent workflow.

The route also needs an audit trail. Cursor’s documented Router can select a model for a request. That may be convenient in normal work, but it weakens a migration result if the test record cannot show which model handled each attempt. Pin the baseline and candidate during controlled evaluation, or capture the resolved route.

Freeze the workload before choosing a replacement

Choose tasks from the work that would hurt if it stopped: a small bug fix, a cross-file refactor, a test-writing task, a tool-assisted investigation, and one request that should be refused or escalated. Use sanitized, synthetic, or explicitly approved fixtures. Preserve failures in the sample; a set made only from clean historical successes will flatter every candidate.

Hold the repository commit, environment, instructions, tools, permissions, timeout, retry budget, and acceptance checks constant. A “golden patch” can guide review, but byte-for-byte similarity is a poor gate when several correct implementations exist. The candidate passes when its result behaves correctly, stays in scope, and requires an acceptable amount of repair.

This worksheet makes each attempt reproducible:

task_id:
fixture_commit:
task_class:
prompt_version:
rules_version:
tools_and_permissions:
baseline_model:
candidate_model:
timeout_and_retry_budget:
acceptance_checks:
  - target_tests
  - full_suite
  - lint_type_security
  - scope_limit
observations:
  accepted:
  wall_time_seconds:
  provider_cost:
  tool_failures:
  review_minutes:
  policy_or_data_exception:
rollback_trigger:

Run each important task more than once when the budget permits, and report the numerator with the denominator: “18 of 20 accepted” is more informative than “90%.” Keep timeouts and rejected patches in the total. The sample will still describe the frozen workload rather than every repository or every future model, so record its limits beside the result.

Score the workload, not the model brand

OpenAI’s eval guidance recommends representative test inputs and explicit testing criteria, including when trying or upgrading models. Apply that discipline to the whole coding-agent route.

Measure	Example gate	Why it belongs in the decision
Accepted tasks	Blocking task classes meet a predeclared count; show attempts, timeouts, and failures	A brand-level benchmark cannot establish that the team’s patches build and stay in scope
Tail completion time	Median and 95th-percentile wall time stay within the workflow’s service objective	A replacement that usually feels fast can still stall critical work
Tool reliability	No unauthorized call; schema, permission, and approval failures remain below the agreed limit	Agent work depends on actions, not just generated text
Cost per accepted task	Provider usage plus retries and review time stays within the budget	A lower per-token rate can cost more if success takes extra attempts
Review and repair	Median reviewer minutes and manual correction remain within the team’s threshold	Human recovery work is part of migration cost
Policy and data controls	Security, legal, privacy, retention, residency, and telemetry owners approve documented evidence	Output quality cannot waive a control requirement
Capacity and operations	Target accounts can access the candidate; rate limits, support ownership, monitoring, and incidents work	A good private trial can fail at organizational scale
Rollback	A timed drill restores a supported route and its configuration without losing the work record	The team needs a recovery action, not a fallback name

Predeclare which gates block migration and which permit a documented exception. Otherwise the team can reinterpret a weak result after seeing it. For a small sample, publish counts and uncertainty instead of a precise-looking ranking.

Run the exit at 30, 14, and 7 days

The dates below count back from OpenAI’s proposed November 12 cutoff. If the provider relationship is restored, the work still yields a tested dependency inventory and a second route.

Deadline	Work	Exit evidence
D-30: October 13	Name an owner; inventory the seven surfaces; freeze fixtures and gates; run the current OpenAI route and at least one candidate on the same tasks	Baseline and candidate records are complete, blocking gaps have owners, and the candidate is eligible for the target accounts and required data class
D-14: October 29	Repeat weak task classes; run shadow or dry workloads; update rules, MCP/tool configuration, support docs, budgets, and policy review	No unexplained critical regression or unresolved control gap remains; cutover and rollback configurations are versioned
D-7: November 5	Send a limited share of approved production work to the candidate; monitor acceptance, latency, tool failures, cost, and exceptions; rehearse rollback under a timer	The canary stays inside predeclared limits and the team has successfully restored the supported fallback
Cutover: November 12	Confirm the current OpenAI/Cursor status, route the approved workload, watch the same gates, and retain the evaluation record	The intended route is observable, on-call ownership is active, and any threshold breach triggers the rehearsed response

This is a canary, not a broad side-by-side experiment. The Google SRE Workbook explains that dependency changes can trigger failures and that partial exposure plus evaluation limits the effect of a bad release. Use a representative slice, but exclude workloads the candidate is not yet approved to handle. A tiny synthetic canary is safer, while also being weaker evidence for production behavior; document that trade-off.

Rollback needs its own passing grade

Preserve the current supported configuration while the baseline is still available. Export or version the relevant rules and tool settings, keep the fixture commit immutable, and make the route explicit. If OpenAI access ends as proposed, that route will no longer be a viable rollback inside Cursor. The recovery target must then be a second supported model, an approved workflow outside the affected route, or a visible pause for the task class.

Test that target before the cutover. Start the rollback timer from the alert, restore the configuration, replay one representative task, and confirm that monitoring identifies the active route. Record who can authorize the change and what happens to work in flight. A model name in a runbook has no recovery value if the account cannot select it or the team cannot reconstruct its permissions.

The next external evidence to watch is concrete: whether OpenAI and Cursor announce a resolution, whether Cursor’s catalog changes, and whether either company publishes migration support before November 12. None of those outcomes should erase the rehearsal record. A provider relationship can change faster than a repository’s rules, tool integrations, and acceptance gates; the durable asset is the team’s ability to move those dependencies deliberately.

The Copilot model-retirement playbook shows how to inventory account- and client-specific catalog changes. The coding-agent lifecycle test matrix extends the same evidence discipline to tool permissions, side effects, and recovery.

Sources

1. OpenAI: Our decision on Cursor following its acquisition by SpaceX
2. Reuters: OpenAI to end partnership with SpaceX-owned Cursor
3. Cursor: Joining SpaceX
4. Cursor Docs: Models and pricing
5. Cursor Docs: Rules
6. Cursor Docs: Model Context Protocol
7. OpenAI API Docs: Working with evals
8. Google SRE Workbook: Canarying releases