少なくともベーススペックと価格はここにあるよ（GPT-5と同じ）：https://cursor.com/docs/models

詳細は他のブログ記事にあるよ：https://cursor.com/blog/composer

ブログ記事書いたのAppleのマーケティングチーム？

具体的な比較が全然ないじゃん。自分たちのベンチマークしか使ってないし。複数のモデルの結果を混ぜて1つのデータポイントにしてるけど、どうやって計算したのかも書いてない。

ここに、僕が正直理解できない追加情報がたくさんあるよ。

https://cursor.com/blog/kernels

マジでただの新しいモデルで

1：品質はかなり良い（でもGPT5とかClaudeほどじゃない）

2：速い

3：ツールを呼び出すように特化して学習されてる

って感じ。

でもGPT-5と同じ値段なんだよね

速いのは良いんだけど...

CheetahってGPT-5.1 miniだと思ってた。

ジャジャーン！

ComposerはCheetahのより新しくて賢いバージョンだよ！

GPT-5と同じ？

いや、自分のテストだと、思考モデルじゃなくて並列ツール呼び出しを利用して、余計なことに時間を浪費しないから、トークンの生成量が少なくて、GPT-5よりも**安く**済んだよ。同じようなタスクで。

Cursorチーム、今回はマジでやったな。これからも期待してる。

あと、ブログ記事のスクリーンショットで、**思考モデル**にもなれるみたいだけど、なぜか自分の環境では思考バージョンが使えないんだよね。まだ製品版には対応してないのかな？

自分のテストだと、Composerモデルがしばらく考えてる時もあれば、そうじゃない時もある。どんなリクエストを出すかによるんじゃないかな。

このコメントを見てみて：https://www.reddit.com/r/cursor/comments/1oj8kwe/comment/nm1ww4x/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

ありがとう！

マジですごく良さげだね。小規模でシンプルなタスクにはすごく良い選択肢だ。もっと複雑なタスクで試してみたけど、ニュアンスとか深い思考が足りなくて、そこまで良くなかった。でも、複雑じゃないタスクにはすごく使えるね。Cursorの追加機能としては間違いなく素晴らしい。

Lovableみたいなプラットフォームからもっと市場シェアを奪うために、vibe coderに媚びようとしてるんじゃないかな。

あー、それは残念。正直、Tabモードさえそのままなら俺は満足だわ。

いやいや、プロのエンジニアにとって最高のツールを作ろうとしてるんだよ！

なんでチャットで@が使えなくなっちゃったの？

@はまだ使えるよ。右下の@ボタンをクリックすることもできる。

切り替えられるの？少なくとも最新バージョンではできるよ。

エージェントのレイアウトのこと言ってる？普通のチャットビューには何も変更ないように見えるけど。

うん、違うね。

新しいやつ

https://preview.redd.it/4obbdubgj3yf1.png?width=459&format=png&auto=webp&s=88333bad2d84687b198b32109319281dda679067

昔のやつ。

[画像へのリンク]

なぜかエージェントが使ってるルールが見えなくなってる
ルールが見えないってのは勘違いだった。

手動でブラウザとか内部ドキュメントを使うようにエージェントに指示できなくなったのはマジで痛い。正直、これらの変更はどっちかっていうとイライラの種だわ。音声入力できるようになったのは確かに追加点だけど、みんなが思ってるほど特別な機能じゃないんだよね。音声テキスト変換なんて今更だし。

個人的には全然興味ないのが、
- 並列エージェント（これはマジでトークンの無駄遣いだと思う）
- Composer 1（前にCursorが出したcursor-small-1ってモデルがマジでクソだったから、新しいモデルにクレジットを無駄遣いする気はない）

いや、一番下の意見は100%撤回するわ。JUCEのコードベースに突っ込んで、Seed Basedのプロシージャル生成で抱えてた問題を解決してもらったら…1週間も格闘してたクラスをComposer 1がたった2分で引き継いで直してくれたんだけど…マジかよ……もしかしてAIって、常に監視しなくてもコード書けるレベルになってきてんじゃね……？

ルールはちゃんとあるよー。コンテキストゲージにマウスオーバーすると、適用されてるルールが見れるよ！

最後の点、エージェント的なモデルに対する不満の元凶だと思うんだよね。

最高の仕事させるには、ある程度自由にさせなきゃいけない。細かく管理するのはどんどん難しくなるし、イライラするし。

もっと自由にやらせてみようぜ！

Cliツールは完全にチャットベースだね。

エージェントのサイドバーが、ファイルエクスプローラーとかと同じようにただのタブの一つだったら、もっと違和感なかったと思うんだよね。メインの特別なタブでもいいくらい。右側はレビュー/エディターパネルにすれば、もっと快適になるはず。今のところ、アラビア語を読んでるみたいだけど、アラビア語が逆になってるみたいな感じ。あのサイドバーは明らかに画面の右側には合ってない。それに、ホットキーもおかしくなるし。左側のホットキーで右のパネルが開いて、右側のホットキーで左のパネルが開くんだもん。

