Mistral Vibe 替代方案：按工作流与 API 控制选择

关于 Mistral Vibe 替代方案，诚实的起点是：Vibe CLI 不会消失——mistralai/mistral-vibe 采用 Apache-2.0 许可，未归档，于 2026 年 9 月 18 日发布 v2.25.5，并于 2026 年 9 月 21 日最后一次推送。人们因为四个具体原因替换它——后台调用仍会到达 Mistral、语音功能没有第三方路径、默认值可以远程更改，以及快到足以破坏正常配置的发布节奏——而每个原因都指向不同的替代品。本页面提供选择树，以及切换在文件层面实际会付出什么代价。

先澄清一个决定哪些价格真正相关的问题。Mistral 于 2026 年 5 月 28 日将 Le Chat 更名为 Vibe：“Le Chat 现在是 Vibe”，一个代理和一个许可，覆盖工作与代码。因此，“Mistral Vibe”现在同时指代消费者助手和编程代理；你以该名称找到的每个订阅价格，购买的都是助手。CLI 是 mistral-vibe 软件包，采用 Apache-2.0 许可，价格为 $0。第三款产品 Mistral Code Enterprise 是一个独立的已弃用插件：“弃用，推荐使用 Mistral Vibe”，可运行至 2027 年 3 月，仅限企业许可。还有两个值得说明的同名项：vibe.us 销售会议室协作硬件，而 Replit、Bolt 和 Lovable 的“vibe coding”汇总讨论的是一种方法论，并不是替代终端代理。

人们为什么离开 Vibe CLI

并非每个请求都会发送到你声明的提供商。在 v2.25.5 中，实用程序补全模块定义了一个快速 Mistral 模型 mistral-vibe-cli-fast，其文档字符串说明，只要 Mistral 提供商可用，即使会话的活动提供商是其他提供商，也会优先使用它；内置默认配置始终会配置一个 Mistral 提供商。同一文件中记录了三个退出路径：没有可用的 Mistral 提供商、allowed_models 允许列表排除了别名 mistral-small，或者无法解析 MISTRAL_API_KEY。如果你离开的原因是“所有流量都必须到达一个端点”，请先从这里着手再迁移——问题可能已经可以在原处解决。

语音功能被锁定为 Mistral 自有的音频协议。在该版本中，TranscribeClient 和 TTSClient 是字符串枚举，唯一成员都是 Mistral；随附的默认配置指向 wss://api.mistral.ai 和 https://api.mistral.ai，两者都使用 MISTRAL_API_KEY 作为密钥。[[transcribe_providers]] 或 [[tts_providers]] 块确实允许你更改 api_base 和密钥变量，但无法更改 client，因此无论你将其指向何处，该端点仍必须支持 Mistral 自有的音频 API。Kunavo 同样不提供语音转文本、文本转语音或嵌入模型，因此切换客户端或网关并不能解决语音需求——这一步需要选择提供该功能的提供商，本页面不会对此作出虚假承诺。

某些默认值由远程设置。2.25.5 的配置架构将 ExperimentsConfig 与针对 https://experiments.mistral.services/ 的 enable = True 一同发布，且 enable_telemetry 默认为 True。该层可以在运行时提供 routed_default_model、routed_model_config 和 routed_extra_models，并通过两个实验标志控制 Smart Approve 模式；除非发布逐步启用，否则这两个标志会保持关闭。最后一点为我们自己的 Vibe CLI 与 Claude Code 对比页面增加了一个注意事项，该页面描述了在快速 Mistral 模型上运行的 Smart Approve 分类器：在 2.25.5 中，两个标志默认都关闭，并且在发布启用之前该模式处于隐藏状态，因此只有在 Smart Approve 实际提供给你后，该路由才会触达你。上文关于实用程序模型的路由仍适用于标题和工作树名称。

