OpenAI confirmed it’s cutting Cursor off from its models entirely, giving developers until November 12 to find something else. The wind-down doesn’t stop at what Cursor has today: OpenAI said it won’t provide access to future models either, such as Astra, the frontier model it shipped this week.

The fragility of model access is something we’ve spoken out about frequently, and this just the latest event in a long line of them.

Anaconda acquired Kilo in July, and therefore its engineering team moved over from Cursor to Kilo, well before the Cursor/OpenAI breakup became public. Anil and Caitlyn, two of the engineers who made the move, compared notes on what actually changed once they did.

The pricing question came first

Cursor’s subscription bundles model usage into a flat fee, which means you don’t see what a given session actually costs until the bill arrives or the limit hits. Kilo bills per token at whatever the model provider charges, and shows the cost of each session as it runs. For engineers running multi-step agentic work, seeing the cost of your agent helps to scope the work and educates you about agentic behavior.

“I’m doing complicated work, and it’s helpful to know how much this particular task is costing, Immediate cost for every chat session”

“Kilo has transparent pricing and cost for every chat session, as well as a breakdown of what models are used.”

Nothing they’d built had to be thrown out

The fear with any tool migration is losing months of your setup: custom rules, extensions, and the muscle memory of a familiar editor. That mostly didn’t happen here.

Both tools read from the same ~/.agents/skills directory, so the global skills Anil and Caitlyn had already written got picked up immediately in Kilo, and cloud agents worked identically in both, so their multi-worktree setup carried over untouched. The bigger surprise was the editor itself: because Kilo runs as a standard VS Code extension instead of a fork, they got access to the official VS Code extension marketplace, something Cursor’s fork doesn’t fully support.

The one piece of config that needed manual work was .cursor/rules. Their fix was to ask the AI itself: they had Cursor identify what configuration was worth carrying over, then asked Kilo to turn that into a rule. It took one conversation with each tool to get sorted.

“In general, it was easy to move over,” was the summary.

What they miss, and what replaced it

Anil said that Composer, Cursor’s proprietary model, solved certain tasks better than the initial models he tried in Kilo.

What he sees as a good replacement is Auto-Efficient, Kilo’s model router that cross-references a prompt against Kilo’s own coding benchmark to pick the cheapest model proven capable of the task. It hasn’t matched Composer’s ceiling yet, but it comes with something Composer never gave him: you know exactly which models handled a given task, and the cost associated with it. No guessing whether it was worth the price, because the router shows you, and if a task calls for something else, you can point it at any of the 500 models Kilo supports and compare cost against output directly, instead of having to work with opaque credits and rate limits.

Auto-Efficient routing to the best models for the task at hand

Small things that add up

A few other differences showed up in daily use: Kilo’s VS Code base is customizable enough that Anil moved his chat panel to the right side of the screen, matching how he’d set up every other tool he uses. And the prompt navigator, essentially a minimap of a chat session, made it fast to jump back to a specific message in a long-running conversation instead of scrolling through it.

Prompt navigator helps you navigate your longer sessions in the VS Code sidepanel

One org, several sets of rules

Anaconda’s own migration ran with several sub-orgs in Kilo. You might want to have one business unit to keep every inference call inside Europe; another just wants the full model catalog. Kilo handles that at the sub-org level, letting admins set model and provider rules per team from a single screen instead of writing one policy for the whole company. Here’s how that works.

Editor choice varies just as much, and Kilo runs natively wherever engineers already work. The newest JetBrains plugin, rebuilt from the ground up in Kotlin, runs parallel agents in isolated worktrees with the same model access as the VS Code and CLI versions.

The point underneath the story

This is not about Cursor being a bad product or Kilo being flawless, but it is an argument we’ve been making for the past 12 months, which got reinforced after the OpenAI-Cursor split became public: a model dropdown isn’t model freedom. You learn what model freedom means the day you’re forced to switch.

Anaconda’s engineers didn’t switch because a contract forced them to. They switched because they wanted to see what a task costs before running it, and because they wanted the option to use a different model without touching anything else about how they work. That’s a smaller, quieter version of the exact problem now facing every developer with a Cursor seat and a Nov 12 deadline on their calendar, and the mechanics of surviving it come down to the same things Anil and Caitlyn ran into on day one: portable rules, portable context, and pricing that doesn’t hide which model you’re actually using and paying for.

If you’re on Cursor and want to see what the move looks like, Kilo’s migration guide walks through the same steps Anil and Caitlyn took. If you’re weighing the decision for a whole team, talk to us.

Kilo Blog

What Anaconda’s Engineers Found When They…