Zed に、カスタムの OpenAI 互換プロバイダーを追加する。

早わかり: settings.json に1ブロック。

Zed はカスタムの OpenAI 互換プロバイダーにネイティブ対応しています。settings.json の language_models.openai_compatible の下にプロバイダーエントリを追加し、api_url を https://api.apisrouter.com/v1 に設定し、使いたい各モデルを available_models の下に名前とコンテキストサイズとともに宣言します。モデルはすぐにエージェントパネルのモデルドロップダウンに現れます。 API キーは意図的に settings.json には書きません。プロバイダー設定の UI から入力するとシステムのキーチェーンに保存されるか、あるいはあなたのプロバイダー名から導かれる環境変数から読み込まれます。apisrouter という名前のプロバイダーなら APISROUTER_API_KEY を読みます。環境変数はキーチェーンの値より優先されます。

{
  "language_models": {
    "openai_compatible": {
      "apisrouter": {
        "api_url": "https://api.apisrouter.com/v1",
        "available_models": [
          {
            "name": "claude-sonnet-4-6",
            "display_name": "Claude Sonnet 4.6",
            "max_tokens": 200000
          }
        ]
      }
    }
  }
}

Zed がカスタムプロバイダーとモデルをどう解決するか。

Zed(GitHub 上では zed-industries、スター数はおよそ87K)は、計画を立て、ファイルを編集し、ツールを実行するエージェントパネルを備えた高性能エディターです。その openai_compatible というプロバイダータイプは標準の /v1/chat/completions プロトコルを話し、これはまさにマルチベンダーのゲートウェイが提供しているものなので、エディターとエンドポイントの間にプラグインや拡張機能を挟む必要はありません。 選んだプロバイダーキー(上の例では "apisrouter")は二重の役割を担います。エージェントパネルの設定でプロバイダー名として使われるのと同時に、Zed がキーを探す環境変数名も生成します。大文字のスネークケースにして末尾に _API_KEY を付けたものです。この命名規則は、何かをデバッグする前に身につけておく価値があります。プロバイダー名を変えれば、期待される変数名もそれに応じて変わるからです。 available_models はアローリストです。Zed は自力でカスタムエンドポイントを列挙できないため、宣言した id だけが選択可能になり、それぞれバージョンサフィックスも含めた正確な文字列である必要があります。api_url の背後にあるエンドポイントが Claude・GPT・Gemini・Kimi の id を横並びで提供している場合、provider ブロック1つでエージェントパネルのピッカーがベンダーをまたいだ切り替え盤になります。一点だけ範囲の注意を。Zed の編集予測(edit predictions)機能は自前の専用モデルを使っており、別に設定されます。カスタムプロバイダーが動かすのはエージェントパネルとインラインアシスタントであり、編集予測ではありません。

フルセットアップ: モデル・コンテキストサイズ・機能。

available_models の各エントリは名前以上の情報を持ちます。max_tokens はそのモデルのコンテキストウィンドウを、max_output_tokens は生成の長さの上限を宣言します。Zed はこれらの数値を使って長いエージェントスレッドを管理するため、長文脈モデルを小さな max_tokens で宣言すると、そのモデルの余力を静かに無駄にしてしまいます。capabilities オブジェクトは、そのモデルが何をサポートしているかを Zed に伝えます。エージェントパネルで動かすつもりのモデルには tools を true に、実際に画像入力を受け付けるモデルにだけ images を有効にしてください。 キーについては、デスクトップエディターでの確実な経路はプロバイダー設定の UI で、そこに入力した値はシステムのキーチェーンに保存されます。環境変数の経路も動作しますが、デバッグのセクションで扱う注意点が一つあります。Dock から起動した GUI アプリケーションはシェルのプロファイルを継承しません。

{
  "language_models": {
    "openai_compatible": {
      "apisrouter": {
        "api_url": "https://api.apisrouter.com/v1",
        "available_models": [
          {
            "name": "claude-sonnet-4-6",
            "display_name": "Claude Sonnet 4.6",
            "max_tokens": 200000,
            "max_output_tokens": 64000,
            "capabilities": { "tools": true, "images": false }
          },
          {
            "name": "claude-opus-4-7",
            "display_name": "Claude Opus 4.7",
            "max_tokens": 200000,
            "capabilities": { "tools": true }
          },
          { "name": "gpt-5.5", "display_name": "GPT-5.5", "max_tokens": 200000 },
          { "name": "kimi-k2.7-code", "display_name": "Kimi K2.7 Code", "max_tokens": 200000 }
        ]
      }
    }
  }
}

エージェントパネル向けのモデル選び。

