Mistral Vibe CLI

.vibe/config.tomlに5行の[[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を案内しています。Mistral の公式サードパーティー向け例では、Mistral 以外のキーにシェルのexportを使っています。
4. 使いたい ID ごとに[[models]]プリセットを追加し、それぞれに固有のaliasを指定します。その後、active_modelをいずれかのエイリアスに設定してください。エイリアスはローカルで使われます。/modelに表示される名前であり、実際にエンドポイントへ送信される ID はnameです。
5. 信頼できるフォルダーでvibeを実行し、あいさつではなくファイルを操作するタスクを与えてください。ファイルを読み込んで編集する初回のターンでツール呼び出しが実行されます。プロバイダーの設定ミスは、通常この段階で明らかになります。

Mistral の Vibe Code CLI 設定ページで2026年9月21日に確認しました。サードパーティの設定は変更されます。ここに記載されたフィールド名が表示内容と一致しなくなった場合は、このページではなく、そのページを正しい情報源としてください。

クライアントをデバッグする前に確認すること

1回のリクエストで、失敗の原因がエンドポイント、キー、設定ファイルのどれかを特定できます。これが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、価格付きのカタログはモデルページにあります。料金は100万トークンあたりのUSDで、入力 / 出力の順です。

すべてのトラフィックがこのプロバイダーに送られるわけではありません

これは設定ブロックからはわからない部分であり、KunavoではなくVibe固有の動作です。v2.25.5では、利用可能なMistralプロバイダーがあると、CLIはバックグラウンドの「ユーティリティ」補完、つまり会話やワークツリーに名前を付ける小さな呼び出しを、Mistral自身のmistral-vibe-cli-fastモデルに送ります。付属のデフォルト設定には常にMistralプロバイダーが1つ設定されており、セッションで使用中のモデルがご自身のモデルであっても、この動作は変わりません。ソースには、優先先とフォールバックの両方が明記されています。利用可能なMistralプロバイダーがない場合、ユーティリティ呼び出しは代わりにセッションで使用中のモデルに送られます。

セッション内のすべてのリクエストを設定したプロバイダーに送信するには、次のいずれかを満たす必要があります。

• MISTRAL_API_KEYを未設定にして、ファストモデルの認証情報が解決されず、ユーティリティ呼び出しがフォールバックするようにする。または
• allowed_modelsによってファストモデルのエイリアスを除外する。キーではなく許可リストによって同じ結果になります。

Smart Approve の分類器はさらに厳格です。2.25.1 の変更履歴によると、セッションのアクティブモデルに関係なく、ファスト Mistral モデルで実行されます。そのため、Kunavo だけを使うセッションは、現実的には Smart Approve ではなくaccept-editsまたはplanで動作します。この動作によって上記の設定が壊れるわけではありません。ただし、プロバイダーブロックが対象とするのはモデルのターンであり、バイナリが送信するすべてのリクエストではありません。

その他の api_style 値

ドキュメントではapi_styleの値を 1 つ示し、例として説明しています。値は"openai"です。v2.25.5 のソースにはさらに 4 つ（"anthropic"、"openai-responses"、"reasoning"、"vertex-anthropic"）がありますが、単純な辞書に登録され、検証はありません。そのため、タイプミスはファイル読み込み時ではなく、リクエスト時に判明します。これらはソースで確認済みですが、ドキュメントには記載されていない値として扱ってください。Anthropic の値を試す場合には注意が必要です。そのアダプターのエンドポイントは/v1/messagesです。そのため、api_baseには末尾に/v1を付けず、https://api.kunavo.comのようにベースのオリジンをそのまま指定します。これは上記のブロックとは逆です。claude-で始まる ID であれば、Kunavo は/v1/messagesに応答します。このページでは、Mistral のドキュメントに記載されているopenaiスタイルを使っています。