ドキュメント

ドキュメント

Open Interpreter

Open Interpreterは、前身であるCodexと同様にTOMLテーブルからプロバイダーを読み込みます。ただし、上流のCodexで削除されたChat Completions通信方式は引き続き利用できます。[model_providers.kunavo]ブロックを1つ追加すれば、キーで到達できる任意のモデル上でエージェントを実行できます。

~/.openinterpreter/config.tomlに[model_providers.kunavo]テーブルを1つ追加 — base_url、env_key、wire_api = "chat" — これでRustターミナルエージェントはキーが利用できる任意のモデルで動作します。

~/.openinterpreter/config.toml
model_provider = "kunavo"
model = "claude-sonnet-5"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"     # the NAME of the variable, not the key
wire_api = "chat"
ベースURLは、chatでの通信時にも/v1サフィックスを保持します。Open Interpreterのドキュメントでは、明示的な規則ではなく、例によってこの点が示されています。プロバイダーページのカスタムプロバイダーのブロックではbase_url = "https://api.example.com/v1"、設定ページの同じブロックでは"https://api.acme.example/v1"、名前を明記して紹介されているホスト型ゲートウェイでは"https://app.nz/v1"が使用されています。サフィックスを削除すると、認証エラーではなく404エラーが発生します。
Kunavoでは、Open Interpreterをこのエンドポイントで実行していません。このページで紹介しているほかのクライアントでも同様です。確認したのは設定項目です。以下のキー名は、このページの下部に記載された日付時点で参照したOpen Interpreter独自のドキュメントに記載されているものです。ベースURLとモデルIDはKunavoのものです。設定ページが公開されていても、実行してテストしたことにはなりません。実際に動作するかどうかは、検証リクエストで確認してください。
「Open Interpreter」という名前のプログラムは2つあり、このブロックはRust版を対象としています。 0.4.3で固定されたPythonパッケージは、--api_base、--api_key、--model openai/<id>、またはPython内のinterpreter.llmを通じて設定します。現在のターミナルエージェントにはこれらのいずれも存在せず、上記のTOMLテーブルのみを読み込みます。何かを編集する前にinterpreter --versionを実行してください。古いチュートリアルにあるpip install open-interpreterを実行すると、同じ名前を取り合う2つ目のバイナリが残ります。
ClaudeのモデルIDを指定すると、Open Interpreterは自動的にclaude-codeハーネスを選択します。文書化されたデフォルトでは、「Anthropic、ClaudeのモデルID、AnthropicのベースURL、またはいずれかのmessagesプロバイダー」の場合に選択されます。ここでこの組み合わせは問題ありません。ルーティングテーブルでは、claude-codeがwire_api = "chat"と互換性ありとされています。別のハーネスを使う場合はharnessを明示的に設定してください。明示した値が常に優先され、認識されない値の場合は、エラーを明示せず、組み込みのリクエストビルダーなしでチャットにフォールバックします。
まだキーをお持ちですか?Kunavoアカウントを作成し、キーを作成します(sk-kn-で始まります)。$10からクレジットを追加すると、呼び出しはその残高から支払われ、失敗した呼び出しは課金されません。ダッシュボードを開くと、Open Interpreter設定が表示されます。

手順

  1. /app/keys でキーを作成してコピーします。キーは一度だけ表示されます。
  2. env_keyに設定する名前で環境変数としてエクスポートします。export KUNAVO_API_KEY=sk-kn-...。このフィールドに入れるのは変数の値ではなく名前です。ドキュメントでは、env_keyは「環境変数からベアラートークンを読み取る」ソースとして記載されています。
  3. 上記のブロックを~/.openinterpreter/config.tomlに記述してください。または、信頼できるプロジェクト内の.openinterpreter/config.tomlに記述すると、そのリポジトリだけに適用されます。プロジェクト設定はユーザー設定より優先され、その実行に限っては-c key=valueフラグが両方より優先されます。
  4. interpreterを起動して/modelを実行します。ピッカーはまずアクティブなプロバイダーのmodelsルートに問い合わせます。KunavoはGET /v1/modelsを返すため、一覧が自動的に表示されます。
  5. 誤った値が使われている場合は/debug-configを実行してください。有効な設定と各値の取得元が表示されるため、古いプロファイルやプロジェクトファイルを素早く特定できます。TOMLを読み直すよりも手早く確認できます。

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

これが短い概要です。完全な手順 — モデルの選択、実際のセッション費用、失敗するケース — はOpen Interpreterのバージョンの違い、料金、代替製品にあります。

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

