OpenAI is cutting Cursor off from its models on November 12, 2026, as we covered in what the split means for developers. If your team uses GPT models inside Cursor, you have about eleven weeks. For most teams this is an afternoon of work plus a week of validation, not a project.
This guide is the actual runbook: how to find out whether you are affected, how to find the dependencies you forgot about, the one trap that will waste your first day, and how to validate the swap before your team notices.
Start here, because it saves most readers the rest of the article: if GPT is under 10% of your team’s Cursor usage and nothing automated depends on it, you do not have a migration. You have a calendar reminder. Step 1 tells you which situation you are in.
Step 1: Find Out What You Actually Use
Do this before anything else. Most engineering leaders guess wrong about their own model mix.
Check three places:
- Cursor’s dashboard. Open Cursor Settings, then your account or usage view. On Teams and Enterprise plans, the admin dashboard breaks usage down by member and by model. This is the authoritative source.
- Your team’s model selector defaults. Ask each developer which model is actually selected in their editor right now. Defaults drift, and the answer is often “I never changed it,” which tells you more than a survey would.
- Your billing. Cursor splits usage into a first-party pool for its own models and a separate pool for third-party models including Claude, GPT, and Gemini. If your third-party pool spend is negligible, you are already mostly off GPT.
Write down one number: GPT as a percentage of your team’s Cursor usage. Under 10% with no automation, skip to Step 8. Over that, or any automation at all, continue.
Step 2: Sweep for Hidden Automation
This is the step teams skip and the one that actually causes incidents. Interactive use fails loudly, because a developer sees an error and tells you. Automation fails silently at 3am and nobody notices until something ships wrong.
Search your repositories, CI configuration, and internal scripts:
# OpenAI endpoints and keys anywhere in the repo
grep -rIn --exclude-dir={.git,node_modules,dist,build} \
-e 'api\.openai\.com' \
-e 'OPENAI_API_KEY' \
-e 'openai\.' \
-e 'gpt-[0-9]' .
# Cursor CLI and agent invocations in CI
grep -rIn --exclude-dir={.git,node_modules} \
-e 'cursor-agent' -e 'cursor ' \
.github/ .gitlab-ci.yml Jenkinsfile scripts/ 2>/dev/nullThen check the places grep cannot reach:
- Scheduled jobs on build servers or cron that call a coding agent.
- Git hooks and PR bots that generate reviews, changelogs, or test scaffolding.
- Internal tools and dashboards someone built in a hackathon and everyone forgot about.
- Shared rules files committed to the repo that pin a specific model by name.
Every hit goes on a list with an owner and a date. Anything unattended is your real deadline, and it should be done well before November 12, not on it.
Step 3: Understand the BYOK Trap Before You Waste a Day
The obvious plan is: keep using GPT in Cursor with your own OpenAI API key. OpenAI has said personal API keys continue to work. This seems like a one-line fix.
Inside Cursor, it is not. Cursor’s own API key documentation and its support responses are clear that a custom API key does not unlock its full feature set. Developers hitting this see errors along the lines of “Agent and Edit rely on custom models that cannot be billed to an API key,” and enabling a custom OpenAI key has been widely reported to break explicitly selected Composer models, returning “This model does not support custom API keys.”
In practice, BYOK inside Cursor gives you chat against standard models. It does not reliably give you Agent and Edit, which are the multi-file, codebase-aware features that are the actual reason to use Cursor. Worse, turning the key on can degrade Composer, so you end up toggling it and losing the thing you were trying to keep.
So the realistic options are narrower than they look:
| Approach | Keeps GPT? | Keeps agentic editing? | Effort |
|---|---|---|---|
| Switch to Composer, Claude, or Gemini in Cursor | No | Yes | Hours |
| BYOK inside Cursor | Partly, chat only | No, and may break Composer | Hours, then regret |
| OpenAI Codex IDE extension or CLI alongside Cursor | Yes | Yes, in Codex | A day |
| Move to another editor | Depends | Yes | Weeks |
The honest recommendation: do not plan your migration around BYOK inside Cursor. Either change models in Cursor, or get GPT from OpenAI directly through the Codex IDE extension and run it alongside. We compare the full field in our guide to Cursor alternatives.
Step 4: Pick One Replacement and Commit to It
Do not run a five-way bake-off. Pick one based on what you are actually optimizing for:
- Lowest effort and lowest cost: Composer, Cursor’s own model. It sits in the cheaper first-party usage pool, which is a meaningful cost difference on agentic workloads.
- Closest quality match for hard reasoning: Claude models in Cursor.
- You specifically need GPT: the Codex IDE extension or CLI, running alongside Cursor.
- Long refactors and autonomous work: Claude Code or Codex CLI in the terminal, independent of your editor.
Announce the choice. An undecided team defaults to whatever was selected last, which is the situation you are trying to end.
Step 5: Validate on Real Work, Not Benchmarks
Give it a week of actual tickets. Benchmarks will not tell you what you need to know, because the differences that matter show up in your codebase and your conventions.
Watch four things specifically:
- Multi-file refactors. This is where models differ most in practice. Take a change that touches six or more files and see whether it holds the thread.
- Long-context work. Point it at your largest module and see where it starts losing track.
- House conventions. Does it follow your existing patterns, or does it write generically correct code that does not look like your codebase?
- Rework rate. How much of what it produces do you throw away? This is the number that actually determines whether the tool saved time, and it is the one nobody measures.
Have two or three developers do this on real tickets rather than assigning it to one volunteer. One person’s experience with a model is noise.
Step 6: Update Your Rules and Prompts
If your repository has a rules file, an AGENTS.md, or equivalent, read it with fresh eyes. Two problems are common:
- Model-specific instructions. Prompts tuned to one model’s quirks often work against another. Strip instructions that exist only to work around a specific model’s behavior.
- Hard-coded model names. Anything that pins a model by name is a dependency you will have to update again. Reference capability, not product names, wherever you can.
This is also the right moment to move these files into your repository if they are not there already. Prompts, rules, and process are your intellectual property. They should live in version control alongside your code, not in a vendor’s settings panel, precisely so that a change like this one costs you an afternoon.
Step 7: Put a Cap on Spend Before You Flip the Switch
If any part of your plan involves an API key, set the limit first. Coding agents burn tokens faster than almost anything else in a normal engineering budget, and metered AI is one of the most common surprise line items we see.
- Set a hard monthly limit on the API key at the provider before it goes into any tool. OpenAI’s own production best practices cover setting budgets and alerts.
- Use a separate key per tool or per team so you can see where spend is going and revoke one without breaking everything.
- Set a usage alert at roughly half your limit, not at 90%, so you have time to react.
- Review the first two weeks weekly, not monthly. Bad patterns are cheap to fix early and expensive to fix in arrears.
The same FinOps discipline you apply to cloud spend applies here, and for the same reason: consumption pricing punishes teams who set it and forget it. If you have been through a cloud cost cleanup, the pattern will be familiar.
Step 8: Assign an Owner and a Date
The cheapest control in this whole exercise, and the one most teams skip.
- One named person owns the November 12 cutover.
- A calendar entry two weeks before, on October 29, to confirm everything on the Step 2 list is done.
- A line in your change log or runbook recording what changed and why, so the next person to ask “why are we on this model” gets an answer. Treat it as knowledge management, not paperwork.
- A note on what you would do if OpenAI and Cursor settle. Truell has said Cursor is in talks with OpenAI, so this may not happen at all. Design the change so it is worth making regardless: moving prompts into your repo and capping API spend are improvements either way.
A Realistic Timeline
| When | What |
|---|---|
| This week | Step 1 audit and Step 2 automation sweep |
| Week of Sept 7 | Pick the replacement, announce it, set spend caps |
| Weeks of Sept 14 to Sept 28 | Validate on real tickets, update rules files |
| Week of Oct 5 | Migrate automation and unattended jobs |
| Oct 29 | Confirmation checkpoint, everything green |
| Nov 12 | Cutoff. Nothing should happen. |
If that looks slow, it is deliberately slow. The work itself is a few days. The rest is validation time, which is the part that prevents you from discovering in November that your replacement model handles your largest module badly.
The Point of Doing This Properly
You are going to do this again. Model providers are becoming application vendors, application vendors are being acquired by companies with their own labs, and the assumption that any of this is neutral infrastructure is expiring. We watched the same lesson land differently in June, when an export-control directive pulled Claude Fable 5 offline days after launch.
The teams that handle these well are not the ones on the best model. They are the ones whose prompts live in their repo, who have actually run a week on their second-choice provider, and who can name every model their tooling depends on. If this migration leaves you with those three things, it was worth more than the GPT access you lost.
How Exodata Helps
We help engineering and IT teams run migrations like this without the surprises: auditing which models your tooling actually depends on, finding the unattended automation nobody remembers building, setting spend controls before the bill arrives, and designing AI workflows so the model is a parameter rather than a foundation. If you ran the grep in Step 2 and did not like what came back, reach out to our team.
Frequently Asked Questions
When exactly do GPT models stop working in Cursor?
OpenAI has proposed November 12, 2026 as the shutoff date for Cursor’s direct access to its models. OpenAI has also said it is already not providing future models to Cursor, so its upcoming Astra model was never going to arrive there regardless of the November date.
Can I just use my own OpenAI API key in Cursor?
Not as a full replacement. OpenAI has said personal API keys continue to work, but Cursor limits what a custom key can do inside the editor. Developers report that a custom key gives chat against standard models without reliable access to Agent and Edit, and that enabling an OpenAI key can break explicitly selected Composer models. If you specifically need GPT, using OpenAI’s own Codex IDE extension or CLI alongside Cursor is the more dependable route.
What is the biggest risk in this migration?
Unattended automation. Interactive use fails loudly because a developer sees an error immediately, but a CI job, PR bot, or scheduled script that reaches GPT through Cursor will fail quietly and may not be noticed until incorrect output has already shipped. Sweep your repositories, CI configuration, and cron jobs before you do anything else.
Which model should we switch to inside Cursor?
Composer is the lowest-effort and lowest-cost option because it sits in Cursor’s cheaper first-party usage pool. Claude models are the closest quality match for difficult reasoning and refactoring work. The right answer depends on your codebase, which is why you should validate the choice on a week of real tickets rather than on published benchmarks.
How long should this take?
The technical work is a few days. Budget six to eight weeks end to end so that validation happens on real tickets rather than in a rush, and so that unattended automation is migrated well before the deadline rather than on it.
What if OpenAI and Cursor resolve their dispute?
It is possible. Cursor’s CEO has said the company is in talks with OpenAI to resolve the situation. Plan the migration so that it is worth doing either way: moving prompts and rules into your own repository, capping API spend, and testing a second-choice model are all improvements that hold their value even if the cutoff never happens.