OpenAI Gave Cursor a November 12 Shutoff Date for Its Models — What a Model Swap Costs, and What Leaving Costs (2026)

OpenAI's notice

OpenAI's post is four paragraphs. The operative sentence is the one quoted above. The reasoning is stated plainly: "We are making this choice because we cannot be confident that SpaceX will use our technology within our terms of service, based on our experience with Elon Musk's companies violating contracts." The mechanism is contractual: "Our custom agreement with Cursor gives us a limited time window to cancel it after a change of control."

Two details in that post matter more to a developer than the reasoning does.

The first is that the notice is deliberately long. "To maximize the time that developers can retain access to our models through Cursor, we are giving the maximum notice provided by our contract." You have until mid-November by design, not by accident.

The second is easy to miss and takes effect immediately: OpenAI writes that it decided "to hold the contract cancellation to the latest date we can while not providing future models to Cursor." The shutoff is in November. The freeze on anything new is now.

OpenAI also names who this lands on: "We know that the people most affected by this decision are the developers who rely on OpenAI models in Cursor."

Cursor's side of the record

Cursor published its own note on August 14: "Cursor has officially been acquired by SpaceX." Its documentation currently carries dedicated model pages for GPT-5.6 Sol, Terra, and Luna alongside Claude Sonnet 5, Opus 5, and Fable 5, Gemini 3.1 Pro and 3.7 Flash, Grok 4.6 and 4.5, and Cursor Composer 2.5. As of this week, in other words, nothing has been removed yet.

What neither post says

Cursor documents a bring-your-own-key path — "You can add your own API keys so Cursor uses your preferred AI models" — with two limits stated on the same page. For OpenAI it covers "Standard, non-reasoning chat models," and "Custom API keys only work with chat models. Tab completion continues using Cursor's built-in models." Neither company's post addresses what happens to that path after the contract ends, and we are not going to guess. If you are counting on it, the honest answer today is that it is documented, it is narrower than the built-in models, and its future is unstated.

Here is the sentence that decides most of this, and it is Cursor's, from its own rules documentation:

> "Large language models don't retain memory between completions. Rules provide persistent, reusable context at the prompt level."

It continues: "When applied, rule contents are included at the start of the model context."

Read that as an architecture statement, because that is what it is. Nothing you taught Cursor lives in the model. It lives in files and settings that Cursor assembles into a prompt. Swap which model receives that prompt and the assembly is unchanged.

So the things that survive a model change, entirely and without work:

• Project Rules in .cursor/rules as .mdc files, with their alwaysApply, globs, and description frontmatter and the four activation behaviours built on those three fields.
• AGENTS.md, including nested files in subdirectories, which Cursor combines with parent directories so that "more specific instructions taking precedence."
• Team Rules, created in the Cursor dashboard, with the documented precedence "Team Rules → Project Rules → User Rules" and the note that "All applicable rules are merged; earlier sources take precedence when guidance conflicts."
• User Rules, remote rules imported from GitHub into .cursor/rules/imported/<repoName>, and skills in the four documented skill directories.

And the things that are tied to Cursor rather than to the model, which is a different list:

• Team Rules as an enforcement mechanism. A rule marked "Enforce this rule" is "required for all team members and cannot be disabled in Customize." That property is a Cursor dashboard feature. There is no file to carry it.
• .mdc frontmatter as a scoping language. The four types map onto other tools' concepts unevenly, and the conversion is real work.
• Chat history and saved plans, which are local artifacts of one application.
• Anything a person on your team learned and never wrote down, which is the largest item on the list and the one nobody inventories.

"I have to leave Cursor." Not from this. Cursor's documented model list still includes Anthropic, Google, xAI, and its own Composer models. If your reason for using Cursor was the editor, the agent, or the team rules layer, none of that is affected by which provider answers the prompt. The people OpenAI's post identifies are specifically "the developers who rely on OpenAI models" — a real group, and a subset.

"My rules will behave the same on a different model." They will be delivered the same. That is not the same claim. Rules are prose, and prose lands differently on different models; a rule that a previous model followed loosely and a new one follows literally will change your output. Nothing about that is a defect in your setup — but it means the week after a model change is a week to read diffs more carefully, not less.

"Bring-your-own-key makes this a non-event." Read Cursor's own limits above before you rely on that. Also on that page: "Cursor's Zero Data Retention policy does not apply when you use your own API keys," and "all requests are routed through Cursor's servers for final prompt building." Those are trade-offs, not blockers, but they are trade-offs your security team may already have an opinion about.

