Cursorは、アップグレードしたエージェント群を従来システムと比較するため、両者にドキュメントだけを使ってSQLiteをRustで再構築させた。ソースコードやインターネットへのアクセスは与えられなかった。新システムのすべての構成は最終的にテストスイートで100 percentに到達した一方、旧型のエージェント群は大量のマージコンフリクトと重複作業によって遅れた。

Cursorでは、エージェントの集団運用は研究プロジェクトから中核製品へと移行している。Cursor 3では、開発者がAIエージェントの集団を並列に実行できる。Cursorを手がけるAnysphereは最近、Elon MuskのSpaceXに$60 billionで買収された。

このシステムは、エージェントを2つの役割に分ける。フロンティアモデルを使うプランナーエージェントは、目標を再帰的に小さなタスクへ分解する。より高速で低コストのモデルを使うワーカーエージェントは、それらのタスクを実行する。このプロセスにより、作業の進行に応じて変化できるタスクツリーが作られる。

Cursorによると、この分担は主にコンテキスト管理の問題に対処するものだ。単独のエージェントは、全体目標と目の前のタスクの両方を保持しながらタスクツリー全体を進む必要があり、長時間の作業でエージェントが方向を見失う理由の説明にもなる。Cursorの群制御設計では、プランナーはコードを書かず、ワーカーは計画を立てない。

Gitは1秒あたり1,000コミットに追いつけなかった

以前のCursorのブラウザー向けエージェント群は、Git上で1時間あたり約1,000コミットに達していた。そのシステムは、ワーカーエージェント、判定エージェント、コンフリクト解消を担うインテグレーターを使っていた。しかしインテグレーターは最終的に、解決策というよりボトルネックになった。

新しいエージェント群は1秒あたり1,000コミットに達した。そのためCursorは独自のバージョン管理システムを構築した。同社によると、その速度で動作するエージェントは、人間のエンジニアリングチームが通常遭遇しない故障モードを生み出した。この結果、この実験は単なる生のコード生成能力だけでなく、ソフトウェア開発インフラが何千もの自動編集を、重複作業で崩壊することなく調整できるかを問うものになった。

問題の一つは、Cursorが「split-brain design」と呼ぶものだった。このパターンでは、2つのプランナーが互いに気づかないまま、コードベースの別々の領域で同じ概念を構築し、それぞれ異なる方法で実装してしまう。プランナー同士が互いの存在を認識し、競合する編集で相手をブロックする場合、競合の管理はさらに難しくなった。

こうした問題を減らすため、Cursorはエージェントに共有設計文書へ意思決定を記録させた。意思決定に関連するコードは、コンパイル時にチェックされる参照を通じて、該当する文書へリンクされた。

マージコンフリクトが発生すると、中立的なエージェントが介入して解消した。ワーカーはまた、肥大化したファイルを検出し、外部のエージェントがそれを小さなモジュールへ分割できるようにした。エージェントは、人間が監督する既存コードベースで作業する際にコアコードへ触れないよう学習していたため、Cursorは意図的に壊すことを許可した。エージェントは割り当てられた範囲外のコードにパッチを当てることができ、コンパイラーがその変更をシステム全体へ反映した。

Cursorは複数のレビュアーとエージェント管理のフィールドガイドをテスト

Cursorは複数のレビュー手法を評価した。あるレビュアーはワーカーの完全なトランスクリプトを受け取り、別のレビュアーはワーカーの出力だけを見て、3つ目はコードベースだけを見た。単一の視点ですべての問題を検出することはできなかったが、Cursorは相関の低い視点を組み合わせることで信頼性が向上すると確認した。

同社はまた、固定の行数制限内でエージェント自身が管理する知識フォルダーである「field guide」もテストした。すべてのエージェントは起動時にそのフォルダーの内容を受け取った。モデルの重みは学習後に固定されるため、Cursorは、意外な発見を記録しておけば、後続のエージェントが近道できるため有用だとしている。

ベンチマークでは、Cursorはエージェント群に835ページのSQLiteマニュアルを与え、Rust実装を構築するよう指示した。エージェントにはSQLiteのソースコード、テストスイート、SQLiteバイナリ、インターネットアクセスは与えられなかった。ベンチマークは、既知の答えを持つ数百万件のSQLクエリを含むテストスイートsqllogictestだった。エージェント群はそのベンチマークの存在を知らなかった。この設定により、タスクはソースコードの翻訳やベンチマーク特化の調整ではなく、仕様への追従とシステム統合のテストになった。

