CursorBench 3.1 モデル評価結果

 (cursor.com)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Cursorのコーディングモデル評価表で Fable 5 Max が72.9%で1位を記録し、上位争いの基準点となった
  • Fable 5 系列は Max、Extra High、High、Medium が1〜4位を独占し、他のモデル群と明確な差を示した
  • 5位圏以降には Opus 4.7 Max 64.8%、GPT-5.5 Extra High 64.3%、Fable 5 Low 64.2%、Opus 4.8 Max 63.8%、Composer 2.5 63.2% が続く
  • CursorBench 3.1 は コードベース理解、バグ発見、計画、コードレビュー中心の作業を追加し、一部の編集作業の採点基準を改善した
  • 平均タスク当たりのコストは公開トークン価格とタスクごとの使用トークンから算出され、小さなスコア差は統計的に有意でない可能性がある

上位は Fable 5 が独占

  • CursorBench 3.1 の表では、モデル別の順位、スコア、平均タスク当たりコスト、使用量関連の数値をあわせて比較している
  • 1位から4位まではすべて Fable 5 系列
    • Fable 5 Max: 72.9%, $18.02, 63,842, 76
    • Fable 5 Extra High: 72.0%, $13.74, 48,754, 63
    • Fable 5 High: 70.6%, $10.81, 37,173, 54
    • Fable 5 Medium: 69.8%, $8.27, 28,507, 47
  • 5〜10位の区間では Opus、GPT-5.5、Fable、Composer モデルが混在している
    • Opus 4.7 Max: 64.8%, $11.02, 62,989, 96
    • GPT-5.5 Extra High: 64.3%, $4.37, 17,905, 46
    • Fable 5 Low: 64.2%, $5.70, 18,882, 36
    • Opus 4.8 Max: 63.8%, $7.59, 77,370, 60
    • Composer 2.5: 63.2%, $0.55, 15,152, 37
    • GPT-5.5 High: 62.6%, $3.59, 13,329, 40

中下位モデル別スコア

  • 11〜20位は Opus、Sonnet、GPT-5.5 モデルが主に占めている
    • Opus 4.8 Extra High: 62.1%, $6.14, 55,622, 54
    • Opus 4.7 Extra High: 61.6%, $7.11, 43,942, 72
    • Sonnet 5 Max: 61.2%, $6.87, 93,485, 93
    • Opus 4.7 High: 59.4%, $5.01, 32,227, 59
    • GPT-5.5 Medium: 59.2%, $2.22, 9,065, 35
    • Opus 4.8 High: 58.4%, $4.41, 36,788, 45
    • Sonnet 5 Extra High: 58.4%, $5.23, 58,228, 86
    • Sonnet 5 High: 57.0%, $3.74, 41,735, 66
    • Opus 4.8 Medium: 56.6%, $3.83, 31,684, 41
    • Sonnet 5 Medium: 54.9%, $2.57, 27,469, 53
  • 21〜36位には GLM、Kimi、Gemini、Sonnet、Composer などが含まれる
    • GLM 5.2 Max: 54.6%, $3.11, 51,312, 83
    • Opus 4.8 Low: 54.3%, $2.93, 22,726, 36
    • Opus 4.7 Medium: 52.7%, $2.93, 19,193, 41
    • Kimi K2.7 Code: 52.7%, $1.92, 32,902, 70
    • Composer 2: 52.2%, $0.56, 14,163, 40
    • GLM 5.2 High: 50.7%, $2.46, 30,621, 76
    • Gemini 3.5 Flash: 49.8%, $1.94, 35,105, 79
    • Sonnet 4.6 Max: 49.0%, $3.09, 40,280, 55
    • GPT-5.5 Low: 48.8%, $1.19, 4,923, 24
    • Sonnet 4.6 High: 48.8%, $3.06, 37,352, 57
    • Opus 4.7 Low: 48.3%, $1.87, 13,164, 29
    • Sonnet 5 Low: 47.7%, $1.46, 17,028, 37
    • Kimi 2.6: 47.6%, $1.27, 24,783, 56
    • Sonnet 4.6 Medium: 46.0%, $2.64, 31,360, 50
    • Sonnet 4.6 Low: 41.5%, $1.89, 21,211, 50
    • Kimi 2.5: 31.9%, $0.87, 9,446, 30

