FIELD GUIDE 20AI, models and agents

continuedev / continue

Continue is still worth studying at the end of active maintenance

Continue helped establish a configurable alternative to sealed coding assistants through editor extensions, a terminal client, model choice, rules, prompts, and tool integrations. The official repository now states that it is read-only and no longer actively maintained, with 2.0.0 presented as the final release. That status is the first fact any prospective adopter needs.

WHAT TO KNOW FIRST

  1. The official repository is read-only and identifies 2.0.0 as the final release, which changes the adoption decision fundamentally.
  2. Continue's lasting design contribution is configurable agents through models, roles, rules, prompts, tools, and editor or CLI surfaces.
  3. Apache-2.0 permits continued use and modification, but a permissive license does not provide an upstream maintenance team.

01The maintenance notice comes before the feature list

The current README says the continuedev/continue repository is no longer actively maintained and is read-only for all users. It describes 2.0.0 as the final polished release of the VS Code extension, CLI, and JetBrains plugin. This is not a small caveat at the end of a review. It changes how every capability should be evaluated. A new dependency normally comes with an expectation of bug fixes, compatibility updates, and security response. A read-only repository transfers those expectations to adopters or forks.

Existing users may reasonably continue with a pinned version while they plan. Researchers may study the architecture, and organizations can fork under the Apache-2.0 license. A new company-wide deployment needs a stronger justification. Editors, model APIs, authentication methods, operating systems, and tool protocols keep changing around an inactive codebase. The correct question is no longer only whether Continue is useful. It is whether the adopting team is willing and able to become part of its maintenance story.

02What the final release still provides

Continue remains available as a coding agent through a command-line interface, VS Code extension, and JetBrains plugin, although the repository recommends the CLI over the JetBrains plugin. The documented feature set includes Agent, Chat, Edit, and Autocomplete modes. Together they cover delegated tasks, questions about code, focused modifications, and inline suggestions. This range helped make Continue a practical laboratory for different levels of model involvement inside a developer workflow.

The final release notice says anonymous telemetry and authentication were removed, alongside bug fixes and other polishing. Those changes simplify some data-flow questions, but they do not make every configured provider local or private. Model requests still travel according to the selected provider, and tools can reach whatever their configuration permits. Evaluate each surface separately. An inline completion provider sees different context and has a different interaction pattern from an agent allowed to run tools across a repository.

03Modes create useful differences in authority

Chat mode is suited to explanation and exploration. Edit mode focuses changes on selected code. Autocomplete proposes text as the developer types. Agent mode can work through broader development tasks with tools and more autonomy. These are not merely interface tabs. They represent different authority and context. A question about an unfamiliar function does not need the same permissions as a task that searches files, executes commands, and applies edits.

Teams can preserve this distinction in any successor or fork. Default to the least active mode that can answer the question, make mutation visible, and require stronger review as tool access expands. A developer should know which files, terminal actions, and external services are available to the agent before starting a task. Continue's mode vocabulary remains valuable because it gives users language for separating assistance from execution, even if the upstream implementation no longer evolves.

04YAML configuration turns preferences into repository policy

Continue documentation centers current customization on config.yaml and marks older JSON configuration and some context mechanisms as deprecated. Configuration can define models, model roles, rules, prompts, tools, and MCP servers. A team can select one model for chat, another for autocomplete, and different capabilities for agent work. Repository-specific configuration can encode conventions that should travel with the code rather than live only in a developer's global settings.

This openness is the repository's strongest enduring idea. It lets teams review how an assistant is assembled instead of accepting an invisible vendor default. It can also create configuration sprawl. Provider credentials, personal overrides, repository rules, and shared prompts need clear precedence and ownership. Keep secrets outside committed YAML, pin model identifiers where reproducibility matters, and validate configuration in a clean environment. With upstream frozen, preserving known-good configuration becomes even more important because future providers may change without a matching Continue update.

  • Separate shareable behavior from developer-specific credentials and machine paths.
  • Keep rules short enough that conflicts and obsolete instructions are visible in review.
  • Document which model role is used for each feature and what data that provider receives.

