オープンコード

opencode は、環境変数ではなくマージされた JSON 構成レイヤーからプロバイダーを読み取るため、挿入する ANTHROPIC_BASE_URL スタイルのスロットはありません。 ocx opencode はそのギャップを橋渡しします。プロキシが実行されていることを確認し、表示されているカタログからプロバイダーブロックを構築し、OpenCode のインラインランタイム層 (OPENCODE_CONFIG_CONTENT) を通じてそれを挿入します。

クイックスタート

ocx opencode

これにより、プロキシが確実に実行され、そのプロセスに挿入された生成された provider.opencodex ブロックのみを使用してオープンコードが起動されます。追加の引数は ocx opencode run "hello" を通過します。

ルーティングされたモデルは、ピッカーの opencodex プロバイダーの下に表示されます。

opencodex/kiro/glm-5
opencodex/gpt-5.6-sol      # native slugs stay unprefixed

あなた自身の設定は決して変更されません

ランチャーは、~/.config/opencode/opencode.json、プロジェクト opencode.json / opencode.jsonc、またはその他のディスク上の構成レイヤーをコピーしたり書き換えたりしません。既存のプロバイダー、エージェント、キーバインド、MCP エントリ、および相対的な {file:…} 参照は元のファイルから解決され続けますが、provider.opencodex オーバーライドを検出するためにグローバルまたはプロジェクト設定を読み取ることがあります。

この起動の場合のみ、opencodex は、OpenCode のインラインランタイム層を介して、生成された provider.opencodex ブロックを追加します。そのレイヤーは、グローバル/カスタム/プロジェクト設定の後にマージされ、子プロセスの競合するキーのみをオーバーライドします。

レイヤー	`ocx opencode` での動作
グローバル / カスタム / プロジェクト構成	書き込んだとおりにディスク上に残ります
インラインランタイム (`OPENCODE_CONFIG_CONTENT`)	生成された `provider.opencodex` ブロックのみを受信します。
相対 `{file:…}` パス	最初に定義した設定ファイルに対して引き続き解決します。

グローバルまたはプロジェクト設定でも provider.opencodex が定義されている場合、ランチャーは情報メモを出力します。ocx opencode のランタイム層がその起動に対してそれをオーバーライドします。

ブロックを独自の設定に入れる

ocx opencode は 1 回の起動に対してのみプロバイダーブロックを挿入します。これは、プレーン opencode はまだプロキシについて何も知らないことを意味します。プレーンな opencode から、またはランチャーを経由しないエディター拡張機能からルーティングされたモデルを利用できるようにしたい場合、ocx export は同じプロバイダーブロックを出力して、独自の設定にマージします。

ocx export --client opencode

プロキシが実行されている必要があります。このコマンドは、構成、正規の宛先 (~/.config/opencode/opencode.json、またはそれが設定されている場合は XDG_CONFIG_HOME の下)、マージ警告、および env エクスポート行を出力します。そのファイルには決して触れません。上記のセクションはそのままであり、ブロックを設定に移動するのは明示的な行為です。

provider.opencodex ブロックを既存の設定にマージします。ファイル全体をエクスポートされたファイルで置き換えると、他のプロバイダー、エージェント、キーバインド、および MCP エントリが破壊されます。 ocx export --out はまさにこの理由で既存のファイルの上書きを拒否するため、--out をスクラッチパスに指定し、ブロックを次のようにコピーします。

ocx export --client opencode --out ~/opencodex-opencode.json

ランチャーのランタイムブロックとは異なり、マージされたブロックは静的なスナップショットであり、カタログに従いません。プロバイダーを追加するか、モデルの可視性を変更した後、ocx export を再実行します。

マージしたら、オープンコードを起動する前にアドミッションキーをエクスポートします。プロキシがループバック上にある場合を除き、何も必要ありません。

export OPENCODEX_OPENCODE_API_KEY=<your key>

アドミッションキーがディスクに書き込まれません

プロキシが API キーを必要とする場合、インラインランタイム設定にはシークレットではなくオープンコードの {env:…} 参照が含まれます。ループバックバインドでは、その参照を apiKey として使用します。非ループバックバインドは x-opencodex-api-key を介してのみ送信するため、プロキシアドミッションはアップストリームの Authorization ヘッダーから分離されたままになります。

ループバックの例:

"options": {
  "baseURL": "http://127.0.0.1:10100/v1",
  "apiKey": "{env:OPENCODEX_OPENCODE_API_KEY}"
}

非ループバックの例:

"options": {
  "baseURL": "http://192.168.1.10:10100/v1",
  "headers": {
    "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
  }
}

実際の値は、子プロセス環境を介してのみ渡されます。 OPENCODEX_API_AUTH_TOKEN が優先され、次に強化されたサービストークンファイル、次に設定された API キーが優先されます。これは、非ループバックバインドに必要なものです。

ループバックバインド (127.0.0.1、デフォルト) は何も認証しないため、{env:…} 参照は不活性であり、変数を設定しないままにすることができます。 hostname がループバックを超えて設定されている場合にのみ問題になります。リモートアクセスを参照してください。このアドミッションキーは opencodex 独自のものであり、プロバイダーで構成されたアップストリームプロバイダーキーとは無関係です。

元に戻す

元に戻す必要はありません。生成された設定ファイルは ~/.opencodex の下に書き込まれません。プレーンな opencode を実行すると、以前と同じように独自の設定が読み取られます。

モデルの制限

limit.context は、カタログが権限のあるコンテキストウィンドウを報告する場合にのみ書き込まれます。そうでない場合、limit ブロック全体が省略され、opencode は独自のデフォルトを保持します。

opencode のスキーマは、output のない context を含む limit ブロックを拒否し、カタログにはモデルごとに権限のある出力フィールドがないため、32000 の output バジェットが一緒に出力され、コンテキストウィンドウに固定されるため、コンテキストの小さいモデルには output > context が与えられません。この数値はスキーマを満たすために存在します。これは、特定のモデルの真の最大値について主張するものではありません。

opencodex プロバイダーブロックは起動のたびに再生成されるため、内部で行われたモデルごとの調整は存続しません。代わりに、独自のプロバイダーキーの下にカスタムエントリを保持します。

要件

opencode が PATH にインストールされている必要があります。

npm install -g opencode-ai