Cursorは4つの構成をテストした。GPT-5.5単独、Grok 4.5単独、Opus 4.8をプランナー・Composer 2.5をワーカーとする構成、Fable 5をプランナー・Composer 2.5をワーカーとする構成である。新システムはすべての構成で旧システムを上回った。4時間後、新しい実行は73から85 percentのスコアだったのに対し、旧システムの実行は11から77 percentだった。新システムのすべての構成は、その後100 percentに到達した。

旧型エージェント群は完了した以上の作業を生み出した

Grok 4.5の実行は、従来システムが遅れた理由を示した。旧型のエージェント群は2時間で68,000コミットを生成し、新システムの約70倍に達した。Cursorによると、その活動の大半は無駄だった。旧システムの実行では70,000件を超えるマージコンフリクトが蓄積した一方、新しい実行はテスト全体を通じて1,000件未満にとどまった。

旧システムの実行で最も競合の多かったファイルでは、1,173エージェントが関与する7,771件のコンフリクトが記録された。新しい実行での比較対象の数値は47件だった。同じsplit-brain問題はパッケージ構成にも現れた。旧システムの実行はプロジェクトを54個のRustクレートに分割し、3つの別々のSQLパッケージを作った一方、新しい実行は早い段階で9つのクレートに落ち着いた。

Fable 5構成では、旧型エージェント群は64,305行のエンジンコードを必要としたのに対し、新システムは9,908行だった。Opus構成では、旧システムは19,013行を生成し、97 percentを記録した。新システムは4,645行で100 percentに到達した。Cursorにとって、行数とコンフリクトの少なさは同じ結果の一部だった。改良されたエージェント群は、より少ない重複実装作業で、より高いテスト性能に到達した。

低コストのワーカーモデルが最大のコスト差を生んだ

総コストは、Opusハイブリッド構成の$1,339から、GPT-5.5単独実行の$10,565まで幅があった。すべての実行で、ワーカーはトークンの少なくとも69 percentを占め、通常は90 percentを超えた。プランナーのトークンはより高価なため、コスト配分はトークン配分とは異なった。Opusハイブリッド実行では、プランナーが生成したトークンは小さな割合にすぎなかったが、総請求額の3分の2を占めた。

最大のコスト差を生んだのは、ワーカーモデルの選択だった。GPT-5.5実行では、ワーカーだけで$9,373かかった。OpusとComposerを使った実行では、同等の品質でワーカー群全体のコストは$411だった。Cursorは、この差はほぼ完全に価格設定によるものだとしている。Composer 2.5はOpus 4.7およびGPT-5.5と同水準のベンチマーク性能を示すが、コストは入力トークン100万件あたり$0.50、出力トークン100万件あたり$2.50である。Cursor創業者Michael Truellによると、このモデルはKimi K2.5をベースにしている。

Cursorは、大規模タスクのうちフロンティアモデルの知能を必要とするのは、タスク分解や主要な設計判断など一部に限られると主張している。フロンティアプランナーが曖昧さを解消すれば、より安価なモデルがその計画に従える。ただし、ハイブリッド実行は、プランナーの品質が依然として重要であることも示した。Fable 5のプランナーはOpusより少ない計画トークンを使ったが、ワーカーは作業を完了するためにはるかに多くのトークンを必要とし、Fable実行の総コストはより高くなった。

Cursorは、エージェント群を、意図を一歩ずつ実行可能な作業へ変換する一種の確率的コンパイラーと表現している。同社によると、この実験の主な制約は、その意図を正確に記述することだった。CursorはOpus単独実行から得られたコードベースをminisqliteとしてGitHubで公開した。

記事によると、この種の実行はもはや研究室での実験に限られない。Fable 5のプレリリース版は、BunのZigからRustへの書き換えの大部分を担った。64個のインスタンスが11日間で100万行を超えるコードを書き、コストは約$165,000だった。本番利用は依然として異なる。2025年後半に発表された研究では、本番環境で使われるエージェントの68 percentが、人間の介入前に10ステップ以下しか完了していないことが分かった。47 percentでは、その上限は5ステップ未満だった。この対比は、Cursorの制御された高並列ワークフローのどの程度が、人間が多くのエージェント実行を早期に中断する本番環境へ移行できるのかという、実務上の重要な問いを残している。