CursorBench 3.1 の評価範囲

  • CursorBench 3.1 はコードベース理解、バグ発見、計画、コードレビューに焦点を当てた問題を導入した
  • 一部の 編集作業 の採点基準も改善された
  • CursorBench 3.0 は編集、リファクタリング、バグ修正問題に焦点を当てた初期の作業セットだった

コスト計算と解釈上の制約

  • 平均タスク当たりコストは、各モデルの公開 per-million-token pricing を使って計算される
  • 入力、キャッシュ読み取り、キャッシュ書き込み、出力価格をすべて含む
  • 各モデルが CursorBench 3.1 のタスクで使用したトークンに価格を適用した後、タスク全体の平均を算出する
  • 結果には 変動性 が残っており、小さなスコア差は統計的に有意でない可能性がある

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker News の意見

  • 少し懐疑的
    Cursor のベンチマークでは、Cursor のモデルである Composer 2.5 が Opus 4.8 max や GPT-5.5 xhigh と同等に良く、価格はずっと低いという結果になっている
    しかし Artificial Analysis のテストでは、Composer 2.5 はかなり後れを取っている: https://artificialanalysis.ai/agents/coding-agents
    DeepSWE ベンチマークを見ると、GPT-5.5 xhigh は 64、Opus 4.8 max は 56、Cursor 2.5 は 16 だ
    Cursor が誰かにはよく合う可能性は疑っていないが、Opus 4.8 や GPT-5.5 の競合だという主張は疑わしい。自社ベンチマークでは良く出て、第三者ベンチマークでは大きく後れを取るというのは、あまりにも都合がよく見える

    • Cursor で働いている。Composer 2.5 のリリース当時は、AA の総合ベンチマークでかなり競争力があり、全体で 3位 だったと記憶している
      最近 AA は DeepSWE を使うように変更したが、このベンチマークは非常に長いスコープのタスクにより重点を置いている。Composer はまだそうしたタスクが得意ではないので、次のモデルで改善しようと取り組んでいる
      全体として、Composer が良い結果を出すベンチマークもあれば、そうでないものもある。それでも現在の価格帯では非常に有能なモデルだと見ている。特定の挙動や弱点を見つけたら、ここで知らせるか、lrobinson at cursor.com までメールしてほしい
    • 何が起きているのか理解するのは難しくない。自社データのパターンと特定の能力に合わせて 強化学習 したのだから、当然、学習セットと噛み合うベンチマークを作ることになる
      皮肉なことに、Cursor の「固有の顧客」が本当に関心を持つ狭い範囲では、そのベンチマークは Artificial Analysis より正確かもしれない。それ以外では、単なるもう一つのデータポイントとして見ればよい
    • DeepSWE は独自の 実行ハーネス だけを使うという点で少し欠陥があり、そのハーネスが適切にサポートしていないモデルでは問題が起きる
      こうしたモデルがどう動くかにはハーネスが大きく影響するという証拠が多いのに、DeepSWE はその要素を完全に取り除いている。おそらく自分たちが好むいくつかのモデルでだけうまく動くことを確認した可能性が高い
      GitHub Issue にも報告されている通り、キャッシュを使わないハーネスなので コスト計算 にも問題がある。完璧なベンチマークはないが、ベンチマーク間のばらつきはかなり説明できる
    • Cursor のセッションは、Composer モデルが強化学習される対象とほぼ同じだ。このベンチと学習データは事実上同じ 分布 のはずだ
    • ベンチマークのことはよく分からないが、Composer 2.5 はかなり使ってみて、実作業ではかなりうまく動いた

  • 軸をこう取った選択はかなり困惑する。左側が最も安い方だと思ったが、むしろ最も高い方だった
    右上が最高になるようにしたい配置は理解できるが、コスト軸 が逆なのはやはり直感的ではない
    それはさておき、毎日一日中、エージェントがかろうじてこなせるレベルの非常に難しい実装をしているが、「本当の検証」が必要な作業では、しばらく Opus を max に保つ必要があった。Opus を GPT-5.5 xhigh に少しでも近い動作にするには、実質的にそれが唯一の方法のように感じた
    GPT-5.5 をサブスクリプションで使うとコンテキストウィンドウが小さく、400k だが実効では 258k 程度なので、Opus を使っている
    違いは、GPT-5.5 xhigh がほとんどの実例で非常に速い点だ。実装全体も効率的で、深く考える必要のない質問には適応的に素早く答える
    一方 Opus 4.8 Max は何でも不必要に長く考え込み、単純な実装でも何時間もかかることがあり、主に計画とレビューにだけ使うようになる
    Fable は適応的思考と高速な応答ではずっと優れているが、おそらく GPT-5.5 xhigh にはまだ及ばないだろう。皆それぞれ長所と短所は十分に語っていると思うし、残念ながら私の難しい作業では、まだ信頼できる実装者ではない。依然として GPT の領域であり、Fable は細かく面倒を見ないと、実装の中に大きく危険な穴を残しがちだ

    • 「毎日一日中、エージェントがかろうじてこなせるレベルの非常に難しい実装をしている」という内容のうち、検証可能なものは何か一つでもあるのか？ それともただ信じろということなのか？ 全部笑えるほど 主観的 に聞こえる
    • Fable が実装の中に危険な穴を残すなら、GLM や DeepSeek を混ぜて コードのレッドチーミング 用途に統合することもできそうだと思う
      Fable は設計上セキュリティに盲目であり[0]、オープンモデルはそのあたりがかなり得意だ
      [0] GPT-5.6 がどうなるかは不明だが、ブログを見る限り、同様に過度に慎重な安全フィルターが入るようだ
      面白いのは、最近の Opus のリリース記事がセキュリティ能力を意図的に下げたと自慢している点だ。“during its [Opus 4.7] training we experimented with efforts to differentially reduce these ["cyber"] capabilities”
    • Gartner 方式だ。右上が行きたい場所だ
    • x 軸をなぜ反転させたのかという点には同意する。このグラフは一般の観察者には非常に理解しにくくなっている
    • 「GPT-5.5 をサブスクリプションで使うとコンテキストウィンドウが小さい」というのが、実作業で差を生むと感じているのか気になる
      私は 5.5 high/xhigh で C のコードベースを最適化し、ベンチマークするのに使っているが、初期コードを読むだけで最初の コンテキストウィンドウ がほぼ埋まる
      セッションは自動圧縮を 5〜15 回ほど行うが、作業が毎回最新のウィンドウに主に集中しているので、それなりにうまくこなしている
      プログラミングでは GPT の強みが Opus より大きく、コンテキストウィンドウの差を上回っているように思う

  • Composer 2.5 がそこまで良いというのは信じがたい。GLM 5.2 や Opus 4.6 と比べてみたが、問題を考える深さと批判的推論が足りなかった。
    ほかのモデルが作った計画を実行するには向いているが、その場合でも周辺ファイルが実際に動く仕組みとはかなり違う、奇妙なコード操作をすることがある。

    • 今は Cursor を使っていないが、少し前に使ったときの経験も似ていた。Opus で計画し、Composer で実装し、Opus で仕上げた。
      Composer は良い計画があれば有能だが、驚くほどではなかった。それでも本当に気に入ったのは速度だった。
      Opus なら30分かかる仕事を、Composer は5〜10分で終わらせた。もちろん結果は完璧ではないので、Opus や Codex で仕上げの段階を通した。
      結局はバランスの問題であり、常に変化するし、解いている問題に完全に依存する。私は柔軟に保ち、その瞬間にいちばんうまく機能するプロセスに合わせている。
    • こういうものを見ると、単にギザギザしたフロンティアなのだと思う。個人の経験を疑っているわけではない。先月、Grok と X のプレミアムアカウントのクレジットで Composer 2.5 を使ってみた。
      ロケットを作っているわけではないが、かなり印象的だった。どのモデルも時々間抜けなことをするが、私が頼んだ作業はかなりうまくこなし、印象的な結果も見せてくれた。
      Grok では速く、私が多く使ってきたほかのモデルと比べると gemini 3.1 より良いと思う。私の基準では 3.5 と antigravity は以前の gemini cli より劣っていた。Opus 4.6 とは同程度。Claude Code のもっと新しいモデルはまだ試していない。

  • グラフを正しく理解しているなら、Fable は sonet や opus に比べて、同じ作業を達成するのにより少ないトークンを使っている。だとすれば良いことだ。
    しばらくの間、より良い結果を得るためにトークンを大量に吐き出しているように感じていたが、モデル自体がより多くのトークンを生成せずに良くなっているのなら、本当の成果に感じられる。
    質問1: このグラフでステップ数がなぜ重要なのか。何を教えてくれるのか。
    質問2: なぜ横軸を反転して、0 が原点ではなく右側に来るようにしたのか。新しい賢い方法なのか。以前は見たことがない気がする。

  • Opus 4.7 が 4.8 より良い結果を出しているのが興味深い。4.6 もテストしてくれればよかったのに。昨日ここで、後継モデルより 4.6 のほうが良いと主張して嘲笑されていた人を見た。
    ただしベンチマークはいつも厄介だ。DeepSWE では GPT-5.5 が Opus-4.8 にかなり大きな差で勝っているが、FrontierCode では逆だ。
    信頼できる唯一のベンチマークは、実際の自分のワークロードだ。

  • 新しいベンチマークが出るたびに、中国系モデルは既存ベンチマークから期待される水準よりずっと低く出て、時間が経つとまた回復する。

    • 蒸留の魔法だ。

  • こういうサイトはどれも、コスト/性能のパレートフロンティアのグラフを見せてくれるとよい。重要なのは主にその2つだ。速度パラメータを入れて3次元にすることもできるだろうが。
    https://paraplouis.github.io/llm-pareto-frontier/ は、私が見た中では最も良いグラフだが、望むほど頻繁には更新されていない。

    • そのサイトはあまり役に立たない。思考トークンとキャッシュ、そしてその効率が反映されていないからだ。
      GLM5.2 は、ネット上で人民解放軍が動員できるあらゆる五毛党が宣伝しているが、思考過程が過度に冗長で、その不足が露呈している。
      Anthropic のモデルにも同じ問題はあるが、はるかに高い実際の知能を土台にしている。
      まさにそのため、信頼できる比較は今では任意の入力/出力トークン単価ではなく、タスクを完了するのにかかる総コストを基準に示している。

  • Composer 2.5 と GPT 5.5 を Cursor と Codex の両方でかなり使ってみたが、Composer 2.5 の性能が GPT 5.5 に近いという主張は完全にばかげている。
    たしかに速いが、品質はまったくその水準ではない。
    しかも Composer は Cursor の月額サブスクリプションがないと使えないので、コスト比較にも意味がない。同程度の価格の OpenAI サブスクリプションなら、より良いモデルをその分使える。

  • 最も興味深い部分はコストだ。GPT 5.5 と sonnet 5 は GLM 5.2 と同じコストだが、より有能なモデルだ。

  • Cursor のモデルが Cursor のベンチマークで優れているとは、11時のニュースものだ。
    ただし、ほかのモデルはすべて、実際に使ってみた経験から予想した位置にかなり妥当に置かれている。
    Fable はコストが10倍だが、ほとんどの面でほかのモデルを圧倒している。ただ、ときには安いものと高いものの選択ではなく、高いが可能なものと、そもそも不可能なものの選択になる。他のモデルと同じく、その境界がどこにあるのかを学ぶ必要がある。