"Codex will import everything." Codex's importer is genuinely good and it does list Cursor as a source. It is also specific about what it moves: instruction files, settings.json, skills, plugins, project folders, chats from the last 30 days, MCP configuration, hooks, slash commands, subagents. Note what is described in the memory row of that table — "Project memories from Claude Code." One source, named. Nothing in the importer claims to carry what your team decided and why.

The lesson available here is not "pick a different vendor." It is that a two-and-a-half month notice period arrived from a direction nobody was watching, and the parts of your setup that were portable were portable because they were files, while the parts that hurt were the parts that lived inside one product.

Rules already follow that principle — they are files in your repository, and that is why a model swap costs nothing. The knowledge layer usually does not. The decisions, the corrections, the reasons behind the standards: those sit in chat histories, in people's heads, and in whichever tool happened to be open at the time.

MemoryLake is a memory layer that sits outside any single tool, so that half is readable from whatever you are using this quarter and whatever you are using next. Setup is three steps.

Step 1: Create an API key

Sign in and create an API key. One credential across every tool you connect.

Step 2: Upload your first memories

Short entries, one claim each. Your source material is the reasoning that is currently implicit in your rules:

Decisions with their reasons. Your .mdc file says migrations are additive-only. Why is nowhere. Write the why here, and the rule stops getting reverted every time someone new reads it.

Corrections that stuck. The approach the team tried and rejected, and what went wrong. This is the category no rules format has a field for.

Working context that isn't code. Who owns which service, what is frozen this quarter, which deadline moved.

Pointers outward. The dashboard, the runbook, the issue tracker — the things an agent cannot find by reading your repository.

Step 3: Connect your AI & agents

Connect what you use. MemoryLake is reachable over MCP and over an API, and Cursor supports MCP servers, so the same memory is available in Cursor today. Codex, Claude Code, Cline, and OpenClaw connect the same way, and anything else reads the same memory through the API. That is the point: the connection changes, the memory does not.

Three honest limits. This does not move your .mdc files or your Team Rules — those are Cursor's, and a memory layer does not convert them. It does not extend a contract or restore a model — nothing in this article changes what is available in Cursor in November. And memory is context, not enforcement; anything that must hold every time belongs in a check that fails the build, a point Cursor's own documentation makes about its enforced rules: "AI guidance should not be your only security control."

A model change stops being an event. Rules are assembled at prompt time from files you own. Whoever answers, the assembly is the same.

The costly half becomes visible. You find out what was only in a chat history while you still have the chat history.

Team standards keep their reasons. The rule moves as a file; the reason moves as a memory; both survive the next tool.

Deadlines like November 12 become calendar items, not migrations. Switching a model in settings is a few clicks. Switching editors is a project. Knowing which one you actually need is the whole decision.

Separate "which model" from "which tool" before you decide anything. They are different costs and this news only forces one of them.

Test the alternative on real work, not a toy repo. A rule that survived one model's loose reading may need tightening for another's literal one.

Audit your enforced Team Rules now. They are the item with no file representation, and their absence is silent in any other tool.

Read the importer's table before trusting the importer. Codex names what it moves. Anything not named is your job.

Keep reasoning out of rules files. Rules are inserted at the start of the model context and compete for room — the general shape is in what coding agents actually read.

Do not let a deadline pick your architecture. Two and a half months is enough time to move deliberately. It is also enough time to make three tool changes you did not need.

Write down what the team learned this week. Model transitions surface conventions nobody had documented. That is a one-time opportunity and it closes.

OpenAI's post gives a date and the reason for it: a proposed shutoff of November 12, 2026, the maximum notice its contract allows, and no future models to Cursor in the meantime. Cursor's own record confirms the acquisition that triggered the clause and still documents a model list with Anthropic, Google, xAI, and Composer options in it.

For most Cursor users this is a settings change. Cursor's documentation is explicit that models do not retain memory between completions and that rules are what make context persist, which means your .cursor/rules, your nested AGENTS.md files, and your Team Rules are indifferent to who answers the prompt. If you specifically need OpenAI models, you have a real decision, and the honest inventory is short: the .mdc scoping language and enforced Team Rules do not travel, chat history and saved plans do not travel, and the importer on the other side names exactly what it will bring.

What travels for free is whatever you kept as files, and what goes missing is whatever you kept as conversation. That is the actual lesson in a shutoff date arriving from a contract nobody outside the two companies had read — and it is why why long context isn't memory keeps being the same argument in a different costume.