On June 18, 2026, Cursor announced it had acquired Continue, the team behind one of the earliest widely adopted open-source coding agents. The news landed on continue.dev with a straightforward message: Continue's standalone product path ends, but its ideas and contributors move into Cursor's commercial stack. For a project that helped define what an IDE-embedded agent could look like before every vendor shipped one, the transition raises familiar questions about open source, forks, and who maintains the code you already depend on.
Final 2.0.0, Then Read-Only
Continue shipped a final 2.0.0 release covering its VS Code extension, CLI, and JetBrains plugin. After that tag, the continuedev/continue repository on GitHub went read-only. No new issues, no new PRs, no roadmap posts from the original maintainers on that repo.
The codebase stays under Apache 2.0, which matters for teams who forked, vendored, or built internal tooling on top of Continue's architecture. You can still clone, modify, and ship derivatives. What ends is active maintenance from the Continue team: security fixes, model adapter updates, and compatibility work for the next VS Code or JetBrains release cycle will not arrive from upstream unless someone else picks up the baton.
At more than 34,000 GitHub stars, Continue was not a niche experiment. It was a reference implementation for local-first agents, custom model routing, and context assembly inside the editor. That scale makes the read-only transition feel less like a quiet sunset and more like a platform shift.
What Happens to Forks and Dependents
Apache 2.0 explicitly allows commercial use, so Cursor's acquisition does not retroactively restrict the license on existing releases. Teams running pinned 2.0.0 builds can keep running them. Teams who need ongoing updates face a fork-or-migrate decision.
PearAI is the most visible example of that fork dynamic. PearAI built on Continue as a submodule and marketed an open, multi-model IDE experience. With upstream frozen, PearAI and similar projects inherit the full maintenance burden: model providers change APIs, editor extension APIs drift, and security patches stop flowing from continuedev/continue unless they merge or reimplement changes themselves.
Cursor's pitch is that Continue's capabilities will live on inside Cursor's product rather than as a separate OSS distribution. That may be true for Cursor subscribers, but it does not replace a community-maintained extension for developers who want vendor-neutral tooling or air-gapped deployments without a Cursor account.
Open Questions: Subscriptions, Data, and Control
The announcement leaves several practical questions unanswered for existing Continue users:
- Subscription overlap. Continue offered its own paid tiers and cloud features. Cursor runs on Cursor subscriptions. It is unclear how billing, entitlements, and team seats map for organizations that paid Continue directly.
- Data handling. Continue's cloud and telemetry policies were distinct from Cursor's. Teams with compliance requirements need clarity on where prompts, codebase indexes, and audit logs go after migration.
- Feature parity timeline. JetBrains and CLI users may not move to Cursor's Electron IDE. Whether Cursor backports Continue capabilities elsewhere, or simply recommends switching editors, affects real migration cost.
- Community governance. A read-only repo ends the public RFC process. Design decisions that used to happen in the open now happen inside a commercial product roadmap.
None of this is unique to Continue, but the project's early OSS identity makes the tension sharper than acquiring a closed startup would.
Cursor's Broader Platform Play
The acquisition fits a pattern Cursor has been building for months. Our coverage of SpaceX's acquisition of Anysphere framed Cursor as infrastructure for agentic development at scale, not just a smarter autocomplete. Continue adds agent UX patterns, model orchestration experience, and a large contributor network that already trusts the brand.
It also pairs with Cursor's push into repo-native workflows. Cursor's parallel agents on a git forge assume you want multiple agent sessions coordinated against real branches. Continue's history in editor-embedded agents complements that: less about one-shot chat, more about persistent agent loops tied to the files you have open.
Contrast With GitHub Copilot's Closed Stack
GitHub Copilot has never been an Apache-licensed project you could fork and self-host. Copilot lives inside Microsoft's integrated stack: IDE extensions, Copilot Business billing, GitHub Models, and increasingly GitHub Actions agentic workflows. You get deep GitHub integration and enterprise procurement paths, but you do not get the source to the agent harness or the freedom to run a community fork if GitHub deprioritizes your editor.
Continue's arc moves in the opposite direction from pure OSS toward commercial consolidation, while Copilot started closed and expanded outward through apps and Actions. For web teams choosing a long-term agent platform, the tradeoff is similar in both cases: convenience and polish versus ownership of the toolchain. Continue users who valued OSS now inherit Cursor's terms; Copilot users never had the fork option to begin with.
What Web Developers Should Do Now
If you rely on Continue today, treat June 18 as a decision point, not a panic. Pin 2.0.0 if you need stability while you evaluate alternatives. Audit whether PearAI, Cursor, or an internal fork fits your compliance and editor requirements. Read Cursor's migration guidance as it ships, and watch whether the continuedev repo attracts a community fork with credible maintainers.
The agent market is consolidating fast. Continue helped prove that developers want agents inside the editor with transparent configuration. What happens next is whether that transparency survives inside a single vendor's subscription wall.