Tool
Continue
Continue joined Cursor and its repository is read-only. Decide whether to keep a local setup, maintain a fork, or migrate, with current status and cost boundaries.
Verdict: do not choose Continue as a newly supported team coding platform. Continue says it has joined Cursor, and its official repository says it is no longer actively maintained and is read-only. An existing local-model setup may still be worth retaining, but that is a decision to own compatibility and maintenance, not to buy an ongoing service.
This profile addresses Continue the coding assistant, not similarly named session-transfer tools. The open-source code remains available under Apache-2.0. The repository describes a final 2.0.0 release for VS Code, CLI, and JetBrains, with anonymous telemetry and authentication removed. Those lifecycle facts take precedence over older documentation that still describes platform sign-in or hosted features.
Keep, fork, or replace?
| Your requirement | Decision |
|---|---|
| Supported assistant for a new team rollout | Choose a maintained alternative |
| Working VS Code setup connected to a local model | Retain provisionally if someone owns version and security checks |
| Custom assistant configuration worth preserving | Export configuration and evaluate migration before rewriting it |
| Ability to modify the agent itself | Source remains available, but a fork needs its own maintenance plan |
| Managed hosted service with published support and capacity | Do not infer availability from the retained documentation |
| Existing JetBrains installation | Repository recommends the CLI over the JetBrains plugin; test your actual workflow |
For current cross-product selection, start with the AI coding-agent shortlist. If the terminal is the intended surface, compare the CLI coding-agent options.
What the retained software was built to do
Continue combines conversational assistance with tool-driven code changes. Its Agent documentation distinguishes chat, read-only planning, and tools that can make changes. Tool use normally requests approval; configurable policies can automate or exclude particular tools. The screenshots show a file-read request and the resulting context, not a successful coding benchmark.
Configuration is the reusable part of an existing installation. The YAML reference separates model providers, model roles, rules, prompts, context, and MCP servers. Different models can handle chat, autocomplete, embeddings, or other roles. Tool calling must actually work through the selected provider for Agent mode to be useful; a model name or a capability flag alone is insufficient evidence.
A migration should preserve those decisions explicitly: which endpoint receives source code, which model performs each role, which rules matter, and which tools can write. Copying a chat prompt alone will not reproduce the environment. Use the unfamiliar-codebase guide to document the repository constraints before evaluating a replacement.
Costs and limits after the acquisition
The source license costs $0. That does not include hosted inference, local hardware, electricity, or maintenance. This review does not quote a current Continue subscription price or promise a hosted allowance: the current homepage announces the acquisition, while the repository describes the final release.
With a remote model endpoint, the provider determines billing, context limits, throughput, and retention. With a local model, capacity depends on available memory, model size, and context length. Continue's retained Ollama guide specifically warns that advertised tool support can fail in practice. The guide identifies itself as covering older Continue 1.1.x and Ollama 0.11.x versions, so its sample model names and setup steps are reference material rather than a verified recipe for today's final release.
Local inference and privacy
The final-release notice says anonymous telemetry was removed. That is different from saying every configured data path is local. A remote model, remote MCP server, or explicitly configured development-data destination can still transmit content. The YAML reference includes data destinations and content-level settings; inspect the effective configuration before treating an installation as offline.
For a retained local deployment, record the extension version, model artifacts, provider endpoint, configured tools, and allowed network destinations. Review changes to any of those components as changes to the environment. This is an operational recommendation, not evidence that an unmaintained build has been security-audited.
What users report
In a Hacker News discussion, roscas described using Continue with offline Ollama in VS Code and asked for alternatives after noticing maintenance had stopped. codingdave pointed out that users could still run the software or maintain a fork. These reports identify the actual trade-off: a useful existing local workflow can survive an upstream shutdown, while future support becomes someone else's responsibility. They do not establish present reliability or code quality.
A bounded exit check
Before retaining Continue, reproduce one task that matters on a disposable branch: locate the relevant code, make a small change, run the project's checks, and inspect the diff. Record failure modes and provider cost. Then repeat the same task with a maintained candidate from the shortlist. Keep Continue only if its configuration advantage outweighs the work of owning it; do not confuse continued executability with continued support.
