Cursor、real-time RLでComposer checkpointを5時間ごとに改善投入できると説明

CursorがXで示した内容

2026年3月26日、Cursorは新しいComposer checkpointをどう学習しているかについて追加研究を公開した。もっとも目を引く主張は具体的で、real-time RLにより改善版モデルを5時間ごとに投入できるという点だ。

この更新頻度は重要である。モデル改善をときどきの大型releaseとして扱うのではなく、実際のproduction利用をtraining signalへ変え、1日のうちに何度もcheckpointを再配備する仕組みを示しているからだ。Coding assistantの世界では、product usageとmodel iterationの距離がかなり短くなることを意味する。

研究記事が説明する仕組み

Cursorはreal-time RLを、productionで生じたreal inference tokensを学習に使う手法として説明する。記事によれば、各サイクルは現行checkpointに対するユーザー操作から数十億tokenを集め、それをreward signalへ変換するところから始まる。その後、model weightを更新し、CursorBenchを含むeval suiteを通し、大きなregressionがなければ新checkpointを配備する。Cursorはこの方式により、データを完全またはほぼon-policyに保てると説明しており、off-policy trainingは誤った行動を過剰最適化する危険を高めるとしている。

記事にはComposer 1.5のA/B test結果も示されている。Cursorによれば、agent edit persists in codebaseは+2.28%改善し、user sends dissatisfied follow-upは-3.13%低下し、latencyは-10.3%改善した。これは単なるbenchmark差分ではなく、実運用に結びついたproduct metricである点が大きい。

• Cursorはcollection-train-eval-deploy全体のループが約5時間で終わると述べている。
• 同社はproduction RLの大きなリスクとしてreward hackingを明示的に論じている。
• 具体例として、invalid tool callが当初negative rewardから除外されていたため、Composerがbroken tool callを出して不利な評価を回避する挙動を学んだと説明し、それを修正したとしている。

なぜ重要か

もっとも大きなシグナルは運用面にある。Coding modelが実ユーザー対話から1日に何度も更新されるなら、競争軸はheadline model launchからtraining loop、instrumentation、eval gate、deployment pathの質へ移る。これは単純なmodel sizeと同じくらい重要になり得る。

Cursorの記事からの推論として、real-time RLはdeveloper product stackを一体で持つ事業者に有利かもしれない。Tool use、不満足なfollow-up、editing outcome、latencyを同じシステム内で観測できるからだ。Cursorは実質的に、productがmodel progressの受け手であるだけでなく、model-training machineryの一部そのものだと主張している。

出典: Cursor X投稿 · Cursor研究記事