Continue Is Archived: What Replaces It

Continue.dev was acquired by Anysphere (Cursor) in June 2026. The repository is read-only because of that sale, not a generic maintenance lapse. Cursor recommending itself as the replacement is the acquirer talking.

Continue is the open-source VS Code AI coding agent from Continue.dev, and as of August 2026 its main repository is read-only and no longer actively maintained. Cursor acquired Continue.dev in June 2026 and wound the standalone product down, which is the real reason the repository stopped moving, not a generic maintenance lapse. The Hacker News thread, Continue coding agent is dead. Alternatives?, is really about what to do when a beloved local-first coding assistant stops moving. The short answer: you can keep using Continue if it still fits, but any replacement should be judged by context, permissions, and reviewability more than by chat polish. Because Cursor is the company that acquired and shut down Continue, testing it as a replacement is worth doing on its own merits, with that history in view rather than hidden. That usually means pairing Cursor MCP with rules, skills, and narrower agent boundaries instead of rebuilding one giant assistant.

Treat the archive as a boundary, not a funeral

Continue mattered because it gave VS Code users a practical AI coding loop that could run with local models through tools like Ollama. That was not a small thing. A lot of developers wanted autocomplete, chat, and edit help without sending every experiment through a hosted model path.

The archive notice changes the maintenance story, not the binary on your machine. An unmaintained tool can still be useful for a stable personal workflow. Watch for pretending it has the same security, compatibility, and bug-fix posture it had while maintainers were actively cutting releases.

So the first decision is boring and good: decide whether Continue is now a frozen tool in your kit or a dependency you expect to evolve. If it is frozen, pin it. If you expect it to track editor APIs, model APIs, MCP changes, or local model quirks, start testing alternatives.

One Hacker News objection was exactly right: not maintained is not the same as cannot be used. The sharper question is whether you want to own the fork when your editor, model server, or auth assumptions change.

Compare replacements by the context they can safely touch

The easy mistake is to compare AI coding tools by vibe: which one writes the better first answer, which one has the nicer sidebar, which one feels fastest on a demo repo. That misses why Continue had a following. Its appeal was not only output quality. It was the ability to keep a local, inspectable workflow close to the editor.

MCP is a protocol that lets an AI client connect to external tools and data sources through defined servers. In practice, a Cursor MCP setup can expose GitHub, docs, issue trackers, databases, or local project utilities to the agent without stuffing all of that context into a prompt.

That is powerful, and also where the foot-guns live. A replacement that can read your repo, inspect an issue, query a database, and push a branch is not just a smarter chat box. It is a small operating surface inside your development workflow.

For Cursor users, the useful comparison is: what can the agent see, what can it change, and where does a human review happen? Cursor rules can carry repo conventions. Cursor skills can package repeatable workflows. Cursor subagents or custom agents can narrow a job to one role, like test repair or migration review, instead of letting one broad assistant improvise across everything.

If you are tracking this space through Subagents and skills, this is the piece to keep: the replacement decision is less about finding another Continue clone and more about making the assistant's boundary explicit.

Try Cursor as the replacement without widening access

Do a small experiment before you move your daily coding loop. Pick one repo, one task type, and one external context source. Do not start by connecting every tool you use.

Prerequisites:

• A repo you can safely test against, ideally with a real issue and a real failing test.
• Cursor installed and signed in.
• One MCP server you trust enough to expose to the editor.
• A branch where the agent cannot accidentally ship changes.

Step 1: choose the old Continue job.

Name the workflow Continue handled well. For example: read a failing test, inspect nearby code, propose a patch, and explain the diff. Keep it narrow enough that you can tell whether the replacement is better or worse in 20 minutes.

Step 2: add only the context the agent actually needs.

This is where Cursor's MCP support for the Model Context Protocol becomes practical. You are not adding MCP because it is fashionable. You are adding one server because the agent needs one source of truth, such as issue metadata or internal docs, to complete the task.

Step 3: write the repo boundary down.

Add a small rule or AGENTS.md note before you ask the agent to work. The point is not ceremony. The point is to make the expected behavior visible in the same place as the code.

# AGENTS.md

## AI coding boundary

- Do not edit files under db/migrations without asking first.
- Prefer small diffs that preserve public API behavior.
- Run pnpm test -- --runInBand for changes under packages/api.
- When using MCP context, summarize which external source informed the change.
- Leave a short review note listing tests run and files touched.

Step 4: ask for a patch, not a plan-shaped novel.

A good prompt is concrete: fix the failing test in packages/api, use the issue context if relevant, and stop before editing migrations. This keeps the agent inside the same box you would give a careful teammate.

Step 5: verify the setup works.

The test is simple: the agent should produce a small diff, mention the context it used, respect the boundary, and give you a reviewable summary. If it cannot do those four things, do not connect more tools yet.

For adjacent thinking on where Cursor is putting hosted repo workflows, see Cursor Origin Hosts Code Repos. The same principle applies there: more reach is useful only when the review surface stays clear.

Copy this permission boundary table

Use this as the first artifact when replacing a local Continue workflow with Cursor MCP. It is intentionally conservative. You can loosen it later, but it is much harder to debug an agent that started with broad write access.

The table also answers how to add an MCP server to Cursor safely: start with read-only context, then add write tools only after the agent proves it respects repo rules and produces clean review notes.

Further reading

• continue on GitHub
• Continue coding agent is dead. Alternatives?, Hacker News
• Cursor Agent docs
• Cursor MCP docs
• MCP specification

Keep the replacement small

Keep Continue if it still earns its place, but treat it as frozen software you now own. If you test Cursor next, add one MCP context source, write one boundary file, and judge the result by the diff you can review.