Continue, a project closed in June 2026

Continue, a project closed in June 2026

Continue was among the first widely used open source coding assistants. An extension for VS Code and JetBrains, any model you liked, full control over where code went. For teams that could not send a repository to an outside service, it was the default answer for two years.

On 16 June 2026 a notice went up on the project site saying Cursor had acquired the team and was winding the standalone product down. The final VS Code extension release, tagged 2.1.0, reached the extension registries on 19 June. The repository went read only, and cloud service data was deleted after 15 July 2026.

This text covers what follows in practice: what still works, what is gone, and what sensibly replaces the tool in an existing setup.

What exactly happened

The acquisition was of a team rather than a product. The creators moved to the company behind Cursor, and the tool they built stopped being developed as a separate entity.

Wider context is worth adding, since without it the decision looks isolated. The same day, on 16 June 2026, an agreement was signed under which SpaceX acquires the company behind Cursor in an all stock transaction valued at sixty billion dollars, with closing planned for the third quarter. The developer tooling market is consolidating, and open projects without a revenue model of their own are the side being bought.

Three dates matter to a user. Releases ended in June, so the extension gets no more fixes. The repository is read only, so issues and pull requests will not be accepted. Cloud data was removed in mid July, so configurations held service side no longer exist.

What still works

The code stays under the Apache 2.0 licence and nobody can revoke that. It is a permissive licence, so using, modifying, and deploying it commercially remains allowed even after the project closed.

In practice that means an installed extension keeps working, provided it runs with your own key or a local model. Calls go straight to the model vendor, so they do not depend on infrastructure that no longer exists.

models:
  - name: local
    provider: ollama
    model: qwen2.5-coder:7b
    roles: [chat, edit, autocomplete]

A configuration like that, resting entirely on Ollama, references no external service. A team that used the tool this way can stay on it for a good while.

Splitting the roles matters here, because autocomplete and chat have entirely different timing requirements. The smaller model answers in tens of milliseconds, the larger one may take a second to think.

models:
  - name: autocomplete
    provider: ollama
    model: qwen2.5-coder:1.5b
    roles: [autocomplete]
  - name: chat
    provider: ollama
    model: qwen2.5-coder:7b
    roles: [chat, edit]

Pin the versions, since new ones will not appear anyway. In the extension registries the editor plugin stopped at 2.1.0 on 19 June 2026, and the command line tool at 1.5.47 in the npm registry on 18 June, even though project material announces a final two for both.

npm install -g @continuedev/cli@1.5.47
cn --version

Turn off automatic extension updates deliberately. Not because a bad version will arrive, but because none will, and an enabled update mechanism creates the illusion that the tool is being watched.

The boundary is clear, though, and worth knowing before deciding. No releases means no security fixes. A change to the extension interface in the editor or to a model vendor's API will eventually break something, and nobody will fix it. Maintaining your own branch is possible, only rarely worthwhile for a tool with free replacements.

What replaces it

The choice depends on which element drove you to Continue in the first place. For most teams that was three different things, and each points somewhere else.

In a migration the extension itself rarely costs the most work. What does is reconstructing the context a team accumulated over years: project rules, style guidance, and convention notes. Move those into a file the new tool understands rather than writing them again.

The second thing to move is model keys. Previously held in extension configuration, after a tool change they belong in environment variables or a secret manager. It is also a good moment to rotate them, since the configuration is being touched anyway.

A wind down plan, step by step

A team still using the tool daily needs a plan rather than a general recommendation. The order below limits disruption.

Start with an inventory. Check who actually uses the extension, in which editors, and with which models. It usually turns out that part of the team already moved elsewhere and that configurations differ between people more than anyone assumed.

The second step is gathering project rules in one place. Everything describing conventions, style, and repository context goes into a file in the repository, independent of any tool. That file outlives successive assistant changes.

# Project conventions

- Components in PascalCase, directory `src/components`
- API calls only through `src/api/client.ts`
- Tests next to the source file, named `*.test.ts`
- No comments in generated code

The third step is testing a replacement on a real task. Pick one person and one task of medium difficulty, a refactor spanning several files for instance. A day of work says more than a capability list on a vendor page.

The fourth is rotating keys and removing the old configuration. The extension file holds a model vendor token, so an abandoned setup leaves a working key somewhere nobody watches.

grep -rlE "sk-[A-Za-z0-9_-]{20,}" ~/.continue 2>/dev/null
rm -rf ~/.continue

The first command lists files containing something that looks like a key, and it is worth running before deleting the directory so you know which keys to rotate. Deleting the files does not invalidate the token, so without rotation on the vendor side it still works everywhere somebody copied it earlier.

The fifth is setting an uninstall date. Without one in the calendar an unsupported extension stays for good, and the risk grows quietly.

The whole process usually takes one person a week of work spread across two calendar weeks. The largest cost is not configuration but habit: keyboard shortcuts, the way questions get asked, and what the team learned about the previous tool's behaviour. Account for that cost rather than assuming swapping an extension is neutral.

