Cursor Router、プログラミングタスクごとにモデルを選択し、オンライン行動シグナルで品質と推論コストを両立

CursorはTeamsおよびEnterprise向けにCursor Routerをリリースした。これにより、従来は開発者がモデルを固定的に選択していたAutoモードが、リクエストごとに分類してから異なるモデルへ送る方式に変わる。ルーターはクエリの内容、既存のコンテキスト、タスクの複雑さ、分野を確認する。定型的な変更はコスト効率の高いモデルに任せ、UI関連の作業には製品の嗜好に合うモデルを選び、長いワークフローや難易度の高い問題はフロンティア推論モデルへ振り分ける。

Cursorによると、分類器は60万件を超える実際のリクエストで訓練され、数百万件のオンラインリクエストを対象にA/Bテストが実施された。オフラインのコーディングベンチマークだけを見るのではなく、ユーザーが次の作業へ進んだか、エージェントを修正したか、生成されたコードが後日もコードベースに残っているかという割合から、出力への満足度を推定する。訓練とコスト評価には、モデル切り替えによって生じるキャッシュミスも織り込まれており、100万token当たりの価格を単純に比較するより、マルチターンのエージェントワークロードに近い評価となっている。

ユーザーはIntelligence、Balance、Costの3つのモードから、品質と費用のバランスを選択できる。管理者はチーム単位での有効化、利用可能なモードの制限、デフォルト値の設定、モデルの許可リストまたはブロックリストの作成が可能だ。ルーターはすでにデスクトップ版、Web、iOS、CLI、SDKをカバーしており、同一のモデル選択ポリシーを対話型開発と自動化エージェントの両方に適用できることを意味する。

公式発表では、Auto Intelligenceの満足度は高性能モデルに近く、チームのコストは約60％低いとされる。また、利用量の多い3社の初期顧客では、すべてのリクエストをOpus 4.8へ送る場合と比べて、約30～50％のコストを削減したという。ただし、これらの結果は依然としてベンダー内部の測定値として捉えるべきだ。AFC満足度分類器の精度、各モデルが実際に処理したトラフィックの比率、失敗事例は公開されておらず、ルーティングによってモデルのバージョンが追加の変数にもなる。導入するチームは、リクエストごとに実際に選択されたモデル、コスト、レイテンシー、リグレッション結果を記録し、全体平均の改善によって特定の言語やタスクにおける品質低下が覆い隠されないようにすべきだ。