Mistral Vibe CLI

在 .vibe/config.toml 中設定五行 [[providers]] 區塊 — api_base、api_key_env_var、api_style — 將 Vibe CLI 指向 Kunavo，金鑰存於環境變數而非檔案。

# ./.vibe/config.toml (project) or ~/.vibe/config.toml (user).
# "Project-level configuration takes precedence over user-level
# configuration", and the project file loads only in a trusted folder.
active_model = "sonnet-kunavo"

[[providers]]
name = "kunavo"
api_base = "https://api.kunavo.com/v1"
api_key_env_var = "KUNAVO_API_KEY"
api_style = "openai"
backend = "generic"

[[models]]
name = "claude-sonnet-5"
provider = "kunavo"
alias = "sonnet-kunavo"
# Optional, and documented on the api-keys-profiles page:
#   temperature   sampling temperature
#   input_price   indicative per-input cost, fed to --max-price
#   output_price  indicative per-output cost, fed to --max-price
# Take the two prices from the table further down this page if you want
# --max-price to mean anything.

# The key never goes in config.toml. api_key_env_var names the variable:
#   export KUNAVO_API_KEY="sk-kn-..."

逐步操作

1. 在 /app/keys 建立金鑰並複製——金鑰只會顯示一次。
2. 開啟 ~/.vibe/config.toml（或在要套用此設定的儲存庫中建立 ./.vibe/config.toml），然後貼上上方區塊。沒有可供點選的新增供應商流程：Mistral 說明此檔案需手動編輯，而 /config 和 /model 只能在既有的預設設定之間切換。
3. 匯出你在 api_key_env_var 中指定的變數：export KUNAVO_API_KEY="sk-kn-..."。Mistral 的憑證頁面指出，CLI 啟動時會載入 ~/.vibe/.env 以取得憑證；其第三方範例也使用 shell export 來設定非 Mistral 金鑰。
4. 針對每個想使用的 ID 新增一個 [[models]] 預設設定，各自設定 alias，再將 active_model 指向其中一個別名。別名僅在本機使用：/model 會列出別名，而真正傳送至端點的是 name 中的 ID。
5. 在信任的資料夾中執行 vibe，並交付一項會操作檔案的任務，而不是打招呼。首次執行時讀取並編輯檔案，可測試工具呼叫；供應商設定錯誤通常會在此處顯現。

已於 2026年9月21日 根據 Mistral 的 Vibe Code CLI 設定頁面 進行確認。第三方設定會變動；如果這裡的欄位名稱不再與你看到的內容相符，應以該頁面為準，而不是本頁。

除錯用戶端前先驗證

一個請求就能判斷失敗原因是端點、金鑰還是設定檔。如果這裡回傳 JSON，則相同的基礎 URL 與金鑰在 Mistral Vibe CLI 中也能運作。

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

欄位中應填入哪個模型 ID

每個文字模型都能以模型 ID 存取——即時清單位於 GET /v1/models，帶有價格的目錄位於模型頁面。費率是每 1M 權杖的美元價格，輸入／輸出。

並非所有流量都會傳送至此供應商

設定區塊無法告訴您的部分就在這裡，而且這是 Vibe 特有的行為，與 Kunavo 無關。在 v2.25.5 中，只要 Mistral 供應商可用，CLI 就會將背景「utility」補全呼叫 — 用來命名對話和工作樹的小型呼叫 — 路由至 Mistral 自己的 mistral-vibe-cli-fast 模型；隨附的預設設定一律會設定該模型，即使工作階段目前使用的是您的模型 也一樣。原始碼明確說明了此優先順序和備援方式：若沒有可用的 Mistral 供應商，utility 呼叫就會改用工作階段目前使用的模型。

因此，若要讓工作階段中的每個請求都傳送至你設定的供應商，以下條件必須成立其中之一：

• MISTRAL_API_KEY 未設定，因此無法解析快速模型的憑證，utility 呼叫便會改用備援模型；或
• 透過 allowed_models 排除快速模型的別名，達到相同效果；此時是由允許清單排除，而非金鑰造成。

Smart Approve 分類器的限制更嚴格；其 2.25.1 版變更記錄指出，無論工作階段目前使用哪個模型，它都會使用 Mistral 快速模型。因此，實際上僅使用 Kunavo 的工作階段會採用 accept-edits 或 plan，而非 Smart Approve。這不會影響上述設定；這只表示供應商區塊設定的是你的模型回合，而非二進位檔傳送的每個封包。

其他 api_style 值

文件列出 api_style 的一個值，並以範例方式說明："openai"。v2.25.5 原始碼還有四個值："anthropic"、"openai-responses"、"reasoning" 和 "vertex-anthropic"；它們位於一般字典中，沒有驗證，因此拼字錯誤會在請求送出時才顯現，而非在載入檔案時發現。這些值已由原始碼確認，但文件未提及；若嘗試使用 Anthropic 風格，還有一個容易踩到的陷阱：其轉接器的端點是 /v1/messages，因此 api_base 必須使用不帶 /v1 的純來源網址 https://api.kunavo.com，與上方區塊相反。Kunavo 確實支援 /v1/messages，適用於以 claude- 開頭的 ID。本頁展示 openai 風格，因為這是 Mistral 文件中列出的設定。