The local model, the reason many people stay

The largest group of users picked this tool for one reason: code never left the machine. That requirement did not vanish with the project, so it is worth saying how to meet it today.

The arrangement is simple. You run the model locally and the extension addresses it over a localhost URL. For completion take a smaller model, a few billion parameters, since response time is what counts. For chat and multi file changes take a larger one, if the hardware allows.

Hardware requirements decide whether such a setup makes sense. A seven billion parameter model at four bit quantisation fits in a few gigabytes of memory and runs smoothly on a current laptop. Models around thirty billion parameters need a machine with a suitable card or a computer with unified memory, and the quality gap is often smaller than rankings suggest.

In fairness, a local model performs worse than the best commercial ones, particularly on tasks spanning many files at once. For completion and simple edits the difference is slight; on a hard refactor it shows. The choice is therefore a compromise rather than a one to one swap.

How it worked, or what to look for in a replacement

It helps to know what the tool actually did, since its capability list makes a good checklist when picking a successor.

Three working modes formed the base. Chat answered questions about code without modifying files. Plan mode let you review a change before applying it. Agent mode applied changes across many files at once.

The second element was inline completion, usually backed by a smaller and faster model than the one used for chat. That split matters in practice: a suggestion must appear within tens of milliseconds, while an answer to a question may take a second.

The third was configuration in a file kept in the repository, so a team worked on identical settings. A tool where everyone configures models locally leads to the same suggestion looking different for each person.

The fourth was support for context sources: files, directories, documentation, search results. That mechanism drives answer quality more than model choice does, since a model without the right code fragment guesses.

What this story says about the market

Continue did not disappear because it was bad. It disappeared because an open coding assistant is a hard business, and the competition holds models nobody else can access on the same terms.

The mechanism repeats. A tool wins users because it offers freedom of model choice and runs locally. Maintenance costs money, so a cloud layer and a team plan appear. That layer competes with products from companies earning on their own model, which can price the tool lower because they recover the cost elsewhere. It ends with the team being acquired.

The conclusion is not "avoid open tools". It is rather: expect the wrapper layer to be replaceable, and build a process where replacing it costs a day. Code, conventions, and team knowledge stay; extensions come and go.

Note too that users lost no capability, only the convenience of a single wrapper. The models, the editors, and the protocols are the same, and most of a closed tool's features can be assembled from parts available today at no cost.

The same principle applies to the model access layer inside an application, as covered alongside LangChain. A thin interface you can switch is cheaper than a migration after a year on one vendor.

The lesson for choosing tools

Closing a project with thousands of users inside a week is a reminder that an open licence secures the code rather than continuity of development.

The practical conclusion is simple. When picking a tool, check how it makes money. A project without a revenue model, maintained by a company funded from an investment round, is a candidate for acquisition or shutdown regardless of how good it is technically.

The second conclusion concerns tool lock in. The easily replaced layer is the editor extension. The hard to replace layers are accumulated project context and team habits. Keeping rules and conventions in plain files in the repository turns a tool change into a day's work rather than a quarter's.

The third concerns models. A tool letting you connect any vendor protects you from a price change on the other side upending a budget. The same principle applies to choosing an assistant as to the model access layer inside an application.

Common migration mistakes

The first is leaving a working extension in place with no decision made. A tool without security fixes, holding access to a repository and to keys, is a risk growing every month. Deciding to stay on it is fine, provided the decision is deliberate and carries a review date.

The second is moving to a closed tool without checking where code goes. If locality drove the original choice, a replacement sending the repository to a cloud undoes the entire point of the earlier decision.

The third is abandoning accumulated project rules. They are the most valuable part of the configuration and the only part you cannot quickly recreate, since they formed over months alongside ordinary work.

The fourth is leaving keys in the old configuration. The file of an extension you no longer use still holds a model token, and a tidy up is the moment to remove and rotate it.

The fifth is picking a replacement after one day of testing. A coding assistant is judged over a week of work on a real project, since only then does its handling of a specific repository's context become visible.

FAQ

Does Continue still work?

An installed extension works provided it uses your own model key or a local model. It receives no fixes at all, security fixes included, and the cloud service along with its data was removed in July 2026.

Is the code still open?

Yes, the Apache 2.0 licence remains in force and permits using and modifying the code, commercially included. The repository is read only, though, so development would mean forking it and maintaining that fork yourself.

What should I pick instead?

If locality was the point, take an extension that works with Ollama, Cline or Roo Code for instance. If comfort and quality were, Cursor or a command line assistant built on Claude is a reasonable choice.

Can service data be recovered?

No, cloud data was deleted after 15 July 2026. Configurations kept locally in repository files remain untouched, and those are the ones worth carrying into a new tool.

Why was the project closed?

Cursor acquired the team and wound the standalone product down. The context is a wider consolidation of the developer tooling market, including the transaction in which SpaceX acquires the company behind Cursor in an all stock deal worth sixty billion dollars.

The acquisition was covered by The New Stack, and the archived code remains in the GitHub repository.