节奏快到足以破坏正常运行的配置。 2.25.5 的变更日志记录了一项修复：对于未配置 API 密钥环境变量的提供商——本地或自托管模型服务器——“会再次在 Unified Harness 上运行，而不是每一轮都因缺少 MISTRAL_API_KEY 而失败”。这意味着，无密钥的本地提供商至少在更早的某个版本中曾在 Unified Harness 上失败；变更日志没有说明始于哪个版本，因此请将其与您安装的版本核对。同一版本移除了该 harness 的“experimental”标签，并将 --legacy-harness 列为退出方案；2.25.4 则列出了 shell 权限检查中修复的五个 CVE 标识符（这些标识符按变更日志中的原样列出，未另行与 CVE 数据库核对）。请在您编写的任何运行手册中固定版本。

哪种替代方案对应哪种退出原因

仓库、版本和市场数据于 2026 年 9 月 21 日从 GitHub API、PyPI、Visual Studio Marketplace 以及各项目自己的文档中读取。其中三个项目现在由不同于大多数指南仍印出的 URL 所属者的其他所有者负责。GitHub 重定向证明了新的所有者，但没有找到其中任何项目的带日期公告，因此应将其理解为记录中的更名，而不是收购。第一行还有一个限制：检查的是各项目的自定义提供商配置，而不是其后台流量，因此如果“每次调用都到达我的端点”才是真正要求，请在您自己的设置中通过代理日志确认。更深入的比较见 OpenCode 替代方案、Aider 替代方案 和 Crush 与 OpenCode 对比。

选择之前先检查线路

这是功能表遗漏的部分，也是决定您现有密钥是否能正常工作的因素。每个客户端对自定义端点接受的协议集合不同，其中一个会拒绝大多数网关提供的格式。

三个每个都可能耗费一下午的细节。对于 Vibe 的 OpenAI 形式样式，api_base 必须是 /v1 根路径，因为 OpenAI 适配器会自行追加 /chat/completions；而 anthropic 适配器会追加 /v1/messages，因此它需要主机根路径。Crush 的配置发生了变化：在 v0.96.1 中，crushrc 是文档记录的添加提供商位置，而 crush.json 仍位于 $HOME/.local/share/crush/ 下，因此将提供商添加到 JSON 文件的教程描述的是较旧的格式；README 还警告这两个文件都是受信任的代码，因为 crushrc 会在完整 shell 中运行。Codex CLI 的门槛则会提前终止迁移：在此版本中，chat-completions 密钥不是 Codex CLI 提供商。

对于最常见的迁移——从 Vibe CLI 转到 OpenCode，同时保留一个密钥——目标端的声明是一个文件，而不是向导：

{
  "provider": {
    "kunavo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Kunavo",
      "options": {
        "baseURL": "https://api.kunavo.com/v1",
        "apiKey": "{env:KUNAVO_API_KEY}"
      },
      "models": {
        "claude-sonnet-4-6": { "name": "Claude Sonnet 4.6" }
      }
    }
  }
}

Crush 的对应方式是一行 crushrc——provider add kunavo --type openai-compat --base-url "https://api.kunavo.com/v1" --api-key "$KUNAVO_API_KEY"——随后为您希望列出的每个模型添加一个 model add，这正是 README 自带的自定义提供商示例所采用的格式。两者都是从各项目自己的文档中读取的已发布配置格式，而不是运行时测试结果：Kunavo 未让任一客户端连接其端点运行。设置参考见 OpenCode 集成、Crush 集成 和 Mistral Vibe 集成。

哪些内容会迁移、哪些不会，以及如何回滚

以文件副本的形式迁移： AGENTS.md。Vibe CLI 2.25.5 定义了 AGENTS_MD_FILENAME = "AGENTS.md"，OpenCode 的文档告诉您将项目的 AGENTS.md 提交到 Git，而 Crush v0.96.1 会读取 ~/.config/AGENTS.md 并提供 initialize-as AGENTS.md 选项。文件名相同，因此这一部分可移植——但每个客户端对内容的解释方式不同，所以请在新工具中阅读一次，不要假设行为完全相同。

