Cursor 收购后的 Continue.dev 替代方案

Continue.dev 已作为产品终结：continue.dev 现在是一页告别页，上面写着“Continue 已被 Cursor 收购”；GitHub README 称该仓库“已不再积极维护，并对所有用户只读”；其背后的托管平台也已不存在。客户端仍可安装，并且仍可通过你自己的端点运行，因此你不必今天就迁移——但登录、hub 和账户都已消失，而文档网站没有说明这一点。值得迁移的现有替代方案是 Cline 和 opencode；应避免的是已归档的 Roo Code。

在其他内容之前先澄清一个歧义，因为这个查询混入了无关内容。本页面讨论的是 Continue Dev, Inc.——位于 continue.dev 的编码代理，提供 CLI、VS Code 扩展和 JetBrains 插件。它不是 continue 循环控制关键字，不是 Visual Studio 的“编辑并继续”调试功能，也不是 continue.com；后者是另一个无关的长寿研究组织，只是使用了更短的域名。

Continue.dev 被 Cursor 收购：实际可以验证的情况

三个日期可以直接核查，但公告日期无法核查。continue.dev 网站包硬编码了一个 2026-06-15T00:00:00Z 的停服锚点，并包含三个阶段——early、mid、final——目前固定为 mid。最终的 VS Code 版本于 2026 年 6 月 19 日发布。The New Stack 以 JSON-LD 发布日期为 2026 年 6 月 22 日 的形式报道了这次收购。对于公告本身，该文章措辞谨慎——称 Continue 在“6 月 16 日左右”更新了主页——而且没有任何第一方通知带有日期，因此本页面将 6 月 16 日视为报道内容，而非已确立事实。

README 还声称“VS Code 扩展、CLI 和 JetBrains 插件最终都发布了 2.0.0 版本”，包括移除匿名遥测和身份验证。两个注册表中的三分之二与此不一致，而你实际安装时使用的是注册表。

四项检查均于 2026 年 9 月 19 日完成。在 v2.0.0-vscode 标签中，extensions/cli/package.json 仍显示版本 0.0.0-dev，并且没有 CLI 2.x 的 git 标签——因此准确的说法是，CLI 最新发布的 npm 版本是 1.5.47，而不是说 CLI 2.0.0 在任何地方都从未存在过。遥测和身份验证移除是 README 的说法；本页面没有检查任何已发布的构建版本。README 还建议优先使用 CLI，而不是 JetBrains 插件。

Continue.dev 定价：没有价格，也没有可恢复的旧价格

Continue 的常见问题解答指出：“定期计费已停用，今后您不会再产生任何来自 Continue 的新订阅费用”；账单相关问题请联系 support@continue.dev；并表示：“您账户中剩余的任何未使用付费额度都将退款”——但不包括已使用的额度、促销额度、试用额度、免费赠送额度、礼品额度和客服发放的额度，以及支付处理费和税费。这是 Continue 的说法；本页面无法核实是否实际发放了任何退款。

continue.dev/pricing 返回 HTTP 404，而承载付费平台的主机要么已从 DNS 中消失，要么不再响应，因此不存在可引用的当前套餐价格，也无法从在线来源恢复历史价格。应将替代方案文章中任何“Continue 每月收费 $X”的数字视为未经验证。客户端本身采用 Apache-2.0 许可且免费；你唯一持续产生的成本，是你将客户端指向的端点所对应的模型 API 账单。

仍然有效的内容、已经消失的内容，以及文档中的陷阱

这一部分值得仔细阅读，因为 docs.continue.dev 返回 HTTP 200，在新用户进入的页面上没有收购或停服横幅，并且仍在 Requirements 下列出“一个 Continue 账户或 Anthropic API key”，以及 cn login；文档称后者“会打开浏览器以向 Continue 进行身份验证”。这句话有一半仍然有效：Anthropic key 路径是本地路径。账户这一半指向的平台已经消失。

