November 12 deadline: OpenAI models leave Cursor, what iOS developers should do

OpenAI plans to stop supplying its models to Cursor, and the date it has proposed is November 12, 2026. If you build iOS apps in Cursor with GPT models selected, your setup may change next week, and the fix depends on which Cursor features you actually use.

This post covers what is confirmed, which parts of Cursor are affected, and the options that keep working. It also has a short migration plan for iOS projects, including the places where a model name can hide in your scripts.

What is confirmed so far

OpenAI's help page says the company is "planning to wind down our contract providing OpenAI models to Cursor." The same page says "We have proposed a transition period of November 12, 2026." Two details matter here. The date is a proposal, and OpenAI says it will share the official termination date once both companies confirm it. OpenAI also warns that "Cursor may choose to end access sooner."

The reason is Cursor's acquisition by SpaceX. Cursor announced in August that it had become part of SpaceX, and Tom's Guide reported that the deal triggered a change-of-control provision in OpenAI's agreement. Cursor co-founder Michael Truell said OpenAI accounts for about 5% of Cursor's model traffic, according to the same report. So most Cursor users were never on these models, but if you are in that 5%, your habits are about to change.

Tom's Guide also reported that existing OpenAI models should keep working as they do today until the cutoff, and that future OpenAI models won't be available under the current agreement. As of November 5, I could not find a final date confirmed by both companies, so check OpenAI's help page before you act on the 12th.

Which Cursor features are affected

The obvious fix is to paste in your own OpenAI API key. That covers less than people expect. OpenAI's page says a personal key works for "local Chat and Agent features." It does not cover these:

  • Cursor Tab
  • Auto
  • Cloud and Background Agents
  • Automations
  • The Cursor CLI
  • Cursor's API and SDK

So if your day is mostly Chat and local Agent, a key keeps you close to your current setup. If you rely on Cloud Agents or scripts built on the Cursor CLI, a key won't carry GPT models into those features.

Billing is the other surprise. Requests made with your own key go through your OpenAI API account and are billed separately from any Cursor or ChatGPT subscription. A paid ChatGPT plan does not include API usage, so a ChatGPT subscription alone won't help here.

Your options, in plain terms

OpenAI lists three paths: bring your own key, install the Codex extension, or use an AI gateway provider such as Amazon Bedrock or Azure. Staying in Cursor with a different model is a fourth, and iOS developers have a fifth because Xcode now has agents built in.

Option 1: stay in Cursor and change the model

This is the smallest change. Cursor's model page lists its own models, including Composer and Grok, along with models from Anthropic and Google. Cursor describes Composer as fast and cost efficient for interactive coding. The Anthropic and Google models are third-party options, and the page says they are billed at API list price on the plans that unlock them, so check what your plan includes before you switch everything.

Pick this if you like Cursor itself and you were only on GPT out of habit.

Option 2: bring your own OpenAI key

Pick this if GPT models matter to you and your work happens in local Chat and Agent. Set a monthly budget in your OpenAI account before you start, since a long agent session can use far more tokens than a chat. Keep the key out of your repo, and never paste it into a prompt.

Option 3: use the Codex extension inside Cursor

OpenAI's page says "The Codex IDE extension lets you use the Codex agent directly inside Cursor." Cursor is built on VS Code, which is why this works. The page also notes the limit: the extension "does not change the model used by Cursor Chat, Agent, Tab, Auto, Cloud Agents, or other Cursor services." You end up with two assistants side by side, Codex in its own panel and Cursor's features running on whatever Cursor model you pick.

Option 4: use a gateway

Amazon Bedrock and Azure are the examples OpenAI gives. This mostly suits teams that already buy cloud services through one of those vendors. For a solo developer it's more setup than the problem deserves.

Option 5: move the agent work into Xcode

This is the option many iOS developers should look at first, whatever happens with Cursor. Apple's documentation describes it in "Setting up coding intelligence." Choose Xcode > Settings and select Intelligence in the sidebar. Under Agents, click Get next to the agent you want, then click Install. Apple says that an agent you choose in the coding assistant "automatically has access to Xcode capabilities, such as building and testing your app."

The same screen has more options. Under Chat, you can turn on ChatGPT in Xcode, or sign in to Claude Sonnet & Opus. Add an Agent lets you connect another agent that supports the Agent Client Protocol. Add a Chat Provider accepts a provider that supports the Chat Completions API, hosted online or locally on your Mac. Xcode expects two endpoints from it:

{Model provider URL}/v1/models
{Model provider URL}/v1/chat/completions

For Swift work, the native build and test access is the real reason to try it. An agent in an editor outside Xcode has to run your builds through shell commands and read the output, while Xcode's agents get those capabilities directly. You may still prefer Cursor for large refactors across many files, and nothing stops you from using both.

How to choose

