Open Interpreter を、カスタムの OpenAI 互換エンドポイントで動かす。

早わかり: api_base と openai/ モデルプレフィックス。

Open Interpreter は、両方のインターフェースでカスタムエンドポイントの経路をドキュメント化しています。CLI では --api_base にエンドポイントを、--model に openai/ プレフィックス付きの id を渡します。Python では、chat() を呼ぶ前に interpreter.llm.api_base、interpreter.llm.api_key、interpreter.llm.model を設定します。 このプレフィックスは飾りではありません。Open Interpreter は LiteLLM の上で動いており、LiteLLM はモデル文字列からどのプロバイダークライアントを使うか決定します。openai/claude-sonnet-4-6 は「api_base が指す先に対して、モデル claude-sonnet-4-6 で OpenAI チャット補完のプロトコルを話せ」という意味です。プレフィックスを外すと、LiteLLM は代わりに裸の名前からプロバイダーを推測し、claude-* の id を Anthropic のクライアントに向け、あなたが設定したエンドポイントを無視します。

export OPENAI_API_KEY=sk-APIsRouter-...

interpreter \
  --api_base https://api.apisrouter.com/v1 \
  --model openai/claude-sonnet-4-6

Open Interpreter が、モデルで何をするか。

Open Interpreter(GitHub 上では openinterpreter、スター数はおよそ66K)は、あなたのマシン上のコードインタープリターを言語モデルに与えます。自然言語で目標を述べると、モデルが Python やシェルを書き、Open Interpreter がそれをローカルで実行し、その出力が次のステップのために会話へフィードバックされます。そのループが、チャットクライアントとは質的に異なるものにしています。モデルは文章を生成しているのではなく、あなたのユーザー権限で実行されるコードを生成しており、あなたの実システムからの実際のエラーに対して反復します。 これはルーティングに2つの帰結をもたらします。第一に、モデルの品質は直接的に安全性と正しさの特性です。フラグを幻覚したり、トレースバックを読み違えたりするモデルは、もう1往復の失敗を生み、自動実行モードではそれをレビューしないまま生み出してしまいます。第二に、このループは特定の意味でトークンを大食いします。各ターンは、増え続ける会話・コード・キャプチャされた出力を再送信するため、長いデバッグセッションは急速に文脈を積み重ねます。 api_base の設定は、このループ全体を1つのエンドポイントに移動させます。openai/ プレフィックスの後の model フィールドはそのままの文字列として渡されるため、Claude の id、GPT の id、DeepSeek の id は、別々のプロバイダー設定ではなく、相互に入れ替え可能な1フラグの選択肢になります。

フルセットアップ: Python API とプロファイル。

Python の経路は、interpreter.llm に同じ3つの値を設定し、LiteLLM がカスタム id について発見できない2つの設定、context_window と max_tokens を追加します。Open Interpreter は context_window を使って、切り詰める前にどれだけ会話履歴を保持するか決めるため、20万トークン級のモデルでこれを未設定やデフォルトのままにしておくと、必要以上に早く切り詰めが起こります。モデルが実際にサポートする値を宣言してください。 永続的なセットアップのためには、同じキーが llm: ブロックの下のプロファイル YAML に存在します(interpreter --profiles でプロファイルのディレクトリを開きます)。プロファイルは、エンドポイント・モデル・window の設定をシェル履歴の外に保ち、キーは環境変数から供給されたまま、設定をマシン間で共有可能にします。

import os
from interpreter import interpreter

interpreter.llm.api_base = "https://api.apisrouter.com/v1"
interpreter.llm.api_key = os.environ["APISROUTER_API_KEY"]
interpreter.llm.model = "openai/claude-sonnet-4-6"

# LiteLLM cannot infer these for a custom id; declare them:
interpreter.llm.context_window = 200000
interpreter.llm.max_tokens = 8192
interpreter.llm.supports_functions = True

interpreter.chat("Profile data.csv and plot the top 10 rows by revenue.")

あなたのコードを書くモデルを選ぶ。

ここでのモデル比較は珍しく具体的です。2つのモデルに同じタスクを与え、動作する結果に至るまでの往復回数を数えてください。キーごとの利用状況ビューが、セッションあたりのトークンコストを加え、往復回数と合わせてそれが比較のすべてになります。1つのエンドポイントの裏では、各候補は1つのフラグです。

