OpenAI has notified SpaceX that it will terminate Cursor’s access to OpenAI models on 12 November 2026. The trigger was SpaceX’s acquisition of the coding startup (roughly $60 billion, completed on 14 August 2026) and OpenAI’s stated reason was blunt: it could not be confident SpaceX would use its technology within the terms of service, citing its experience of Elon Musk’s companies and contracts.
On the numbers, this is a modest event. Cursor’s chief executive, Michael Truell, put OpenAI models at about 5% of Cursor user traffic, and Anthropic responded the same day by saying it would increase the compute available for Claude within Cursor. Most teams will notice nothing on 12 November.
I still changed a policy because of it. Not the tool, the policy. Here is the reasoning, and the three things it changed in how we screen engineers in Singapore.
The part that matters is not the 5%
Engineering leaders are generally good at assessing vendor risk when it takes familiar forms: the vendor raises prices, the vendor is acquired, the vendor deprecates an API, the vendor goes out of business. All four are foreseeable, and all four give you notice proportional to your spend.
This is a different shape. Access was withdrawn because of who owns the customer, over a dispute in which the customer’s users were not participants. No amount of good behaviour, contractual diligence or spending by a Cursor user in Singapore would have altered the outcome. The dependency was invisible because it sat one layer below the thing teams thought they had chosen.
That is the lesson worth generalising: when you adopt a tool that resells someone else’s model, you inherit a relationship you are not party to and cannot inspect.
The reflex that changes everything
For every AI tool your team relies on, write down two names: the company you pay, and the company that owns the model. If they are different, you have a dependency with a relationship you cannot see, cannot influence, and will not be consulted about. That does not mean avoid the tool, it means do not let it become the only way your team knows how to work.
Expert view 1: standardisation was the mistake, not the tool choice
Through 2026 a lot of Singapore engineering organisations did something that looked like good practice: they picked one AI coding assistant, bought it for everyone, wrote internal guidance around it, and built repository-level configuration to make it work well.
Every step is defensible. Together they produce a team whose working method has a single point of failure controlled by a company you have no contract with.
I have stopped approving that pattern. The replacement policy is deliberately unexciting: the company pays for a primary assistant, engineers may expense an alternative if they prefer it, and any tool-specific configuration lives in version control as a first-class asset rather than as personal setup. The cost difference is marginal. The difference in exposure is not.
Expert view 2: the switching cost is real but small, and it is not skill
We advised four Singapore teams through a change of assistant this year, for reasons unrelated to this announcement. The productivity dip lasted between four and nine working days in every case.
What was actually lost was never engineering capability. It was configuration: rules files, saved prompts, editor settings, the accumulated tacit knowledge of how to phrase a request so the tool did the right thing. Teams that had treated those artefacts as versioned assets recovered in days. Teams where they lived on individual laptops took closer to a fortnight and rebuilt them inconsistently.
That is a cheap lesson to act on. If your repository contains tool-specific instruction files, they deserve the same review discipline as source code, and if they exist only in personal settings, you have an undocumented dependency on individual people as well as on a vendor.
Expert view 3: the hiring signal shifted, but not in the direction people expect
The tempting conclusion is that we should now favour engineers who do not rely on AI tooling. That would be the wrong lesson, and an expensive one, refusing effective tools does not make anyone a better engineer.
What we changed instead is that we now observe candidates working both ways. Part of our practical exercise runs with assistance available, part without. We are not looking for people who are equally fast in both modes, because nobody is. We are looking for whether effectiveness degrades gracefully or collapses.
Across 26 Singapore interviews run in this format, 9 candidates were dramatically less effective without tooling, unable to make progress on problems they had handled comfortably minutes earlier. That is not automatic grounds for rejection, and we have hired two of the nine. It is information about how much scaffolding a person will need, and it belongs in the decision rather than being discovered in month three.
Screening engineers in Singapore with and without AI assistance
We run the two-mode practical as standard and report both results, so you see how a candidate performs with tooling and how far their effectiveness falls without it. No assumptions, just the observation.
Let’s talk, brief us on the roleWhat Singapore engineering leaders should actually do this month
Nothing dramatic, and nothing that requires a migration. Four things, none of which takes more than an afternoon:
- Write the two-name list. For each AI tool in use: who you pay, and who owns the model. The exercise takes twenty minutes and is frequently surprising.
- Move tool configuration into version control. Rules files, prompt libraries, editor settings. This is the entire recoverable cost of switching, and it is cheap to protect in advance.
- Verify at least two engineers can work productively in an alternative assistant. Not everyone. Two is enough to prevent the team being stranded.
- Stop writing tool names into job specifications. « Experience with Cursor » in a job advert is a statement about your configuration, not about the candidate’s capability, and it narrows your pipeline for no benefit.
The fourth is the one that most directly affects hiring in this market. Singapore’s senior engineering pool is not large enough to filter on incidental tooling preferences, and doing so removes strong candidates for reasons that will be obsolete within two quarters.
The event was small: five per cent of traffic, ninety days of notice, a competitor immediately adding capacity. The lesson was not small: your team’s working method can be altered by a dispute between two companies, neither of which you have a contract with. Bryan, HireDeveloper.sg
The honest counter-argument
There is a reasonable case against everything above, and it deserves stating. Standardising a team on one excellent tool produces genuine gains: shared vocabulary, transferable configuration, faster onboarding, easier support. Deliberately maintaining plurality has a real cost, paid daily, against a risk that materialises rarely.
I think the trade is worth it at the current stage of this market, because the tools are changing quickly enough that a two-year lock-in is a bigger bet than it appears, and because the mitigation is cheap, version-controlled configuration and two engineers who know an alternative. If the market consolidates and the pace slows, I would revisit that. It is a judgement about volatility, not a principle.
Start with the two-name list
Twenty minutes, one column for who you pay and one for who owns the model. Where the two differ, you have a dependency you cannot inspect. That list is the whole of this article, applied.
Let’s talk, see vetted candidatesFAQ
What exactly did OpenAI announce about Cursor?
It notified SpaceX that Cursor’s access to OpenAI models ends on 12 November 2026, following SpaceX’s roughly $60bn acquisition of Cursor completed on 14 August 2026. OpenAI said it could not be confident SpaceX would use its technology within the terms of service, citing prior experience with Musk-owned companies. Cursor’s CEO put OpenAI models at about 5% of user traffic, and Anthropic said it would add Claude compute in Cursor.
Should Singapore teams stop using Cursor?
No. On the stated numbers the practical disruption is close to zero, with alternative capacity already being added. The reason to pay attention is what the episode demonstrates: model access can be revoked for reasons unrelated to your usage, contract or spend, a category of risk most engineering organisations have never priced.
How does this change what I screen for when hiring?
It raises the value of engineers whose competence is not welded to one assistant. Run part of your practical with AI assistance switched off and observe whether effectiveness degrades gracefully or collapses. In our 26 Singapore interviews using this format, 9 candidates were dramatically less effective without tooling, a finding to weigh, not an automatic rejection.
What is the actual cost of switching AI coding tools?
Lower than teams fear, and concentrated in configuration rather than skill. Across four Singapore teams we advised through a change of assistant, the dip lasted four to nine working days. What was lost was rules files, saved prompts and editor configuration, recoverable cheaply if those artefacts are versioned, expensively if they live on individual laptops.