Cursor Router、リクエストごとにコーディングモデルを振り分け――コストモードではGrok 4.5をルーティング候補に残す必要

CursorはTeamsおよびEnterprise向けにCursor Routerを提供開始し、ユーザーがモデルを固定して選択する従来のフローを、リクエストごとに判断する仕組みへと変更した。Routerはまずコーディングタスクの種類と複雑さを分類し、管理者が許可したモデルの中から実行モデルを選択する。ユーザーはCost、Balance、Intelligenceのいずれかを選べる。BalanceとIntelligenceでは、実際に選択されたモデルの料金に基づいて課金される。管理者はチームまたはグループ単位で、デフォルトモード、モデルの許可リストまたはブロックリストを設定できるほか、ソフトポリシーまたは強制ポリシーによってAutoの使用を求めることもできる。

[Cursorの技術発表](https://cursor.com/blog/router)によると、Routerは60万件を超える実際のリクエストで学習され、その後、数百万件のオンラインリクエストを用いたA/Bテストが実施された。報酬シグナルには、AFCユーザー満足度指標が採用されている。Cursorは、Intelligenceモードによりフロンティアモデルの品質を維持しながら費用を約60%削減でき、初期の企業顧客では約30～50%のコスト削減が記録されたとしている。ただし、この発表では分類器、タスク別のモデル選択マトリクス、信頼区間、第三者が再実行できるテストデータは公開されていない。

この変更はデスクトップ版、Web、iOS、CLI、SDKに展開されており、[TestingCatalogの最近のまとめ](https://www.testingcatalog.com/)でも、3つのモードと各インターフェースへの展開範囲が確認されている。注目すべき点として、ルーティング結果はデフォルトで非表示にできるうえ、Costのルーティングでは、コストパフォーマンスに優れた候補としてGrok 4.5を残すことが求められる。つまり、データレジデンシー、ベンダー契約、結果の再現性を重視する企業は、「Cursor」自体を承認するだけでは不十分で、基盤となるモデル群とルーティングログも管理する必要がある。今後、エンジニアリングチームは、リクエストごとに実際に使用されたモデル、バージョン、料金、失敗後のフォールバックチェーンを出力するよう求めるべきだ。また、全体平均の削減率をそのまま信用するのではなく、自社リポジトリのタスクを使って、コスト、変更の受け入れ率、回帰エラーを比較する必要がある。