不会迁移：工具、技能、插件和子代理。Vibe 将这些内容保存在项目的 .vibe/ 目录中，其中包含 tools/、skills/、plugins/ 和 agents/ 子目录，以及一个 .agents/skills 目录；全局对应项位于 ~/.vibe 下。这里没有其他客户端读取该布局，因此请预留手动重新声明它们的时间。密钥也不会迁移：Vibe 的设置流程会将它们写入 ~/.vibe/.env，环境变量优先，而每个目标客户端使用各自命名的变量。

历史记录完全不会迁移。 Vibe 会话是 ~/.vibe/logs/session 下的本地文件——每个会话包含一个 .session_index.json，随后是 meta.json 和 messages.jsonl。2.25.5 wheel 提供三个控制台脚本（vibe、vibe-acp、vibe-app-server），并公开 --continue 和 --resume；其中没有找到导出命令。自 2.25.5 起，在非 Windows 系统上，该目录仅所有者可访问。请保留它，而不要计划导入它。

按以下顺序进行迁移，不会让您陷入困境：将 AGENTS.md 复制到新客户端的项目根目录；根据上表中的协议，在该客户端自己的文件中声明提供商；导出它指定的密钥变量；在两个客户端中分别运行一个有界任务——先进行单文件编辑，再进行跨多个文件的调查；读取您的提供商账户为每次运行记录的内容。开始前先设置回滚：Vibe CLI 是普通的 Python 软件包，因此重新安装您之前使用的版本（uv tool install mistral-vibe==2.25.5）即可恢复客户端；试用期间保持 ~/.vibe 不变，则可保留您的配置和密钥文件。

切换对账单的影响

基本没有，这正是关键：在自带密钥的路径上，客户端是免费软件，账单由模型决定。这些数字是用于说明的令牌算术，不是实测任务成本，也不是账单上限。假设一次会话发送 200,000 个未缓存输入令牌，并接收 12,000 个输出令牌。第一行是 Mistral 为 Vibe CLI 默认模型公布的费率，仅用于比较——Kunavo 不销售 Mistral 模型。其余是Kunavo 目录按每百万令牌计的实时费率。

Mistral 的数据于 2026 年 9 月 21 日从其 API 价格表读取，而 Vibe 随附的配置为 mistral-vibe-cli-latest 声明了相同的两个数字。表格无法告诉您的内容是：列出的最低费率与完成任务的最低成本是两种不同的说法；一个需要三次尝试的模型，成本可能高于一次完成任务的更昂贵模型。在将这些数字视为预算之前，请根据您每天的会话数进行换算。

Kunavo 的目录价格是计费下限，而非上限：上游报告其收费金额后，账单金额取目录费用与上游费用乘以适用加价系数这两者中的较高值。缓存费用和外部工具费用不包含在此示例中。最低充值金额为 $10 的预付额度，充值用于增加账户余额，而非购买套餐——请参阅计费详情。无论您最终选择哪款客户端，当您准备为密钥充值时，请创建 Kunavo 账户。

还在决定是继续使用还是迁移？Mistral Vibe 与 Claude Code 对比介绍如何保留 CLI 并将其指向其他位置，适用于 OpenCode 的最佳 API讨论最常见落点上的提供商问题，而如果终端不是限制条件，Claude Code 替代方案会扩大选择范围。

常见问题

检查于 2026 年 9 月 21 日：GitHub API 中的 mistral-vibe、opencode、goose、OpenHands、Roo-Code、crush、codex、cline 和 kilocode；PyPI 上的 mistral-vibe 2.25.5；上文所列的 Visual Studio Marketplace 和 JetBrains Marketplace 条目；v2.25.5 wheel 的源代码、变更日志和 README；docs.mistral.ai 的 CLI 配置和 API 密钥页面；mistral.ai/pricing、mistral.ai/pricing/api 以及 Vibe 更名公告；opencode.ai、goose-docs.ai、roomote.dev、Crush v0.96.1 README 和 OpenAI 的 Codex 配置参考。没有安装任何客户端，也没有让其连接 Kunavo 运行，因此本文不构成兼容性测试，所有金额均为说明性的令牌算术，而非实测任务成本。