cline vs continue: an agent engine you can still extend versus a finished release you can only fork
Cline and Continue are both Apache-2.0 coding agents with VS Code, JetBrains and CLI surfaces, but they sit at opposite ends of a project lifecycle: Cline is a multi-surface engine still being pushed daily, while Continue has shipped a final 2.0.0 and made its repository read-only. The choice is less about features than about whether you need a maintained dependency or a frozen codebase.
At a glance
| Project | cline/cline | continuedev/continue |
|---|---|---|
| Licence | Apache-2.0Permissive: commercial use allowed | Apache-2.0Permissive: commercial use allowed |
| Maintenance | Commits in the last six monthsLast push September 25, 2026 | Commits in the last dayLast push September 29, 2026 |
| Language | TypeScript | TypeScript |
| GitHub stars | 69,303 | 36,062 |
| Read more | Our analysisGitHub | Our analysisGitHub |
Which one to choose
Choose cline if you need an agent whose repository is still receiving changes, want the same engine across VS Code, JetBrains, CLI, Kanban and an SDK, and can accept model-agnostic configuration plus approval prompts or auto-approve for every command and edit.
Choose continue if you want a free Apache-2.0 agent for VS Code, JetBrains or the CLI and are willing to run a read-only codebase with no upstream fixes, or if you intend to fork the 2.0.0 release and maintain it yourself.
One engine, many surfaces versus one finished product
The architectural difference is the first thing to understand. Cline's README describes a shared agent core exposed through several products: an SDK, a CLI, a VS Code extension, a JetBrains plugin and a separate Kanban board at cline/kanban. The README's own index lists these as distinct locations in the repository, and it states that the JetBrains plugin is a client that talks to the shared agent core. The SDK is documented as the same engine that runs the CLI, Kanban, VS Code extension and JetBrains plugin, with custom tools, multi-agent teams, connectors and scheduled automations. That is an engine-first design: surfaces are clients, and the agent logic lives once.
Continue's README describes a coding agent available as a CLI, VS Code extension and JetBrains plugin, with the final 2.0.0 release covering all three. The README does not describe a shared-core architecture in the same terms, and it recommends using the Continue CLI instead of the JetBrains plugin. The practical consequence is that Continue reads as a finished product with three distribution channels, while Cline reads as a platform whose channels are expected to stay in step. If you want to build on top of the agent, Cline's SDK is the documented entry point; Continue's README does not document an equivalent programmatic API.
Getting each one running
Cline's README gives install commands per surface: npm i -g cline for the terminal, npm i -g kanban for the web task board, npm install @cline/sdk for the SDK, a VS Marketplace listing for the VS Code extension, and a JetBrains Marketplace listing for the plugin. The README does not document a single installer that covers every surface, so setup is a per-surface decision. The README also states that the JetBrains plugin is not currently open-sourced, which matters if you need to audit or patch that client.
Continue's README points to a VS Code listing, an Open VSX listing, an npm package at @continuedev/cli, and a JetBrains plugin, and it recommends the CLI over the JetBrains plugin. Because the repository is read-only, setup is a one-time exercise: you install the 2.0.0 artifacts and there is no later release to upgrade to. Cline's README states that every file edit and terminal command requires approval unless you toggle auto-approve; that approval model is the main setup decision on the Cline side, and it is also the main thing to verify before putting either tool in a CI pipeline.
Approval, autonomy and parallel work
Cline's README documents a Plan mode and an Act mode. In Plan mode the agent explores the codebase, asks clarifying questions and lays out a strategy; in Act mode it executes. By default every edit and command needs approval, and auto-approve removes that gate. The README also describes checkpoints that track changes so the agent's work can be undone, and diff review in VS Code and JetBrains. The Kanban board is documented as running many agents in parallel, each card with its own worktree, auto-commit and dependency chains. That is the scaling story: more agents, isolated worktrees, and a human gate that you can loosen deliberately.
Continue's README does not document a plan/act split, checkpoints, or a parallel task board. Its final release notes mention removing anonymous telemetry, pulling out authentication and squashing bugs. So the operational difference is stark: Cline documents mechanisms for supervising and parallelising agent work, while Continue documents a cleaned-up final release without those supervision features. If you need to run many agents at once with reviewable isolation, Cline is the one with a documented mechanism; if you need a single agent in one editor, both can serve, and Continue's smaller surface is easier to reason about.
Where each one falls short
Cline's weaknesses are visible in its own README. The JetBrains plugin is not open-sourced, so the "open source coding agent" claim does not extend to every surface. The repository index marks the VS Code extension path as work in progress for migration, which suggests the layout is still moving. Model support is broad but external: the README lists Anthropic, OpenAI, Google, OpenRouter, Vercel AI Gateway, AWS Bedrock, Azure and GCP Vertex, Cerebras and Groq, Ollama and LM Studio, and any OpenAI-compatible API. That breadth means you must verify your chosen provider is supported and that the CLI's headless mode meets your CI security requirements, because commands and edits can each require approval. Nothing in the README documents a rollback story beyond checkpoints, and it does not document how checkpoints behave outside the IDE surfaces.
Continue's weakness is structural rather than technical. The README states plainly that the repository is no longer actively maintained and is read-only for all users. The last push recorded for the project is 2026-09-16, but the final 2.0.0 release dates to 2026-06-19, and the README's own note governs what that means: no further releases, no security patches from upstream, and no community fixes through the project. The README also recommends the CLI over the JetBrains plugin, which is an admission that one of the three surfaces is the weaker one. For a tool that runs commands and edits files, the absence of upstream patches is the limitation that matters most.
Licence and maintenance implications
Both projects are Apache-2.0, so the licence itself is not the differentiator. Apache-2.0 permits commercial use, modification and redistribution with the usual notice and patent terms, which means either codebase can be forked and shipped inside a company. The difference is what you inherit when you do.
Cline's repository is not archived and its last push is 2026-09-16, one day before the date of this comparison, so it is reasonable to treat it as a project still receiving changes. Its release list shows desktop-v0.0.20 on 2026-08-28, v4.1.16 on 2026-08-26 and sdk/sdk/v0.0.81 on 2026-08-26, which indicates the surfaces are versioned separately and are all being touched. Continue's repository is also not archived and its last push is 2026-09-16, but the README states it is read-only and no longer actively maintained, and its most recent releases are v2.1.0-vscode and v2.0.0-vscode, both dated 2026-06-19, with v1.3.40-vscode on 2026-06-15. A read-only repository with no release since June is a frozen dependency. If your policy requires upstream security response, Continue fails that test on its own documentation, and Cline is the only one of the two that can currently claim it.
Choosing for concrete scenarios
For a platform team that wants one agent engine behind an internal tool, Cline's SDK and connectors are the documented path, and the Kanban board gives a way to run many agents with per-card worktrees and auto-commit. For a team that needs an agent inside JetBrains IDEs and must audit the client, Cline's README says the JetBrains plugin is not open-sourced, so that requirement is not met; Continue's JetBrains plugin exists but its README recommends the CLI instead, so neither is a clean fit and the requirement should be re-examined.
For a solo developer who wants a free agent in VS Code with no maintenance obligation and no plans to extend it, Continue's final 2.0.0 is a complete artifact: telemetry removed, authentication pulled out, bugs squashed. It will not improve, but it will not churn either. For a team that runs agents in CI, Cline's CLI headless mode plus the approval model is the documented option, and the security review should focus on whether auto-approve can be scoped tightly enough. For an organisation that cannot accept an unmaintained dependency, Continue is out unless it is forked, and the fork cost should be estimated before adoption rather than after.
Bottom line
Pick Cline when you need a maintained, extensible agent engine across IDE, terminal and SDK surfaces, and accept that the JetBrains client is closed and that approvals or auto-approve must be configured for your threat model. Pick Continue when you want a frozen, Apache-2.0 agent for VS Code or the CLI and can live without upstream fixes, or when you are prepared to fork 2.0.0 and carry it yourself. Before committing, verify two things: that your model provider is supported by the project you choose, and that the release you install works with your exact IDE version, since Continue's read-only repository means no fix will arrive if it does not.