Your Coding Tool Should Not Choose Your Model for You

OpenAI announced last night that it intends to stop providing its models to Cursor following Cursor’s change of control, with future models withheld and existing access proposed to end on November 12, 2026.

There will be plenty of debate about the companies involved, the contracts they signed, and whether OpenAI made the right decision. I am not going to litigate that here.

Thanks for reading Kilo Blog! Subscribe for free to receive new posts and support my work.

I am more interested in what the announcement means for developers.

Developers, or the enterprises they work for, chose Cursor. They chose OpenAI models. They built those choices into the way they work every day. Now, they may lose the ability to use them together because of a dispute they did not create and cannot resolve.

That is the risk of renting your workflow from companies whose incentives you do not control.

A model dropdown is not model freedom

Most AI coding tools now offer more than one model (even if they’re only from one lab). That is good. It is also not the same thing as model freedom.

A model dropdown tells you which models a product has decided to make available today. Model freedom means you retain meaningful choice when the market changes tomorrow.

You should be able to choose the best model for a particular task. You should be able to use one model for planning, another for implementation, and another for code review. You should be able to optimize for quality when the work is difficult and for speed or cost when it is not. You should be able to bring your own API key, use a managed provider, or run an open model.

Most importantly, you should be able to change models without changing the rest of your development environment.

The best coding model today will not be the best coding model forever. It may not even be the best model for the next task in your queue. The market is moving too quickly, and the models are too different, for developers to make one permanent choice.

Model freedom is not about having the longest list of models. It is about making sure developers—not model companies, coding-tool companies, or disputes between them—remain in control.

When your coding-tool company also builds a model

There is a basic conflict when the company building your coding tool is also building the model inside it.

That company has an economic incentive to make its own model the default. It decides which competing models receive the deepest integrations, which get new capabilities first, how they are priced, and whether they remain available. It can use the product experience to drive demand toward the part of the business it most wants to grow.

None of this requires bad intent. In fact, each individual decision may be perfectly rational.

That is precisely the problem. The incentives are structural.

A model company will ultimately make decisions that protect its models, its contracts, its safety obligations, and its competitive position. Those decisions may sometimes align with what developers want. They will not always.

If the company making your software is also building a model, you will never have complete model freedom. You have access for as long as that access supports the company’s broader strategy.

Model freedom is also operational resilience

This announcement is unusually visible, but losing access to a model is not a theoretical risk.

Providers experience outages. They impose rate limits. They change prices, retire models, update policies, and adjust capacity. Model quality can improve or regress between releases. Commercial relationships end. Companies are acquired. Strategies change.

Teams should be able to route around those changes.

If one provider is unavailable, developers should be able to keep working. If a model becomes too expensive, teams should be able to move appropriate workloads elsewhere. If a better model launches, they should be able to try it without rebuilding their workflows. If an enterprise needs tighter controls, it should be able to add those controls without forcing every developer and every task onto the same model.

Multi-model access is not a novelty. It is protection against concentrating a critical engineering workflow in a single provider.

Losing a model may still be inconvenient. It should not require replacing the tool your team uses to build software.

Kilo does not build foundation models—and that matters

Kilo is an independent coding platform. It does not build foundation models.

That is not a missing piece of Kilo’s strategy. It is central to it.

Kilo’s job is to help developers use the right model for the work, regardless of who made it. I want OpenAI, Anthropic, Google, xAI, Arcee, Poolside, Z.ai, Minimax, and the next generation of model providers to compete for every task. When one of them builds something better, Kilo users should benefit.

Kilo competes on the quality of the coding experience: how effectively agents understand your codebase, use context, plan work, write and review code, operate across surfaces, and fit into the way your team already builds software.

Kilo does not need to steer you toward a proprietary model to make another part of its business work. Its incentives are straightforward: Kilo succeeds when developers can use the best available models successfully.

Independence does not eliminate every dependency. Model providers can still change their terms, restrict access, or make commercial decisions that affect availability. No coding platform can promise otherwise.

What an independent platform can do is avoid making one provider’s incentives the center of your entire workflow. It can support multiple paths to models, make switching easier, and treat portability as a product requirement rather than an edge case.

What developers should demand

Developers evaluating an AI coding platform should look beyond the models displayed in the interface today.

Ask whether you can bring your own API keys. Ask whether model names, prices, and limitations are transparent. Ask how quickly new models become available. Ask whether competing models receive first-class support or merely appear in a dropdown. Ask whether your prompts, rules, context, and workflows remain portable when you switch.

And ask the most important question: does this company benefit when I choose the best model for me, or when I choose the best model for it?

That answer will tell you more about your long-term freedom than any current feature matrix.

Choose your tool. Then choose your model.

The current Cursor and OpenAI situation will eventually reach some conclusion. The underlying risk will remain.

AI companies will keep competing. Contracts will be renegotiated. Providers will move further into the application layer. Coding tools will be acquired. Models that feel indispensable today will be surpassed, repriced, restricted, or retired.

Developers should be able to benefit from that competition without rebuilding their working environment every time the market changes.

Your coding tool should help you choose the best model. It should not make that choice for you—or allow someone else’s corporate dispute to make it on your behalf.

What now?

If you’re a Cursor user, looking to experiment with Kilo, you can get started with our migration guide.

If you’re a leader, looking to move your org to Kilo, we can help.

Thanks for reading Kilo Blog! Subscribe for free to receive new posts and support my work.