Transparent editorial process
We combine current product documentation, public pricing, and editorial analysis. Hands-on experience is only claimed when the article identifies the workflow or evidence. Sponsorships and related products are disclosed.
Read our review methodologyRecent changes
Cursor confirmed that it was acquired by SpaceX
Cursor says the combination gives it access to more compute for training its own models
OpenAI notified SpaceX that it intends to wind down model access through Cursor
OpenAI proposed November 12, 2026 as the shutoff date
Developers who select OpenAI models in Cursor now face a migration decision
Cursor itself remains available, but exact replacement and enterprise-transition details are still incomplete
Cursor users now have a real deadline to plan around.
On August 28, OpenAI said it had notified SpaceX that it intends to wind down the contract supplying OpenAI models to Cursor, with a proposed shutoff date of November 12, 2026. The announcement followed Cursor’s confirmation two weeks earlier that SpaceX had completed its acquisition of the AI coding platform.
This does not mean Cursor is shutting down. It does not mean every developer must immediately abandon the editor. It means one of Cursor’s most important selling points—easy access to multiple frontier-model families—is becoming less certain.
If your daily workflow explicitly depends on an OpenAI model inside Cursor, use the notice period to test a fallback now.
What OpenAI actually announced
OpenAI says it is using a change-of-control provision in its Cursor agreement after the SpaceX acquisition. The company proposed November 12 as the end date and said Cursor would not receive its future models.
OpenAI framed the decision around confidence in contractual compliance and the responsibilities associated with increasingly capable models. It cited earlier disputes involving Elon Musk’s companies and said it could not be confident that SpaceX would use OpenAI technology within its terms.
Those are OpenAI’s stated reasons, not a neutral legal finding about the contract. AIViewer has not seen the agreement or the evidence underlying the dispute.
What is operationally clear is narrower: OpenAI intends to stop serving models through Cursor after the notice period. The exact behavior users will see—models disappearing from the selector, existing conversations moving to another model, enterprise exceptions or support for personal API keys—had not been fully explained by Cursor when this article was checked.
Cursor is now part of SpaceX
Cursor announced on August 14 that its acquisition by SpaceX was complete. The company says the deal gives its team access to a much larger pool of computing resources and should help it build stronger, less expensive models.
The direction was visible before the acquisition. Cursor partnered with SpaceX in April to expand model training, then released jointly developed Grok models and continued investing in its own Composer and Router systems.
That creates a plausible path forward: Cursor may rely more heavily on its own routing, Cursor-trained models and models associated with SpaceX and xAI. It may also continue offering models from providers whose partnerships remain intact.
But a plausible path is not a confirmed replacement. Developers should make decisions based on the models available in their actual account, not assumptions about what Cursor will offer by November.
Who needs to act
You should prepare now if any of these statements is true:
- Your team selects a named OpenAI model for code generation or review.
- Internal documentation promises that a particular GPT model powers the workflow.
- Evaluation tests, prompts or automated checks were tuned around that model’s behavior.
- You bought Cursor partly to avoid managing a separate OpenAI or Codex workflow.
- Client, security or procurement approval names OpenAI as the underlying provider.
- You need consistent model behavior during a release scheduled near November 12.
You probably do not need an urgent migration if you already use Cursor’s Auto mode, Claude models, Grok, Gemini or a Cursor-built model and your work does not depend on OpenAI-specific behavior. You should still confirm the route used for important tasks and watch Cursor’s transition notices.
A practical migration test
Do not compare tools using a toy prompt. Use one real, bounded task from your own repository.
Step 1: Capture the current baseline
Choose a task you have already completed with your preferred OpenAI model in Cursor—for example:
- Fixing a failing test with a known root cause.
- Refactoring one module without changing behavior.
- Adding validation to a small API endpoint.
- Reviewing a pull request for a security or accessibility issue.
Record the prompt, repository state, time taken, files changed, test outcome and corrections required. Do not rely only on whether the first answer looked impressive.
Step 2: Repeat it with two alternatives
Run the same task with one alternative inside Cursor and one outside it. Reasonable candidates include:
- Cursor Auto or a Cursor-built model.
- Claude inside Cursor or Claude Code.
- OpenAI Codex as a direct OpenAI workflow.
- GitHub Copilot inside your existing editor.
Use the same success criteria. If the alternative needs a different prompt style, document the change rather than quietly optimizing one tool more than another.
Step 3: Compare workflow costs, not benchmark claims
The useful measures are:
- Did the tests pass?
- Did the agent stay within scope?
- How much review and repair was needed?
- Were tool calls and terminal actions easy to inspect?
- Did the result respect project rules and architecture?
- What did the successful run cost under your plan?
A model that scores higher on a public coding benchmark can still be worse for your repository, language or review process.
Step 4: Keep a reversible fallback
Export or copy important project rules, reusable prompts and workflow documentation into version-controlled files. Avoid keeping the only usable version of your process inside one product’s private settings.
If you switch editors or agents, keep the old workflow available until the new one has completed several real tasks successfully. Migration should be a controlled comparison, not a loyalty test.
Should developers switch from Cursor to Codex?
Not automatically.
Codex is the most direct option if continued access to OpenAI models is the deciding requirement. It also reduces dependence on a third-party editor contract for those models.
Cursor may remain the better product for developers who value its editor experience, model router, codebase context and access to non-OpenAI models. The acquisition could also give Cursor more resources to improve its own models.
The decision comes down to dependency:
- Choose Codex if OpenAI models and OpenAI’s agent workflow are essential.
- Stay with Cursor if the editor and multi-model experience matter more than a specific GPT model.
- Test Claude Code if terminal-native, long-running coding work is your priority.
- Use GitHub Copilot if enterprise governance and GitHub integration outweigh frontier-model choice.
For more context, read the full Cursor review, compare the OpenAI, Anthropic and Google model strategies and use AIViewer’s verification workflow when testing outputs.
What remains unknown
Several important details were still unresolved on August 30:
- Whether every OpenAI model disappears on the same date.
- Whether users can continue through personal API keys.
- How Cursor will migrate saved model preferences and agent rules.
- Whether enterprise customers receive different transition arrangements.
- Which model Cursor will recommend for workflows previously routed to OpenAI.
- Whether the proposed date changes after further discussions.
Until Cursor publishes a detailed transition notice, treat November 12 as a planning deadline, not a complete product specification.
The practical verdict
Cursor is not suddenly useless, and a rushed migration would create more risk than it removes. But the platform’s ownership and model mix have materially changed.
Developers who depend on OpenAI models should spend one afternoon in September testing a real repository task in at least two alternatives. Save the evidence, choose a fallback and repeat the test before November.
If nothing changes, you have lost only a few hours. If the cutoff arrives as proposed, you will already know what works.
Frequently asked questions
When will OpenAI models leave Cursor?
OpenAI proposed November 12, 2026 as the contract shutoff date. It is possible that implementation details or the date could change.
Is Cursor shutting down?
No. Cursor has been acquired by SpaceX and says it plans to continue developing the product and its own models.
Will Claude and Gemini remain in Cursor?
The OpenAI announcement concerns OpenAI’s contract. It does not itself announce the removal of Anthropic or Google models. Confirm current availability in Cursor’s official model selector and account documentation.
Can I use OpenAI through a personal API key in Cursor?
Cursor had not clearly documented how the proposed contract change would affect every personal-key or enterprise configuration when this article was checked. Do not assume that a personal key is guaranteed to bypass the change.
What should teams do first?
Inventory workflows that name an OpenAI model, identify affected repositories and approvals, then benchmark one alternative inside Cursor and one separate coding agent using the same real task.
Sources checked
- OpenAI: Our decision on Cursor following its acquisition by SpaceX, published August 28, 2026.
- Cursor: Cursor is now a part of SpaceX, published August 14, 2026.
- Cursor: Cursor partners with SpaceX on model training, published April 21, 2026.
Sources were checked August 30, 2026. AIViewer will update this page when Cursor publishes detailed transition guidance.