• メインループは、実行可能なコードを書き、最初のパスでトレースバックをうまく読むモデルを求めます。claude-sonnet-4-6 と gpt-5.5 が頼れる中庸であり、より良いモデルが避けてくれる往復1回1回が、節約されたトークンと実時間です。
• deepseek-v4-pro は、ボリュームが重要なコード中心のセッションにおける強力な候補です。1つのエンドポイントの裏では、あなたの実タスクに対してそれを試すのは1回の --model の変更で済みます。
• クイックなユーティリティセッション(ファイルのリネーム、1回限りの変換、フォーマット変換)にはフロンティア級の推論は不要です。claude-haiku-4-5-20251001 や glm-5.2 が速く安価に保ちます。
• 自動実行モード(-y)は、コード生成と実行の間の人間によるレビューステップを取り除きます。少しでも使うなら、あなたが走らせる最も強力なモデルで、サンドボックスかコンテナの中で使ってください。まだ評価中のモデルでは絶対に使わないでください。

従量課金 · 公式価格より安い

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Open Interpreter に特有の失敗パターン。

裸のモデル id はあなたのエンドポイントを迂回します。openai/ プレフィックスなしでは、LiteLLM は名前からプロバイダーを解決します。claude-* の id は Anthropic のクライアントに向かい、結果として、設定した覚えのないホストに対する認証やルーティングのエラーになります。エラーがあなたのゲートウェイではなくベンダーの SDK に言及している場合、プレフィックスが欠けています。 デフォルトの文脈の想定が、あなたのセッションを切り詰めます。LiteLLM が認識しない id については、何も文脈ウィンドウを埋めてくれません。Open Interpreter は控えめな挙動にフォールバックし、履歴を早めに切り詰めます。context_window を明示的に宣言してください。コードのデバッグセッションが以前の試みを失うと、同じ間違いを繰り返してしまいます。 セッションが育つほど、請求額も育ちます。各ターンは会話・コード・キャプチャされた出力を再送信します。大きなデータフレームや長いログをループに貼り付けるセッションは、それを以降のすべてのリクエストで運びます。ファイルの中身をチャットに貼り付けるのではなく、モデルにファイルを検査させるコードを書かせることを優先し、タスクが変わったら新しいセッションを始めてください。 Function-calling の不一致。Open Interpreter は、対応している場合は構造化された function call を使えます。supports_functions のフラグは、検出が間違って推測してしまう id のために存在します。能力があるとわかっているモデルでコードブロックが不正な形式で届く場合は、明示的に True に設定してください。あるモデルが本当にツール対応を欠く場合は False に設定し、フォールバックの経路が動くようにしてください。 実行側はあなたの責任です。api_base はモデルのトラフィックを移動させますが、コードは依然としてあなたの権限でローカルに実行されます。ゲートウェイは何もサンドボックス化しないため、自動実行はコンテナに限定し、それ以外の場所では安全レビューをループに残しておいてください。

ゲートウェイ経由で Open Interpreter を使うのは誰か。

• Open Interpreter を日常の自動化ツールとして使う開発者で、Claude 品質のコード生成、GPT の多様性、速いユーティリティ id を1つのキーの裏でまとめて使いたい人。
• 探索的な分析ループを実行するデータ担当者で、セッションが驚くほど文脈を消費することがあり、キーごとの利用状況がノートブック相当あたりのコストを可視化してくれる人。
• コードを書くモデルを、動作する結果までの往復回数という最も誠実なベンチマークで比較するエンジニアで、候補ごとに1つの --model フラグで済む人。
• スケジュールされた、あるいはコンテナ化された interpreter のジョブを実行するタインカラーで、環境変数のエンドポイントと1つのシークレットが、ベンダーごとの認証情報セットに勝る場合。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

エンドポイントを検証し、最初のセッションをデバッグする。

まずゲートウェイのモデルを一覧してください。openai/ の後ろの id は、バージョンサフィックスも含めて、提供されている id と正確に一致していなければなりません。 最初のセッションの失敗にはパターンがあります。anthropic や別のベンダー SDK を名指しするエラーは、openai/ プレフィックスが欠けており、LiteLLM が名前でルーティングしたことを意味します。401 は、interpreter を起動したシェルでキーが見えていないか、使われているものとは別の変数に設定されていることを意味します。プレフィックスさえ付いていれば、OPENAI_API_KEY でも明示的な api_key でもどちらでも動作します。model-not-found エラーは id のタイプミスです。接続エラーは、通常 api_base が /v1 のサフィックスを失っていることを意味します。クライアントは与えられたベースに /chat/completions を付加するからです。 ループが動き始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。インタープリターのセッションは、小さく感じても中程度の請求になる典型例であり、利用状況ビューが、どのセッションが実際にトークンを運んでいたかを見る方法です。

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

よくある質問