这些失效主机的读取结果来自 DNS 查询、连接超时和 HTTP 状态检查，以及 Continue 已发布的文档。没有安装或执行任何内容，因此本页面没有描述 CLI 在访问一个不响应的主机时的行为。

让 Continue CLI 和 VS Code 扩展继续使用你自己的端点

Continue 的 OpenAI provider 页面将 provider: openai 记录为协议，而不是厂商，并提供用于兼容端点的 apiBase 覆盖项。Continue 的 CLI 配置页面给出了解析顺序——先使用 --config 标志，然后是已保存的配置，最后是默认的 ~/.continue/config.yaml；源代码会将该目录拼接到主目录上，因此在 Windows 上它会落在 %USERPROFILE%\.continue\config.yaml。在修改文件前先备份——cp ~/.continue/config.yaml ~/.continue/config.yaml.bak——因为恢复这一个文件就是完整的回滚操作。

name: continue-after-sunset
version: 0.0.1
schema: v1
models:
  - name: Agent model
    provider: openai            # the protocol, not the vendor
    model: claude-sonnet-4-6
    apiBase: https://api.kunavo.com/v1
    apiKey: sk-kn-...
    roles: [chat, edit, apply]
    capabilities: [tool_use]    # documented as required for Agent mode

  - name: Autocomplete model
    provider: openai
    model: claude-haiku-4-5
    apiBase: https://api.kunavo.com/v1
    apiKey: sk-kn-...
    roles: [autocomplete]

有两个值得了解的源代码级细节，它们都是从已发布的 v2.0.0-vscode 标签读取的，而不是来自文档。第一，忽略通常关于末尾斜杠的说法：如果缺少斜杠，core/llm/index.ts 会向 apiBase 追加一个斜杠，随后 core/llm/llms/OpenAI.ts 会以它为基础相对解析每个端点，因此 /v1 和 /v1/ 的行为完全相同。你不能省略的是 /v1 本身——Continue 自己的 404 处理程序会打印一条提示，内容正是这一点。

第二，真正容易踩坑的地方。使用 provider: openai 时，如果模型 ID 匹配 /^o[0-9]+/ 或 /gpt-[5-9]/ 且你没有设置 useResponsesApi: false，Continue 会悄悄地将请求路由到基础 URL 加 /responses 的 POST，而不是 /chat/completions；对于相同的 ID，它还会将 max_tokens 换成 max_completion_tokens。只实现 chat completions 的网关，恰好会在这些 ID 上失败；Continue 自己的 provider 页面记录了逃生口 useResponsesApi: false，但对触发条件的描述比代码更窄——页面称其为“o-series 和 gpt-5 模型”，而正则表达式实际覆盖 gpt-5 到 gpt-9。Kunavo 的 API 提供 /v1/chat/completions、/v1/responses 和 /v1/messages（已在本仓库中于 2026 年 9 月 19 日验证），因此无论哪种情况，该分支都有实际对端——这是路由存在性检查，而不是兼容性测试。上方代码块中的 ID claude-sonnet-4-6 不匹配任何一种模式，因此会走 chat-completions 路径。在源代码中，设置带有 apiBase 的 provider: anthropic 也会解析为基础 URL 加 /messages，但 Continue 的 Anthropic 页面没有记录这一覆盖项，本页面也未测试——不要将其视为受支持的路径。

Continue.dev 替代方案：哪一个适合哪类用户

仓库数据来自 GitHub API，于 2026 年 9 月 19 日检查。表中出现了两次收购，而它们不是同一种事件：Continue 的产品已关闭，后端已删除，计费已停止；Kilo 仍在以新名称和新域名发布。star 数和推送日期是发布节奏的证据，不是质量判断；这些客户端均未在本页面进行运行时测试。

Continue.dev 迁移：哪些内容可以迁移，哪些需要重写

