docs: clarify provider path limitations

This commit is contained in:
Ravi Tharuma
2026-03-27 11:13:08 +01:00
parent 224f0de353
commit 0ab977c236
4 changed files with 9 additions and 8 deletions

View File

@@ -74,13 +74,13 @@ CLIProxyAPIは[Amp CLI](https://ampcode.com)およびAmp IDE拡張機能の統
- 利用できないモデルを代替モデルにルーティングする**モデルマッピング**(例:`claude-opus-4.5``claude-sonnet-4`
- localhostのみの管理エンドポイントによるセキュリティファーストの設計
のバックエンド実行系に送るかを確定させたい場合は、統合された `/v1/...` エンドポイントよりも provider-specific のパスを優先してください。
特定のバックエンド系統のリクエスト/レスポンス形状が必要な場合は、統合された `/v1/...` エンドポイントよりも provider-specific のパスを優先してください。
- messages 系のバックエンドには `/api/provider/{provider}/v1/messages`
- モデル単位の generate 系エンドポイントには `/api/provider/{provider}/v1beta/models/...`
- chat-completions 系のバックエンドには `/api/provider/{provider}/v1/chat/completions`
これ`oauth-model-alias`、alias プール、model fallback によって複数のバックエンドが同じクライアント向けモデル名を共有する場合に特に重要です。その場合、`/v1/models` は実際に狙っている実行系ではなく、統合後のエイリアス表示を返すことがあります。バックエンド選択の基準としては provider-specific のリクエストパスを使ってください。
これらのパスはプロトコル面の選択には役立ちますが、同じクライアント向けモデル名が複数バックエンドで再利用されている場合、それだけで推論実行系が一意に固定されるわけではありません。実際の推論ルーティングは、引き続きリクエスト内の model/alias 解決に従います。厳密にバックエンドを固定したい場合は、一意な alias や prefix を使うか、クライアント向けモデル名の重複自体を避けてください。
**→ [Amp CLI統合ガイドの完全版](https://help.router-for.me/agent-client/amp-cli.html)**