宣言したモデルはすべて同じピッカーに並ぶため、実務上のワークフローはベンチマークではなく実際の作業での比較になります。同じ種類のタスクを2つの候補で別々の日に走らせ、キーごとの利用ログにそれぞれの値段を語らせてください。Zed でのモデル変更はドロップダウンの選択だけなので、実験のコストはゼロ設定で済みます。

• エージェントパネルは実際のエンジニアリング作業を担います。ファイルを読み、複数ステップの編集を計画し、長いスレッドにわたってツールを実行します。フロンティア級のコーディングモデル(claude-sonnet-4-6、claude-opus-4-7、gpt-5.5)がこのスロットにふさわしい存在です。
• kimi-k2.7-code のようなコーディング特化の id は、デフォルトにしていなくても宣言しておく価値があります。リファクタリングの多いセッション向けに切り替えるのもピッカーでの選択1つで済み、設定変更は不要です。
• gemini-3.1-pro-preview のような長文脈モデルは、スレッドが日常的に大きなファイルやモジュール全体の文脈を1つの会話に取り込む場合に力を発揮します。
• インラインアシストはエージェントスレッドより寿命が短いため、速い中位クラスの id を使えば、1行の書き換えにフロンティア級のトークンを消費することなく、単発の変換をきびきびと保てます。

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

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

Zed のカスタムプロバイダーに特有の失敗パターン。

settings.json にキーを書いたのに何も動かない。Zed は設計上、settings.json から API キーを読み込みません。プロバイダー設定の UI にキーを入力するか、導出された環境変数を export してください。JSON に貼り付けたキーは無視されます。 環境変数を設定したのに、まだキーを求められる。変数名はプロバイダーキーから、大文字のスネークケースにして末尾に _API_KEY を付けて導出されるため、apisrouter という名前のプロバイダーには OPENAI_API_KEY ではなく APISROUTER_API_KEY が必要です。また macOS では、Dock から起動したアプリはシェルのプロファイルを一切読み込まないため、プロファイルでの export は見えません。ターミナルから zed コマンドで起動して変数を継承させるか、キーチェーンの経路を使って問題そのものを回避してください。 ピッカーにモデルが見当たらない。available_models はアローリストなので、想定していたのに宣言し忘れた id は単に存在しません。id はバージョンサフィックスも含めた正確な文字列であり、ゲートウェイの /v1/models 一覧が正しい綴りをコピーする元になります。 エージェントがツールを使えない。あるモデルの capabilities ブロックで tools が false になっていれば、Zed はそのモデルでツール利用を提供しません。capabilities は、そのモデルが実際にサポートしている内容に合わせて宣言してください。 /v1 のない api_url。クライアントは与えられたベースに /chat/completions のようなルートパスを付け足すので、https://api.apisrouter.com/v1 が正しく、素のホストでは動きません。それ以外は正しそうなブロックでの 404 らしき失敗は、ほぼ常にこれが原因です。

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

• エディターの中で作業し、ベンダーごとに別々の認証情報を維持するのではなく、Claude・GPT・Kimi を1つのエージェントパネルピッカーにまとめたい開発者。
• 実際の編集でコーディングモデルを比較するエンジニア。候補ごとに宣言を1つ追加してドロップダウンで選ぶだけで、実験のたびに新しいアカウントは要りません。
• 1つのシークレットに標準化したいチーム。オンボーディング資料の APISROUTER_API_KEY 1つがベンダーごとの鍵チェックリストを置き換え、キーごとの利用状況が各席の支出を示します。
• フロンティア級のエージェントモデルと、別ベンダーの高速なインラインアシストモデルをペアで使いたいユーザー。単一ベンダー構成では表現できません。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

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

エージェントスレッドを始める前に、ゲートウェイが何を提供しているかを一覧してください。/v1/models が返す id は、available_models のエントリが使うべき文字列そのものです。 最初のスレッドの失敗は一貫しています。401 は Zed が解決したキーが誤っているか存在しないことを意味します。プロバイダー設定のキーチェーンエントリを確認するか、導出された環境変数が Zed のプロセスから(あなたのターミナルからだけでなく)見えているか確認してください。ゲートウェイからのモデル未検出エラーは、宣言した名前がバージョンサフィックスも含めて提供されている id と一致していないことを意味します。provider ブロックが設定にまったく現れない場合は JSON を検証してください。settings.json はコメントは許容しますが、構造的なエラーは許容しません。 リクエストが流れ始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。エージェントスレッドは長い文脈で多ターンのワークロードなので、どのスレッドとどのモデルがトークンを消費しているかを見ることが、既定のモデルがそのスロットに見合っているかを判断する手立てになります。

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

よくある質問