上級プラットフォーム / AI エンジニア
エージェントが使うモデルを固定する：計画は一方、実行はもう一方
クライアント側のモデル選択を無効化し、プランモードと実行を分離します。強いモデルが計画し、安いモデルが実行します。
コミュニティが実際に不満を言っていること
「開発者が変更履歴を要約するために Claude Code を Opus に切り替える」「全員が設定で別々のモデルを使っていて、誰がいくら使ったか分からない」「クライアント側のポリシーを試したが、誰でも書き戻せてしまう」。
モデルの選択は開発者の好みではなくコストの判断です。リクエストが実際に着地するゲートウェイで強制する必要があります。
GateLLM の実現方法
3 つの層があり、どれも省けません。キーグループのモデル許可リスト（イングレスゲート）が許可されていないモデル名を 403 で拒否し、catch-all のモデルマッピングが「*」から任意のリクエストを承認済みモデルへ書き換え、before スロットのスクリプトがプランモードの間は強いモデルを維持し、終了時に実行モデルへ切り替えます。
Claude Code の会話タイトル生成のようなバイパス的なリクエストにはプランのマーカーがないため、安い実行モデルへ落ちます。これはまさに「要約に Opus を走らせない」という望む動作です。
実際に効果が出る 5 つのレバー
- イングレスゲート：キーグループのモデル許可リストが、ルーティング前に許可されていないモデル名を拒否
- catch-all マッピング：「*」から承認済みモデルへ。要求されたすべての名前を 1 つのモデルに正規化
- plan / 実行の分離：before スロットのスクリプトがプランモードのマーカーを読み、プランを抜けた後にのみルーティングを切り替え
- 可観測：切り替えられたリクエストにはログで SW タグが付き、各リクエストの実際の着地モデルを監査可能
- ホットリロード：マッピングとルールは即時反映。再起動も開発者ごとの展開も不要