情報の流れがめちゃくちゃになってる気がする。エージェントウィンドウが左にあって、コードを拡大するために右を見るっていうのは、実装のせいで自然に感じるんだよね。でも、ファイルツリーはエージェントの左側にあるべき。それらが隣り合ってることで、ファイルやフォルダをエージェントのコンテキストに素早く簡単にドラッグ＆ドロップできるから理にかなってるし。

何度も言うけど、アラビア語を読もうとしてるけど、アラビア語が逆になってるみたいな感じ。このサイドバーは情報が密集してて、明らかに左側に置かれるように設計されてるんだよ。

パフォーマンスとメモリ使用量を改善するために、めっちゃ投資してるよ！

完全に同意。これは素晴らしい追加機能になると思う。

良い感じのビジュアルIDEだね。今夜2.0で遊んでみるよ。

差分を見るにはClaudeのVS Code拡張機能が使えるよ！！

実際にコーディングする時のタブ機能が欲しい。

VS Code

VSCodeに知らない機能がある？ VSCodeにタブ機能がないなんてこと、ないよね？

Copilotには、拡張機能をインストールしていれば付いてるよ（デフォルトかどうかは知らないけど）。

Copilotのオートコンプリートは残念ながら全然追いついてないんだよね。

なんでまだこのサブレにいるの？

彼らが言及しているように、同じ機能を何度も構築して、最高のバージョンを選ぶっていうのは、トークンの無駄遣いのように思える。ワークツリーを使っても、結局は解決に時間のかかるマージコンフリクトが発生するから、自分自身でも良い目的を見つけられてないんだよね。

それ、俺も同じ経験あるわ。10個のエージェントを同時に使ってるって言ってる人のほとんどは、実際には何もローンチしてないと思う。それってただの惨事の元凶だよ。

でも、Sonnet 4.5とかGPT-5とかの機能はどうやってテストするんだ？

複数のエージェントに同じフル機能を作らせて、「一番良いものを選ぶ」のは、ほとんどの場合トークンの無駄遣いになる。多様性が欲しいなら、意思決定の段階で導入して、成果物全体に適用するのはやめよう。

トークン効率の良い並列処理のためには、まず短いドラフトに焦点を当てる。エージェントに簡潔な箇条書きのアウトラインや構造化された計画を生成させる。方向性を決めて、選択したパスを完全なコードに展開する。これにより、複数の完全な成果物のコストをかけずに、真の多様性と迅速な収束が得られる。

マージコンフリクトについて：Gitのワークツリーは、複数のワーキングディレクトリを提供するだけ。コンフリクトは、勝利したブランチとメインブランチの差分の関数であり、実行した実験の数ではない。ワークツリーは追加のコンフリクトを作成するわけではなく、共有状態に触れることなく、それらの実験を同時に実行できるだけ。勝利したブランチがコンフリクトを起こすはずだった場合、いずれにせよコンフリクトを起こしていたはず。クリーンに保つためには、すべてのスパイクを同じコミットから開始し、実行中に共有サーフェスをフリーズし、マージ前に勝者をリベースして、早期にドリフトを表面化させる。

同じフィーチャーの文脈でワークツリーの話をしてるんじゃないんだ。複数のフィーチャーをワークツリーで構築する場合の話。エージェントが暴走して、途中で共有ファイルを修正してバグを直したりすると、マージコンフリクトが起きるでしょ。

なるほどね。指示書に、各エージェントは定義されたスコープ内にとどまるように書けるね。例えば、特定のファイルとか、ファイル群とか（ホワイトリストとかブラックリストで）。でも正直、俺なら一度に1つのフィーチャーを1つのエージェント（または少数のエージェント）に担当させて、それぞれのアプローチで気に入った点を評価して、それを推進するかな。この場合、スコープを狭く保ち、方向性が決まってから解放したいよね。

複数のエージェントに別々のタスクを割り当てるのは、作業の境界線が明確な場合だけだね。プロンプトやリファレンスドキュメントで表現しやすい境界線で、重複がほとんどないか全くない必要がある。基本的には、デバッグ、ドキュメント作成、特定のアンチパターン探しのような、ある種のタスクに特化したサブエージェントだね。そうじゃないと、連携のコストに見合わないよ。

同意。計画段階（または途中の振り返り）で、計画している作業を並行処理しやすいように分割できるか確認するのは、良い習慣だと思う。

全部が全部、並行処理できるわけじゃないし、すべきでもないけど、確認しないだけで無駄にしてる時間って結構あるよね！

Composerで試すのが楽しみ。このアプローチ、AGENTS.mdにコミットごとのレビュー習慣として組み込むと、すごく役立つって気づいたんだ。