Cline 和 opencode 都不会读取 .continue/rules。Cline 的规则文档列出了 .clinerules/、.cursorrules、.windsurfrules 和 AGENTS.md，没有 Continue 条目（2026 年 9 月 18 日检查）；opencode 的规则页面说明了 AGENTS.md（2026 年 9 月 19 日检查）。这是对文档所述文件结构的比较，而不是任何人实际执行过的迁移——没有将真实的 Continue 配置迁移到任一客户端并执行。

安全的顺序是：保持 Continue 安装完全不变，并在开始前将 ~/.continue 复制到其他位置；在旁边部署新客户端，并给它一个边界明确的任务；之后再删除任何内容。由于 Continue 客户端不再依赖后端，保留旧安装不会产生任何成本，而且它就是你的回滚方案。

Continue.dev 的最佳模型，以及一个完整的成本估算示例

Continue 将工作拆分到不同角色中，而 autocomplete 角色的触发频率远高于 chat。资金消耗就在这里，这是上方配置中最值得正确设置的一点。下面的数字是说明性 token 算术，不是实测任务成本，也不是账单上限。假设一次 agent 会话包含 200,000 个未缓存输入 token 和 12,000 个输出 token，一天的 autocomplete 包含 400 次请求，每次平均 2,000 个输入 token 和 50 个输出 token。费率是实时的 Kunavo catalog 每百万 token 价格。

在这些假设下，对于相同的按键输入，仅 autocomplete 一列就会从 $0.630（对应 Claude Haiku 4.5）变为 $1.890（对应 Claude Sonnet 4.6）——这正是角色拆分比醒目的费率更重要的原因。在将其视为预算之前，请按你自己的会话数和编辑天数缩放两列；尤其是 autocomplete 的请求形态只是一个假设，而不是测量结果。

Kunavo 的目录金额是计费下限，而不是上限：当上游报告其费用时，账单取目录成本与上游成本乘以适用加价两者中的较高者。缓存费用和外部工具不包含在此示例中。最低充值金额为$10预付余额——这是资金最低额度，不是任务费用或订阅费用。参见billing details。

接下来

如果你暂时继续使用最终的 Continue 构建版本，Continue integration guide中包含完整配置块。如果你准备迁移，请从 Cline setup或 OpenCode integration开始，并参考 best API for Cline进行 provider 比较。Kunavo 为这些客户端发布了设置指南；已发布的配置参考不是兼容性测试，而且本页面没有针对 Kunavo 端点对其中任何客户端进行运行时测试。准备为 key 充值时，创建 Kunavo 账户，然后运行一个边界明确的任务，并查看账户实际记录的费用。

相关阅读：OpenAI-compatible API介绍协议本身；Cline pricing和 OpenCode pricing介绍两个采用相同“免费客户端、按量计费 API”模式的客户端；如果你考虑投奔收购方，请查看 Cursor alternatives。

常见问题

于 2026 年 9 月 19 日检查的内容包括：continue.dev 及其网站包、GitHub README 和发布版本 API、npm 注册表、VS Code Marketplace 和 Open VSX 的扩展条目、JetBrains 插件 API、docs.continue.dev、hub.continue.dev 和 api.continue.dev 的 DNS 与 HTTP 状态，以及 Cline、opencode、Kilo、Aider、Zed 和 Roo Code 的 GitHub 仓库元数据。Continue 的请求路由以及 hub 和登录功能的移除情况，读取自已发布的 v2.0.0-vscode 标签下的源代码；npm 上的 CLI 仍尝试访问哪些内容，则读取自 v1.5.45 标签下的源代码。Cline 的规则文档于 2026 年 9 月 18 日检查，Anaconda 的 Kilo 收购文章于 2026 年 9 月 21 日检查。没有安装、启动或调用任何内容：本页面没有运行时或兼容性测试。Kunavo 的 token 费率来自实时目录，本页面的所有美元金额都是用于说明的 token 用量计算结果。