05Rules, prompts, and MCP show how custom agents are assembled

Rules can tell an agent about coding conventions, repository structure, testing expectations, and prohibited changes. Prompts package recurring tasks. MCP servers add tools or context through a defined integration boundary. Combined with model selection, these pieces let an organization create a coding assistant that reflects local practice rather than a generic chat personality. This compositional approach has influenced how many later agent systems are configured.

Instructions are guidance, not enforcement. A rule that says never modify migrations cannot prevent a tool with write access from doing so. Sensitive limits belong in filesystem permissions, tool schemas, sandbox boundaries, and review gates. MCP servers also expand the trust surface because they may expose source, databases, issue trackers, or external actions. Pin and review server implementations, scope credentials, and log consequential calls. Continue can describe the assembly, while the operating environment must constrain it.

06Offline and private use require a full data-flow check

The documentation includes guidance for self-hosted models and running without internet, reflecting Continue's provider flexibility. A local model can keep model prompts on controlled infrastructure, but the editor extension, indexing process, tools, or package installation may still have network behavior. The final release's removal of anonymous telemetry is relevant and should be verified against the exact built artifact a team deploys rather than assumed from a summary.

Map each data path: code selected for a prompt, indexed repository content, documentation retrieval, model endpoints, MCP calls, logs, crash reports, and update checks. Then test the configuration in a network-restricted environment if offline operation is a requirement. An inactive upstream makes this audit more durable but also more urgent. There will be no routine project update to address a newly discovered endpoint or compatibility problem unless a maintainer outside the original repository supplies it.

07Forking is a product decision, not a Git operation

The Apache-2.0 license allows modification and redistribution under its terms, so an organization can fork Continue. The first clone is the easy part. A maintained fork needs people responsible for dependency updates, editor APIs, provider changes, security reports, release signing, testing, documentation, and user support. It also needs a policy for accepting community patches and for communicating which builds are official inside the organization.

Estimate the work before depending on internal ownership. Review open issues and dependencies, produce a reproducible build, run extension and CLI tests, establish a vulnerability process, and identify the smallest supported surface. Dropping a plugin or provider can be healthier than promising compatibility the team cannot test. If the goal is only to preserve a few ideas, it may be cheaper to migrate configuration patterns into an actively maintained tool than to carry the entire codebase forward.

08How to use Continue responsibly now

Continue is still worth reading. Its separation of modes, model roles, rules, prompts, tools, and editor or terminal surfaces provides a concrete architecture for configurable coding agents. Existing installations can be stabilized with version pins, restricted providers, documented configuration, and an exit plan. Educational use on disposable repositories remains low risk when credentials and network access are narrow.

For a new long-lived deployment, active maintenance should weigh heavily. Aider offers a maintained terminal-centered workflow, while OpenHands currently targets a broader agent control plane. Continue's ranking reflects both the quality of what was built and the reality that upstream has stopped. A responsible article should preserve both facts. The repository is a strong design reference and a possible fork foundation, not a dependency to adopt as if ordinary upgrades will continue.

A SENSIBLE FIRST HOUR

Start small enough to learn the repo

  1. Read the current repository notice and final 2.0.0 release notes before installing anything, and record that upstream is read-only.
  2. Use a disposable editor profile or terminal environment to install the final official release and connect one non-production model provider.
  3. Create a minimal YAML configuration with one model, one rule, and no broad tools, then test Chat, Edit, and Agent behavior on a sample repository.
  4. Export the configuration, review network and data flow, and decide who will own security patches before using the codebase on maintained repositories.

SOURCE LEDGER

What this review is built on

We use the project repository and first-party documentation. Access, licenses and project direction can change, so recheck the linked source before making a production decision.

  1. Continue repository and maintenance noticerepository
  2. Continue documentationdocumentation
  3. Continue releasesrelease
  4. Continue licenselicense