計画ドキュメントの冒頭に、大体こんな感じのものが表示されるんだよね。

    1
    2
  3  4    
    5    
    6
7  8  9
   10

ワークツリーの問題でまだ解決できてないのは、アプリのインスタンスが1つしか動いてないってこと。ワークツリーをアプリのルートディレクトリにシンボリックリンクすることはできるけど、切り替えのオーバーヘッドがまだ必要。同じブランチに対して複数のエージェントを動かすのと比べて、ワークツリーを使うメリットがあんまり見つからないんだよね。俺的には、2つのエージェントがコードの異なる領域で作業してると仮定すると、ほとんど同じ結果になると思う。

同じファイルで同じブランチを修正したりすると、同時にバグを直したり、依存関係があったりする場合に、マジで大変なことになるのが危険なんだよね。ワークツリーでやる方がずっと安全だよ。

うまくいくケースは2つあるよ:

1. 並列エージェント：gitのツリーを使って、複数のエージェントに同じ問題を解決させようとする。終わったらコードをチェックして、一番良いもの、またはそれぞれの最高のコードを組み合わせる。最高のコードだけをプッシュして、残りは削除する。LLMエージェントは問題に対して異なるアプローチを取ることが多く、質も大きく異なるから、これによって高品質なコードを得られる可能性が高まり、時間も短縮される。ただし、お金とリソースはかかる。

2. ドメイン特化型エージェント：特定のタイプのタスクのエキスパートになるように個々のエージェントをトレーニングする。たとえば、バグ退治に特化したエージェント、ドキュメント作成に特化したエージェント、コードをチェックしてリポジトリ固有のパターンや規範に従っているか確認するエージェントなど。これらのタスクを順番に実行する代わりに、複数のエージェントにこれらのタスクを同時に実行させることができる。各エージェントをタスクに特化してトレーニングすることで、タスクを実行するたびにトレーニングする必要がなくなり、タスクの遂行能力が向上する。

コードベースの異なる場所で、互いに衝突する可能性が低い2つの異なることを同時にやりたい時があるんだよね。そういう時に、エージェントAを起動して、それがキャンセルされることなくエージェントBへのプロンプトを書き始めることができたら便利だ。

マジで同意。でもそれって「cursor 1」でもできてたじゃん？メリットがまだよくわかんないんだよね。
思うに、gitのワークツリーで使うと、ちょっとだけ関連するファイルが2つの領域にある場合にメリットがあるかも。でも、たぶんひどいマージコンフリクトにはならないと思うけど。

間違いなく、GPT-5と同じくらいのコストがかかるし、ブログにもGPT-5の方がComposerより優れてると書いてある。だったら、なんでこれを使うの？半額くらいの値段にするべきじゃない？

結局は金だよ。Composerは間違いなく実行コストが安いモデルだけど、最上位モデルと同じくらいの価格設定にしてる。これは、GLM 4.6を追加しない理由を示唆してるんじゃない？ GLM 4.6の方が5倍も収益が減っちゃうから。GLM 4.6は、この新しいComposerモデルよりも3〜4倍安くて、コーディングに必要なユースケースの9割に対応できるし、Sonnetよりもずっと安価な、本当に堅実なエージェントモデルなんだ。これで何が起きてるか全部わかるでしょ。

イエス。たぶんHaiku 4.5とGemini 2.5 Flashを平均して「Fast frontier」って言ってるんだろうけど、それってむしろ微妙じゃね？ Haiku 4.5とGPT-5 Miniの方が同等かそれ以上だと思うけど。

4.5 Sonnetじゃないのは、たぶん値段のせい？

つまり、彼らの自社モデルの方がGrokよりもコストがかかるってこと？Grokはデータをトレーニングに使いたいから補助金を出してるのかな？

へー、おもしろい。つまり、ほぼGPT-5の性能だけど、もっと速いってことね。

パフォーマンスじゃなくて、コストの話ね。

自己解決しましたー。カーソル設定のデフォルトレイアウトにあったわ。同じ状況の人向け。

いつでも左上に切り替えスイッチがあるよ！

全モデルのハーネスも大幅に改善したよ！特にGPT-5 Codexがめっちゃ良くなった。2.0でも使えるようになってる。

違うよ。https://cursor.com/docs/models#model-pricing

無知で申し訳ないんだけど、出力トークンの品質って実際どう違うの？

エディターの左上でクラシック/エージェントのレイアウトを切り替えられるよ。

おお、わかった。表示 > エディターレイアウトと表示 > 外観で、エージェントタブ（ボタン？）の中を探してたんだ。めっちゃ紛らわしいわ。

UI担当の人へのデザインメモ：水平方向で同じ色、同じ太さの子サブメニューを親タブのすぐ隣に置くのはマジでヤバいから、やっちゃダメ：D