Continue Is Archived: What Replaces It

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. The Hacker News question, 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. For Cursor, Anysphere's AI code editor, 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. The trap is 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 the related training topic, 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 the cursor ide mcp support model context protocol question 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 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.

Common questions

• Is Continue really dead if I can still run it?

  Continue is archived, not magically broken. If your current local setup works, you can keep using it as a pinned tool or fork it. The caveat is maintenance: editor APIs, model behavior, security assumptions, and extension dependencies may shift while the upstream repository no longer absorbs that work.

• How to add mcp server to cursor safely?

  Add one MCP server at a time, and start with read-only permissions. A safe first test is one repo, one issue, one read-only context source, and one failing test. Verify that Cursor's agent explains which context it used before you add write actions or broader project access.

• Does cursor ide mcp support model context protocol replace local models?

  No, MCP is about tool and context connections, not the model itself. Cursor MCP can connect the editor's agent to external systems through Model Context Protocol servers. Your local-model decision is separate: you still need to judge model quality, privacy needs, latency, and whether the client handles your chosen model path well.

• What about local Ollama workflows?

  Local Ollama workflows remain a valid reason to keep Continue or test another local-first extension. One developer objection in the thread was that some assistants mishandle local model traces or reasoning output. That is a real compatibility issue, so test with your actual model and task instead of trusting a generic benchmark.

• Should I use Cursor skills or subagents for this?

  Use a Cursor skill when the work is a reusable procedure, such as release-note drafting or migration review steps. Use a subagent or custom agent when the work needs a narrower role with its own instructions. For a Continue replacement test, start with rules plus one skill before adding more agent shapes.

Best ways to use this research

• Best for: developers who used Continue for local or VS Code-centered coding help and now need a realistic replacement path without pretending the old tool vanished overnight.
• Best first artifact: the permission boundary table above, copied into an AGENTS.md note or Cursor rule before adding any MCP server with write access.
• Best comparison angle: compare tools by context boundaries, review notes, and test verification, not by which assistant sounds most fluent in chat.
• Best next experiment: run the same failing-test fix in Continue and Cursor, then compare diff size, context citation, command output, and whether the agent respected forbidden files.

Further reading

• Cursor — Agent
• Cursor — MCP
• Model Context Protocol — 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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.