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 供應商。呼叫端是背景便利功能，不是你的程式設計回合：工作階段標題、git worktree 名稱、代理程式迴圈與應用程式伺服器執行時環境。同一檔案中記錄了三個替代出口：沒有可用的 Mistral 供應商、allowed_models 允許清單排除別名 mistral-small，或無法解析 MISTRAL_API_KEY。如果你離開的原因是「所有流量都必須抵達同一端點」，請先從這裡開始，再進行遷移——這可能已能在原地解決。

語音功能被鎖定在 Mistral 自有的音訊協定。在該版本中，TranscribeClient 與 TTSClient 是字串 enum，其唯一成員為 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 的設定結構描述會以 enable = True 對 https://experiments.mistral.services/ 設定 ExperimentsConfig，而 enable_telemetry 預設為 True。該層可在執行時提供 routed_default_model、routed_model_config 與 routed_extra_models，並透過兩個實驗旗標控制 Smart Approve 模式；除非推出部署，否則這些旗標會維持關閉。最後這一點為我們自己的 Vibe CLI 與 Claude Code 比較頁面增加了一項注意事項，該頁面描述 Smart Approve 的分類器在快速 Mistral 模型上執行：在 2.25.5 中，兩個旗標預設都為關閉，且該模式會隱藏，直到部署公開它，因此只有在 Smart Approve 實際提供給你後，該路由才會抵達你。上述工具模型路由對標題與 worktree 名稱仍然成立。

節奏快到足以破壞可正常運作的設定。 2.25.5 的變更記錄記載了一項修正：對於未設定 API 金鑰環境變數的提供者——本機或自行託管的模型伺服器——這些提供者「會再次在 Unified Harness 上執行，而不是每一回合都因缺少 MISTRAL_API_KEY 而失敗」。這表示無金鑰的本機提供者至少曾在較早的一個版本中於 Unified Harness 上失敗；變更記錄未說明從哪個版本開始，因此請對照你安裝的版本檢查。同一版本移除了該 harness 的「experimental」標籤，並將 --legacy-harness 指定為替代方案；2.25.4 則列出 shell 權限檢查中修正的五個 CVE 識別碼（識別碼依變更記錄原樣列出，未另行對照 CVE 資料庫）。你撰寫的任何 runbook 都應固定版本。

哪個替代方案符合哪種離開理由

儲存庫、版本發布與市集數據於 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，則可保留你的設定與金鑰檔案。

切換對帳單的影響

基本上沒有，這正是重點：在自帶金鑰的路徑上，用戶端是自由軟體，而模型決定費用。這些數字是說明性的 token 算術，不是實際測量的任務成本，也不是帳單上限。假設一個工作階段傳送200,000 個未快取輸入 token，並接收12,000 個輸出 token。第一列是 Mistral 自行發布的 Vibe CLI 預設模型價格，僅供比較——Kunavo 不銷售 Mistral 模型。其餘是每百萬 token 計算的即時 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 日：mistral-vibe、opencode、goose、OpenHands、Roo-Code、crush、codex、cline 與 kilocode 的 GitHub API；mistral-vibe 2.25.5 的 PyPI；上文所列的 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 執行，因此本文不是相容性測試，所有美元金額都是說明性的 token 算術，而非實際測量的任務成本。