Answer these in order and stop at the first yes.

  1. Do you mostly write Swift and build in Xcode anyway? Try the Xcode agents first.
  2. Do you rely on Cloud Agents, Automations or the Cursor CLI? Stay in Cursor and switch models, because a personal key won't reach those features.
  3. Do you need GPT specifically in Cursor's local Agent? Add your own key and set a budget.
  4. Do you want OpenAI's agent and don't care which editor hosts it? Install the Codex extension.
  5. Does your company already buy through Bedrock or Azure? Ask your platform team about a gateway.

A migration plan for an iOS project

Most of the work is making sure your project isn't tied to one model. These steps take about an afternoon, and you can do them before the cutoff.

Step 1: find where model names are hard coded

Search the repo for model names. They hide in CI scripts, Fastlane lanes, helper scripts and in-app features that call an API directly.

grep -rInE "gpt-[0-9]|o[0-9]-|codex" . \
  --exclude-dir=.git --exclude-dir=Pods \
  --exclude-dir=DerivedData --exclude-dir=node_modules

Read each match before changing it, because the pattern will also catch unrelated words. Any feature that calls OpenAI directly with your own API key is a separate matter, since this change concerns the models Cursor provides. It should keep working, but it's worth knowing which is which.

Step 2: move your rules somewhere portable

If your project guidance lives only in Cursor settings or in chat history, the next tool starts from nothing. Write it down in a plain file in the repo. Here's a starting point for an iOS project:

# Project guide for coding agents

## Build and test
xcodebuild -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 17' build
xcodebuild -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 17' test

## Rules
- Swift only in the app target. No new dependencies without asking.
- UI is SwiftUI. Keep views small and move logic into view models.
- Never edit signing settings, entitlements or the .xcodeproj by hand.
- Run the tests before you say a task is done.

Replace the scheme and simulator with your own. Run xcrun simctl list devices available to see which simulator names exist on your machine. Many agents read a file like this automatically, and for the ones that don't, you can point to it at the start of a session.

Step 3: run the same task through two tools

Pick one small, real ticket. A settings screen with one persisted toggle works well, since it touches SwiftUI, storage and a test. Give the same prompt to your current tool and to one replacement, each on its own branch.

Then compare what matters for iOS work, in this order:

  • Does it build on the first try?
  • Do the tests pass, and did it write any?
  • How many files did it touch that it didn't need to?
  • How did it behave when the build failed?
  • What did the session cost?

One ticket won't give you a benchmark, but it will show you how a tool behaves on your codebase, which is the question you're trying to answer.

Step 4: decide before the date, then write it down

If you work with others, record the choice in the repo so nobody finds out from a failed request. Note which tool and model the team uses, who pays for it, and where the key is stored. If your team has shared rules in Cursor, copy them into the portable file from Step 2 first.

Before you give a new agent your project

Switching tools means handing your code to a new vendor, so take ten minutes to check what it can reach. Apple says an agent you set up in Xcode "may access your project files and other information when processing your requests." It points to "About Intelligence in Xcode & Privacy" in the Intelligence settings for details, and each agent's settings link to its own privacy policy and terms. Read those, especially if a client owns the code.

Then look for secrets that shouldn't be near any agent. iOS repos collect a few of them over time:

  • App Store Connect API keys, the .p8 files often used by Fastlane
  • Signing certificates and provisioning profiles committed by accident
  • GoogleService-Info.plist and similar service config files
  • Scheme environment variables holding real tokens
  • .env files used by build scripts

This command finds the common file types:

find . -type f \( -name "*.p8" -o -name "*.p12" -o -name "*.mobileprovision" -o -name ".env*" \) \
  -not -path "./.git/*" -not -path "./Pods/*"

Move anything real out of the repo and into your keychain or your CI secret store. If a secret was ever committed, treat it as exposed and rotate it, because removing the file doesn't remove it from Git history.

Mistakes to avoid

Waiting for November 12 is the first one. OpenAI says Cursor may end access sooner, so a date in your calendar isn't a guarantee. Run your test ticket this week, while your current setup still works and you can compare the two.

The second is assuming your ChatGPT subscription covers a key. API usage is billed on its own, so check your OpenAI API account has a payment method and a limit before you rely on it in the middle of a release.

The third is switching tools during a release. If you have a build in App Review or a TestFlight round running, finish that first. Agent changes tend to touch many files, and that's a poor mix with a release branch.

The last is judging a replacement on the wrong work. Most tools look good on a new SwiftUI screen. Try one that has to fix a failing test or a build error, because that's where you'll see whether it can read the output and recover.

What to watch next week

Three things could change this advice. The official date may move, since OpenAI says it will confirm one with Cursor. Cursor may announce its own plan, and a staff member said in September that the company would share more about continuity of access. Cursor's model list may also change, so check it again before you commit to a replacement.

The wider lesson applies to any AI coding tool. Models come and go for commercial reasons you can't control, so keep your rules, build commands and tests in the repo, where the next tool can read them.

If you're moving your iOS work to Claude Code and want a ready setup for it, I sell Claude Code + Xcode: The Production iOS Workflow Kit on Gumroad. It's a paid product of mine.

Sources