OpenAI is ending its direct model relationship with Cursor after Elon Musk’s SpaceX acquired the AI coding company. OpenAI says it has proposed November 12, 2026 as the shutdown date for its current contract, while warning that Cursor may end access sooner.
The obvious story is a developer tool losing one model supplier. The more important story is the asset SpaceX just bought: a high-frequency feedback loop between professional programmers, an AI agent, real codebases, tests and a giant pool of compute.
Our view is blunt: the $60 billion deal was not simply a bet on a popular code editor. It was a bet on owning the place where coding models are trained by reality. OpenAI’s decision to stop supplying future models is therefore a rational defensive move, not a sudden rejection of Cursor’s product.
Cursor editor interface. Image by Newmcpe, Wikimedia Commons, CC BY 4.0. Image source.
The timeline: from compute partnership to acquisition
The relationship began as a partnership, not an overnight takeover.
- April 21, 2026: Cursor announced a partnership with SpaceXAI to accelerate model training. Cursor said its training programme was compute-constrained and that Colossus would let it scale much further.
- June 2026: SpaceX disclosed an option to acquire Cursor for an implied $60 billion in SpaceX shares, or to pay $10 billion for the companies’ joint work instead. The regulatory filing described the deal as part of a strategy combining compute, models and AI-native developer software.
- August 14, 2026: Cursor announced that the acquisition had closed and that it was now part of SpaceX.
- August 28, 2026: OpenAI said it had notified SpaceX that it intends to wind down the direct Cursor contract. The proposed transition date is November 12.
Cursor’s own acquisition announcement says the company will have access to a very large GPU fleet and use it to build models that are both more capable and cheaper to run. That is a powerful combination: an application with distribution, a model team with a specialised training recipe and infrastructure willing to spend at scale.
SpaceX’s EU prospectus makes the financial logic clearer. It describes Cursor as a way to strengthen SpaceX’s position in AI-assisted developer productivity, while also giving SpaceX access to Cursor’s people, intellectual property, customer contracts and distribution.
Illustrative SpaceX Falcon 9 launch image. Released to the public domain by SpaceX via Wikimedia Commons. Image details.
How Cursor was already training models before SpaceX owned it
Cursor did not start with a giant general-purpose model. It built a software-engineering specialist and tuned the training loop around the actual Cursor agent harness.
Composer 1 and 1.5: faster agents and larger RL runs
Cursor’s first agentic model was Composer. In its April partnership announcement, the company said Composer 1.5 scaled reinforcement learning by more than 20 times. The point was not merely to make a model write more code; it was to make the model choose tools, search a repository, edit files and recover from errors quickly enough for interactive use.
Cursor’s real-time RL report shows why the product itself became part of the training system. Cursor served model checkpoints to production, watched how people responded and converted those responses into reward signals. In one reported A/B test for Composer 1.5, agent edits that remained in the codebase rose 2.28%, dissatisfied follow-up messages fell 3.13% and latency improved 10.3%.
Composer 2: continued pretraining plus realistic agent RL
The Composer 2 technical report says Cursor used a two-stage recipe:
- Continued pretraining on a code-heavy data mix, starting from Moonshot’s open Kimi K2.5 checkpoint.
- Large-scale reinforcement learning in realistic Cursor sessions, with the same tools and agent harness used by the deployed system.
Cursor says its internal CursorBench is built from real engineering tasks, including terse prompts, ambiguous requirements and changes spanning hundreds of lines across large codebases. That matters because many public coding benchmarks are clean, small and over-specified. A model can score well on them and still be a frustrating colleague.
Cursor reports a 61.3 CursorBench score for Composer 2, a 37% improvement over Composer 1.5, plus scores of 73.7 on SWE-bench Multilingual and 61.7 on Terminal-Bench. Those numbers are company-reported, not an independent guarantee, but they show the optimisation target: useful work in a real development loop, not a flashy demo.
Composer 2.5: ten times more compute and harder training problems
In May, Cursor said Composer 2.5 was built on the same Kimi K2.5 checkpoint as Composer 2, while the team worked with SpaceXAI on a significantly larger model from scratch using 10 times more total compute. Cursor linked that effort to Colossus 2 and described a fleet equivalent to roughly one million H100s.
The training changes are revealing. Cursor added targeted textual feedback to correct a specific bad tool call or communication mistake instead of applying one vague reward to a rollout that may run hundreds of thousands of tokens. It also generated 25 times more synthetic tasks than Composer 2, grounding those tasks in real codebases and verifiable tests.
This is what “training new models” means in Cursor’s case: not just adding parameters, but building a loop that can generate hard tasks, execute an agent, judge the result, identify the exact failure and update the model without breaking latency or usability.
For a practical look at the product economics behind that training loop, read Eyestech’s analysis of Cursor’s pricing and usage model. Our evergreen guide to context engineering for AI coding agents explains why repository structure and long-running context are now as important as raw model size.
The data is more valuable than a pile of prompts
People often describe Cursor’s data advantage as “lots of code.” That undersells it. The valuable asset is a trajectory, not a text dump.
A single coding-agent session can contain:
- the developer’s request and the repository state;
- the files and symbols the agent chose to inspect;
- the search queries and tool calls it attempted;
- the patch it proposed and whether the user accepted or rewrote it;
- compiler, test and linter results;
- the follow-up prompt when the first answer was wrong;
- latency, token cost and whether the task was completed.
That sequence supplies context and a reward signal at the same time. A static code corpus can teach syntax. A successful or rejected trajectory can teach judgement: when to search, when to ask a question, when to run tests, when not to touch a file and how much effort a task deserves.
Cursor says its real-time RL pipeline begins with client-side instrumentation, collects billions of tokens from user interactions, distils those interactions into rewards, runs regression evaluations and can deploy a new checkpoint in about five hours. Keeping the model and the data almost on-policy reduces the gap between the behaviour being trained and the behaviour users are actually seeing.
That is a rare data loop. The model generates work; the developer and the build system judge it; the next model learns from the judgement. Owning the editor means owning the measurement system.
Why SpaceX wanted that loop
SpaceX already had compute ambitions through SpaceXAI and Colossus. What it lacked was a daily product used by expert software engineers. Cursor supplies that distribution and the operational layer around it.
The acquisition creates a vertical stack:
Compute → model training → coding agent → developer feedback → better model → more usage.
That flywheel can be more strategically useful than another consumer chatbot. Developers produce dense, verifiable signals: tests pass or fail, edits persist or disappear, and a follow-up message often says exactly what went wrong. The feedback is not perfectly clean, but it is closer to an outcome than a thumbs-up button.
The data is also specialised. It reveals long-horizon work across real repositories, not isolated “write a function” questions. It shows how experienced programmers decompose tasks, how teams enforce style, where agents waste context and which errors cause a human to take control. A model trained on those signals can become better at the unglamorous parts of software engineering that frontier chat benchmarks rarely measure.
This is why our reading of the acquisition differs from the usual “SpaceX bought a code editor” framing. SpaceX bought a distribution channel and a continuously labelled laboratory for AI software engineering. The editor is the sensor; the model is the product; Colossus is the engine.
What is confirmed—and what is still inference
The public record confirms that Cursor and SpaceXAI partnered on model training, that Cursor described real-time RL from production interactions, and that Cursor said a larger from-scratch model was being trained with SpaceXAI using 10 times more compute. It does not disclose a complete post-acquisition model card, a list of private datasets or proof that SpaceX has trained on every user session.
So the strongest claim we can responsibly make is about capability and incentives: SpaceX now controls the infrastructure, the model team and the product that generates the feedback. It is reasonable to infer that this combination is intended to accelerate SpaceXAI’s coding models, but the exact data mixture and model release schedule remain undisclosed.
The privacy boundary is the part developers should watch
None of this proves that SpaceX is training on every private repository. Cursor’s data-use documentation says Privacy Mode prevents customer data from being used for training by Cursor and its providers. With Privacy Mode off, Cursor says it may use codebase data, prompts, editor actions, code snippets and other code data to improve its AI features and train models.
That distinction matters after a change of control. Enterprise teams should verify which settings are enforced, which providers receive prompts and code context, what retention terms apply, and whether cloud-agent data follows a different path. Cursor’s privacy documentation says Privacy Mode is on by default for Enterprise and can be enforced by administrators, but individual and team plans have different controls.
The strategic value of the data is precisely why the governance question is serious. The best training signal may include the most sensitive context: proprietary architecture, security fixes, unreleased products and internal coding conventions. A model can learn from behavioural traces without memorising source code, but that is not a reason to skip consent, access controls or deletion guarantees.
Why OpenAI is drawing the line now
OpenAI says it cannot be confident that SpaceX will use its technology within OpenAI’s terms of service, citing its experience with Musk’s companies. It also says the change-of-control clause gives it a limited period to cancel the contract and that its upcoming Astra model requires a higher level of accountability.
Our opinion: OpenAI would be negligent not to use that window. Continuing to provide future models to a company that now owns a competing model-training loop would hand over capability, distribution and potentially valuable product feedback on terms negotiated before the acquisition. The cutoff is commercially painful for developers, but strategically coherent.
This does not mean OpenAI has accused Cursor of stealing data, or that every request routed through Cursor becomes improper. It means the risk profile changed when the counterparty changed. Contractual trust is part of model safety, especially when the partner controls a product embedded in thousands of private codebases.
What changes for Cursor users?
OpenAI’s Help Center guidance lists three practical routes:
- Bring your own OpenAI API key: Continue using OpenAI models in Cursor’s local Chat and Agent features, billed at OpenAI API rates.
- Use the Codex IDE extension: Run Codex inside Cursor with a ChatGPT subscription or OpenAI API key.
- Use a gateway provider: Connect through services such as Amazon Bedrock or Azure when central billing, logging or policy controls matter.
Cursor’s model documentation continues to list multiple providers, including Anthropic, Google, DeepSeek, OpenAI and SpaceXAI. Cursor is not disappearing on November 12. The provider mix and the economics of each model are what will change.
The same economics are visible in the wider model market: Eyestech’s analysis of why China is betting on flash AI models examines how cheaper inference changes who can afford to run agents at scale.
Our verdict: the model war is moving into the IDE
OpenAI’s move is bigger than a supplier dispute. It is a warning that model companies no longer view developer tools as neutral distribution. The IDE is where models become habits, where failures are labelled and where the next generation is quietly improved.
SpaceX now has the ingredients to build a serious coding-model competitor: compute, Cursor’s training team, a specialised agent harness and access to a real production feedback loop—subject to privacy settings, contracts and the limits of what user data can legally be used for. OpenAI, Anthropic and Google will have to decide whether they want to remain interchangeable back-end suppliers or own more of the applications that generate their learning signals.
For developers, the practical lesson is simple: do not let one model provider become a single point of failure. Test a second model, keep prompts and repository rules portable, turn on the right privacy controls and understand whether your API-key setup still routes requests through a vendor’s backend.
The $60 billion question is not whether Cursor can survive without OpenAI. It is whether owning the coding loop lets SpaceX improve its own models faster than OpenAI can replace the distribution and feedback it just gave up.