1回のリクエストで、失敗の原因がエンドポイント、キー、設定ファイルのどれかを特定できます。これがJSONを返すなら、同じベースURLとキーがOpen Interpreterで機能します。

# 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で、入力 / 出力の順です。

モデル IDKunavo 入力 / 出力Open Interpreterでの位置付け
claude-sonnet-5$1.40 / $7.00編集と実行を繰り返す際の標準作業モデル
claude-opus-5$3.50 / $17.50誤った計画が大きなコストにつながる、大規模なリファクタリングの計画
claude-haiku-4-5$0.70 / $3.50ターン数が支配的な、シェル中心のセッション
gpt-5-6-sol$2.00 / $12.00同じキーを使い、異なるモデルファミリーから得るセカンドオピニオン
請求は月額料金なしの前払い残高からトークン単位で行われます — 請求を参照してください。繰り返し送られるコンテキスト(エディターやチャットクライアントが送る内容の大半)では、プロンプトキャッシュのほうがモデル選択より請求額を大きく左右します。

よくある質問

Open InterpreterをカスタムAPIプロバイダーに接続するにはどうすればよいですか?

~/.openinterpreter/config.tomlに[model_providers.<id>]テーブルを追加し、name、base_url、env_key、wire_apiを指定します。次に、最上位のmodel_providerキーでそのプロバイダーを選択し、modelでモデルを指定します。OpenAI互換エンドポイントの場合は、wire_api = "chat"を設定し、/v1で終わるベースURLを指定します。これは、Open Interpreter自身のプロバイダーページにあるカスタムプロバイダーと、名前を挙げて説明されているホステッドゲートウェイの例と同じ形式です。env_keyには環境変数の名前を指定するため、キーをファイルに貼り付けず、環境変数としてエクスポートしてください。

Open Interpreterのbase_urlは末尾に/v1が必要ですか?

chatワイヤーの場合は必要です。ドキュメントではパスの構成規則を文章で説明していませんが、掲載されているカスタムプロバイダーの例はいずれも接尾辞が付いています。プロバイダーページではhttps://api.example.com/v1、設定ページではhttps://api.acme.example/v1、名前を挙げているゲートウェイではhttps://app.nz/v1です。messagesワイヤーは挙動が異なり、クライアントに同梱されているAnthropic形式のプロバイダーでは、/v1のないAPIルートを使います。したがって、/v1が必要という回答はwire_api = "chat"とwire_api = "responses"に固有です。

以前の--api_baseと--model openai/...フラグはまだ使えますか?

いいえ。これらは0.4.3で更新が止まったPythonパッケージ用の設定です。LiteLLM経由でルーティングしていたため、openai/プレフィックスが必要でした。現行のターミナルエージェントはCodexのRustフォークで、これらのフラグもプレフィックスの規則もありません。~/.openinterpreter/config.tomlまたはプロジェクトレベルの.openinterpreter/config.tomlからTOMLのプロバイダーテーブルを読み込み、model_providerとmodelで選択します。設定は一から書き直されており、docs.openinterpreter.comはRust版のドキュメントにリダイレクトされます。そのため古いチュートリアルのリンクは引き続き開けても、インストールされていないプログラムについて説明している場合があります。

カスタムプロバイダーの場合、/modelピッカーにコンテキストウィンドウが表示されないのはなぜですか?

このメタデータは、models.devといくつかの稼働中のプロバイダーエンドポイントから生成され、クライアントに同梱されているカタログに由来します。プロバイダーがAnthropicとしての識別情報、ベースURL、プロバイダー名、または認証用環境変数によってカタログ項目と一致した場合にのみ、その情報が初期設定されます。Kunavoはこの生成カタログに含まれていません(2026年9月21日時点でリポジトリ内のファイルを確認済み)。そのため、手動で設定したプロバイダーはエンドポイント独自のmodelsルートからモデル一覧を取得するだけです。モデル自体は動作しますが、ピッカーに表示できる情報が少なくなります。

Anthropicアカウントがなくても、Open InterpreterからClaudeモデルを利用できますか?

はい。wire_apiはベンダーではなく、通信方式を指定するためです。wire_api = "chat"の場合、モデルIDは設定したbase_urlにそのまま渡され、そこで解決されるため、必要な認証情報はエンドポイントのものです。ClaudeのモデルIDを指定するとOpen Interpreterは引き続きclaude-codeハーネスを自動選択します。このハーネスはchatワイヤーと互換性ありと記載されているため、この組み合わせは回避策ではなく、文書化されたものです。