Your Coding Agent Is a Supplier Now: What the Cursor Cutoff Teaches About AI Tool Continuity
SpaceX closed its $60 billion Cursor acquisition in August, and OpenAI answered by scheduling a November 12 shutoff of its models inside Cursor. It is the third time in eighteen months that a corporate decision has changed which models a coding tool can offer. Here is how to make your engineering workflow survive the next one.
Six Weeks Nobody Planned For
SpaceX's purchase of Anysphere, the company behind Cursor, was one of the largest software deals of the year. TechCrunch reported in June that SpaceX would acquire Cursor for $60 billion in stock, days after its IPO, and the deal officially closed in mid-August. For most engineering leaders it was a business headline, not an engineering event. The editor on their developers' laptops still worked the same way the next morning.
Two weeks later, it became an engineering event. As InfoWorld reported on August 31, OpenAI said it intended to "wind down our contract providing OpenAI models to Cursor, with a proposed shutoff date of November 12, 2026." OpenAI's stated reason was that it could not be confident SpaceX would use its technology within its terms of service, citing its experience with other Musk-owned companies. DevOps.com added that OpenAI will also withhold future model releases from Cursor during the transition.
Cursor's CEO Michael Truell responded that OpenAI models serve about 5% of the platform's user traffic, and DevOps.com noted that Cursor still offers models from Anthropic, Google and SpaceX's own Grok, calling the change "a potentially significant, but hardly existential, disruption." That is a fair description for Cursor as a business. It is not necessarily a fair description for your team.
From today, there are about six weeks until November 12. For a company whose developers standardised on GPT models inside Cursor, that is six weeks to choose a replacement, check that it performs on your codebase, retune the instructions that were written for the old model, and get any new vendor through security review. None of that was in anybody's Q4 plan.
This Is the Third Time, Not the First
It would be comforting to treat the Cursor cutoff as a one-off caused by one unusual owner. The record says otherwise. In June 2025, Windsurf said Anthropic had cut its first-party capacity for Claude 3.7 Sonnet and Claude 3.5 Sonnet with less than five days' notice, while reports circulated that OpenAI was buying Windsurf. Windsurf's users were pushed toward bringing their own API keys, which TechCrunch described as more expensive and more complicated.
The Windsurf story then went somewhere nobody predicted. The OpenAI deal fell apart, Google hired Windsurf's CEO and senior researchers in a $2.4 billion licensing deal, and Cognition agreed to buy what remained days later. A team that had picked Windsurf in the spring had, by the end of the summer, a tool with a different owner, a different leadership team and a different roadmap.
The pattern is not limited to acquisitions. On April 4, 2026, Anthropic told Claude subscribers that their subscription limits would no longer cover third-party harnesses such as OpenClaw, with pay-as-you-go billing as the alternative, and said the policy would extend to all third-party harnesses. Claude Code lead Boris Cherny said the subscriptions "weren't built for the usage patterns of these third-party tools." Whatever you think of the reasoning, a developer who had built their daily workflow on an open-source harness running on a flat subscription saw their cost model change overnight.
Politics can do the same thing. On September 25, a federal appeals court upheld the Pentagon's designation of Anthropic as a supply chain risk in a 2-1 ruling, after the designation was first announced in March. The case is still being litigated and we take no side on it here. The engineering point is narrower: for defence suppliers, whether a particular model may be used in their work is now decided in a courtroom, not in their tooling budget. Four events, four different causes, one shared outcome. Which models a team may use, and on what terms, changed on someone else's schedule.
| Date | Event | Trigger | Notice given to users |
|---|---|---|---|
| June 2025 | Windsurf loses first-party Claude capacity | Acquisition talks with a rival lab | Less than five days |
| July 2025 | Google hires Windsurf leadership; Cognition buys the rest | Collapsed OpenAI deal | None; ownership changed within days |
| April 2026 | Claude subscriptions stop covering third-party harnesses | Provider pricing and capacity policy | Announced shortly before taking effect |
| August 2026 | OpenAI schedules end of model access in Cursor | SpaceX acquisition of Cursor | About ten weeks, to November 12, 2026 |
Why "Only 5% of Traffic" Is the Wrong Number for Your Team
A platform-wide average tells you almost nothing about your own exposure. If 5% of all Cursor traffic runs on OpenAI models, that share is not spread evenly. Some teams will never notice the change. Others picked GPT models deliberately, for a reason that mattered to them, and will be close to 100% exposed. DevOps.com observed that many people on social media did not believe the 5% figure anyway. Either way, the only number that matters is the one from your own usage logs.
The deeper problem is that a coding model is not a drop-in part. Teams tune their workflow to the model they use every day, often without noticing. Rules files are written to correct that model's specific habits. Prompts that produce clean multi-file refactors on one model produce sprawling diffs on another. The analysts InfoWorld spoke to listed exactly these costs: validating a replacement across repository-level coding, debugging and multi-file changes, recalibrating prompts, and accepting a temporary drop in productivity while that happens.
There is also a provenance question that the Cursor story brought up earlier this year. When Cursor launched its Composer 2 model in March, a user found that it was built on Moonshot AI's open-source Kimi 2.5. Co-founder Aman Sanger said "it was a miss to not mention the Kimi base in our blog from the start." There was nothing improper about the partnership, which Moonshot confirmed was authorised. But it shows that many buyers do not know which model, from which company, is actually processing their source code. Many security questionnaires still do not ask.
Scale makes all of this matter more. Stack Overflow's 2025 Developer Survey found that 84% of respondents are using or planning to use AI tools in their development process. When a tool is that embedded, a change to its model roster is not a preference issue for a few enthusiasts. It is a change to how most of your engineering organisation produces code.
Key Takeaways
- Platform-wide traffic shares hide concentration; measure your own team's model usage
- Rules files, prompts and review habits are tuned to one model and do not transfer cleanly
- Buyers often do not know which underlying model processes their code; ask explicitly
- With AI tools this widely adopted, a model roster change is an organisation-wide event
What Actually Breaks When a Model or Tool Goes Away
Most teams underestimate the surface area because they think of the coding tool as an editor. In practice it has quietly accumulated configuration, integrations and institutional knowledge. Before any forced switch, it is worth listing what would need to move.
Start with instructions. Tool-specific rules directories, custom modes, saved prompts and project-level system prompts often hold the most valuable knowledge a team has written down for its agents: build commands, forbidden patterns, architecture boundaries, and the fixes for the mistakes the agent kept making. If those live only in a vendor-specific format, or worse, only in individual developers' settings, they do not survive a tool change.
Then integrations. Coding agents now reach into issue trackers, error monitoring, documentation and databases through Model Context Protocol servers and vendor plugins. Code review bots post to pull requests. Background agents open branches from CI. Each of those connections has its own credentials, permissions and security approval. Every one of them has to be rebuilt and re-reviewed on a new platform, which is why the analysts InfoWorld quoted called a platform switch more complex than a model swap.
Finally, the commercial and compliance layer. Single sign-on, seat management, audit logs, data retention settings and the data processing agreement are all tied to one vendor. A new owner can change any of them. A replacement vendor needs all of them set up again. For European companies, a new model provider handling source code or personal data in logs is also a question for your records of processing, not only for your engineering team.
Keep the Knowledge in the Repository, Not in the Tool
The single most effective defence is simple. Store everything your agents need to know in the repository, in formats that more than one tool can read. The best current example is AGENTS.md. According to the AGENTS.md project site, it is "a simple, open format for guiding coding agents," now stewarded by the Agentic AI Foundation under the Linux Foundation and used by over 60,000 open-source projects, with support listed for tools including OpenAI's Codex, GitHub Copilot, Cursor, VS Code, Zed and Aider. A team whose conventions live in AGENTS.md can point a new tool at the same repository and keep most of what it has learned.
The same principle applies to integrations. An MCP server that your team runs and configures in the repository can be connected to any client that speaks the protocol. A proprietary plugin cannot. When you choose how to connect agents to your tracker, observability stack or internal APIs, prefer the option you can take with you. We covered the security side of those connections in our piece on attacks against coding agents, and the same inventory serves both purposes.
The third asset is a small evaluation set for your own codebase. You do not need a research lab. Twenty to forty representative tasks, such as a bug fix in the billing module, a migration, a new endpoint with tests or a refactor across three packages, each with a clear pass condition, are enough to compare two models on your work rather than on public benchmarks. When a model disappears, that set turns a debate about preferences into a one-day measurement. It is the same discipline we recommend for AI features in our article on the eval gap, applied to your own tooling.
Finally, support at least two models in daily use. The analyst advice InfoWorld reported was to "support multiple models, regularly test alternatives and avoid making important workflows too dependent on one model," and to make sure "prompts, agent configurations, evaluation methods and tool integrations can be reused when the underlying model changes." That is not a vote against standardising. Pick a primary tool. Just make sure the second option has been used recently enough to be a real fallback, not a theoretical one. For the architecture side of the same idea in your product, see our guide to model portability.
Key Takeaways
- Put agent conventions in AGENTS.md or equivalent open files committed to the repository
- Run integrations as MCP servers you control rather than vendor-only plugins
- Keep a 20-40 task evaluation set drawn from your own codebase to compare models quickly
- Keep a second model or tool in real, recent use so the fallback is proven
Put Change of Control Into the Contract
Coding tools were mostly bought like productivity software: a credit card, a seat count and a quick security review. They now read your source code, your error logs and sometimes your production data, and their ownership can change within a quarter. They deserve the contract terms you would expect from any supplier with that level of access.
Start with notification. Ask for written notice of any change of control and of any change to the model providers that process your data. In the EU this is not only good practice. Article 28 of the GDPR requires a processor working under general written authorisation to inform the controller of any intended addition or replacement of other processors, giving the controller the opportunity to object. If your coding tool sends prompts that contain personal data to model providers, those providers belong in that chain.
Next, ask for a model roster and a disclosure commitment. Which base models power the tool's own named models, which companies host them, and in which regions? Composer 2 showed that the answer is not always on the launch page. Then negotiate exit terms: data export in a usable format, deletion certificates, and the right to end the contract without penalty if the owner or the core model providers change. Pricing changes deserve the same treatment. We covered the budgeting side in our article on usage-based billing for AI coding tools.
None of this needs a large legal project. A one-page addendum with five clauses on change of control, subprocessor notice, model disclosure, data export and termination rights covers most of the risk. Vendors that sell to regulated industries already have most of it. Those that refuse are telling you how much notice you should expect next time.
Key Takeaways
- Written notice of any change of control or change to underlying model providers
- Model roster disclosure: base models, hosting companies and processing regions
- Data export, deletion certificates and penalty-free exit on change of ownership
- Under GDPR Article 28, processors must inform controllers of new or replaced sub-processors
If You Use Cursor With GPT Models: A Six-Week Plan
For teams directly affected, the calendar is short but manageable. The goal is to finish before November 12, not on it, so that nobody discovers a broken workflow on the morning of a release.
In week one, measure. Pull usage data from the admin console to see which developers and which workflows actually depend on OpenAI models. Talk to the heaviest users and write down why they chose those models. The reason is usually a specific strength, such as long refactors, a particular language or better test generation, and that is what the replacement has to match.
In weeks two and three, evaluate. Run your internal task set against the candidate models still available in Cursor and, if you are considering a platform move, against one or two other tools. Record pass rates, review effort and cost, not impressions. At the same time, move any rules or prompts that were written around GPT behaviour into AGENTS.md and adjust them for the new model.
In weeks four and five, switch. Change the default model for affected teams, re-approve any integrations that change, and update the data processing records if a new provider is now involved. Keep the old configuration documented so you can compare. In week six, review: check review times, defect rates and developer feedback against the baseline, and write down what you would do faster next time. You will need it. The events of the last eighteen months suggest it is a question of when, not if.
Key Takeaways
- Week 1: measure real OpenAI model usage and the reasons behind it
- Weeks 2-3: evaluate replacements on your own tasks; move rules into AGENTS.md
- Weeks 4-5: switch defaults, re-approve integrations, update processing records
- Week 6: compare against baseline and document the switch as a reusable runbook
Your Development Partner's Toolchain Is Your Dependency Too
Companies that work with outsourced or augmented engineering teams have one more exposure to check. Your partner's coding tools touch your code, and a disruption in their stack becomes a disruption in your delivery. Ask your vendor the same questions you would ask yourself: which tools and models their engineers use on your repositories, where the agent instructions live, how quickly they could switch, and whether their contracts with tool vendors include the protections above.
At Stepto we treat AI tooling as part of the delivery infrastructure we are accountable for, not as individual developers' preferences. Our dedicated development teams keep agent conventions, MCP configurations and evaluation tasks in the client's repository, so the knowledge belongs to the client and works across tools. We use more than one model in daily work, disclose which providers process client code, and can change a team's tooling without stopping delivery. When a vendor changes hands, our clients get a plan, not a surprise.
The nearshore model helps here in practical ways. Our engineers in Serbia work in Central European Time, the same working day as European clients and with a shared window of several hours with US East Coast teams, so a tooling migration can be planned and reviewed together rather than passed back and forth overnight. Because we operate under GDPR, subprocessor notices and data processing records are part of normal practice. If your team is facing the November 12 deadline without spare capacity, Stepto's AI engineers can run the evaluation, move your agent configuration into portable formats and hand back a workflow that is no longer tied to one vendor's corporate decisions.
For companies that want this capacity as part of a longer engagement, nearshore development with Stepto gives you a senior team that builds your product and also keeps the AI toolchain behind it portable, documented and auditable. That is the part of AI-assisted delivery that rarely appears in a sales deck and matters most when something changes.
Buy Coding Tools Like Suppliers, Not Like Editors
The Cursor cutoff is not a story about one acquisition or one rivalry. It is the clearest example yet of a pattern visible since 2025: the models behind your developers' daily tools can be withdrawn, repriced or restricted by decisions made in boardrooms and courtrooms, often with weeks of notice or less. The response is not to avoid AI coding tools. It is to own the parts that matter. Keep agent instructions and integrations in your repository in open formats, keep a small evaluation set and a proven second option, and write change of control and model disclosure into your contracts. If you would like help making your engineering workflow portable before the next deadline arrives, Stepto's dedicated development teams can do the work alongside your engineers and leave the knowledge where it belongs: with you.
Building a team in Eastern Europe?
StepTo helps European and US companies build senior-led nearshore engineering teams in Serbia. Let's talk about what your next engagement could look like.
Start a conversationMore from StepTo on this topic
- 84% of Developers Use AI. Only a Third Trust It. Here's What That Gap Is Costing Your Engineering Team
84% of developers use AI but only 32.7% trust it, and fewer than half always verify it before committing. Inside Stack Overflow's adoption-trust paradox.
- The Open Source AI Fork: Why Enterprise Software Strategy Just Split Into Two Irreversible Camps
Stanford's AI Index puts open models 3.3% behind the best closed ones. Why your next AI choice is an infrastructure philosophy question.
- .NET 8 and .NET 9 Both Die on November 10. Your Upgrade Is an Engineering Project, Not a Version Bump.
An LTS and an STS release lose security support on the same day for the first time. Changing one line in the project file is the easy part. What actually breaks on the way to .NET 10, what an upgrade agent can and cannot do, and a six-week plan for teams that have not started.
Written by
Igor GazivodaFounder & CEO · StepTo
Igor has 15+ years in software engineering and business development. He specializes in scaling engineering teams, nearshore strategy, and AI-driven product development. He holds a Master's in Computer Science from the University of Belgrade.
LinkedIn →