Cursor の AI コーディング統計データに関する興味深い分析
Cursor が公開した 2 年間の利用データ分析により、AI コーディングツールの活用において「コード生成量」よりも「既存コードの読解（入力トークン）」がコストと時間の大部分を占める実態が明らかになった。
キーポイント
パワーユーザーによる圧倒的な生産性差
上位 1% のユーザーは週あたり約 3-4 万行のコードを生成しており、これは中央値（700 行）の約 45 倍に相当する。
トークン使用の非対称性：読解が主役
Cursor の利用データでは、入力トークン（既存コードやドキュメントの読解）が出力トークンの約 10 倍を占め、全体の 90% を支配している。
コスト構造の変容
出力トークン単価が高いにもかかわらず、入力トークンの圧倒的な利用量により、AI エージェントのコストの約 70% が入力トークンに発生する。
キャッシュ活用によるコスト削減効果
コンテキストのスマートキャッシングを導入することで、出力トークンの使用率が0.6%まで低下し、入力トークンやキャッシュ読み込みが主要なコスト要因となっている。
高価なモデルと低価格モデルのコスト対比
最上位のOpus 4.7はComposer 2.5と比較して約10倍の高額であり、同等の結果が得られる場合、中堅以上の企業ではより安価なモデルの利用が増加する可能性がある。
高価格モデルによるコード採用率の向上
Cursorのデータによると、より高価なモデルほど1行追加あたりのコスト対効果が高く、コードの採用率（acceptance rates）が向上する傾向がある。
コスト効率とモデル性能の比較
Opus 4.7 は GPT-5.5 と同等のコスト効率を持ちながら、エージェントリクエストあたりのコストが半分であり、Cursor の Composer モデルは約 5 倍効率的である。
重要な引用
The top 1% of users generate around 30-40K lines of code per week! That's the equivalent of what ~45 'median' devs generate in the same period.
90% of Cursor's token usage is input tokens!
Indeed, the ratio of time spent reading versus writing is well over 10 to 1.
Without caching context, token cost would be 10x higher
Opus is the most expensive model & could hurt Anthropic
Opus 4.7 has the same cost-per-line-accepted as GPT 5.5 at half the cost per agent request.
影響分析・編集コメントを表示
影響分析
この分析は、AI コーディングツールが単なる「コード生成器」ではなく、「既存コードベースを深く理解・参照する高度な読解ツール」として機能していることを示唆しています。開発現場においては、ツールの導入効果測定会社において、生成行数だけでなくコンテキストの読み込み効率やコスト構造（入力トークン依存）への意識転換が求められます。
編集コメント
「生成」に注目しがちな AI ツール業界において、実際のコストと時間の大部分が「読解（入力）」にあるという逆説的な事実を浮き彫りにした貴重なデータです。開発者はツール選定や運用戦略を見直す際、この「10:1 のトークン比率」を重要な指標として考慮すべきでしょう。
こんにちは、Pragmatic Engineer ニュースレターの特別無料号をお届けします。Gergely です。毎号、シニアエンジニアやエンジニアリングリーダーの視点から、ビッグテックとスタートアップを取り上げています。今回は、過去の『The Pulse』記事 4 本のうち 1 つを再掲しています。フルサブスクライバーには、5 週間前に以下の記事を配信しました。このメールを転送された方は、こちらから購読できます。
Cursor は過去 2 年間の集約利用データに基づいた新しいレポートを発表し、いくつかの興味深い発見がありました：
パワーユーザーは、中央値と比較してコード行数が 10 倍生成します
image出典：Cursor
Cursor を使用している開発者の中央値（p50）は、週あたり約 700 行のコードを生成しますが、上位 90 パーセンタイル（p90）では約 9,000 行に達します。
上位 1% のユーザーが驚異的な量のコードを作成
p99 データは非常に印象的です：
imageCursor ユーザーの上位 1%（p99）と上位 10%（p90）
Cursor ユーザーの上位 1% は、週あたり約 3 万〜4 万行のコードを生成します！これは、同じ期間に「中央値」の開発者約 45 人が生成する量に相当します。
これらの上位 1% のユーザーがどのように異なるのかを問う価値があります。彼らはグリーンフィールドコードをより多く書いているのでしょうか、ライブラリを使用しない傾向があるのでしょうか、リーダーボードの上位にランクインするためにトークン数を最大化しているのでしょうか？それともバグを 45 倍も生成しているのでしょうか、そして何よりも重要なのは、彼らがリリースするソフトウェアで多くのビジネス価値を生み出しているのでしょうか？
Cursor は、出力トークンの数に対して入力トークンを 10 倍消費します。
これは驚くべきことです：Cursor のトークン使用量の 90% が入力トークスです！つまり、使用されるトークンの大部分は既存のコードベースとドキュメントを読むために使われています。コードの生成は少数派の使用法に過ぎません：
image 入力トークン（コードベースを読むための Cursor）がトークン使用量の大部分を占めています
ある意味で、この使用法は理にかなっています：開発者として、私たちがタイピングしたコード行数と比較して、コードを読むことに費やす時間は常に遥かに多かったです。「読み書きの比率 10:1」というのは古典的な知見です。2008 年、ロバート・C・マーティン（通称「アンクル・ボブ」）が著書『クリーンコード』でこの観察を共有しています：
「確かに、読むことと書くことに費やす時間の比率は 10:1 を遥かに超えています。私たちは新しいコードを書く努力の一環として、常に古いコードを読み続けています…[したがって] 読みやすくすることは、書きやすくすることにもつながります。」
AI エージェントにおけるトークン使用の「読み書き比率 10:1」が今になって現れていることに、私は面白さを感じています。
入力トークスが主な AI トークンコストとなる
入力トークンは出力トークンの一部のみで価格設定されています：例えば、Opus 4.7 は出力トークンに対して入力トークンの 5 倍の料金を請求します（100 万トークンあたり入力トークンで 5 ドル、出力トークンで 25 ドル）。それでもなお、入力トークンがトークン使用量の大部分を占めているため、Cursor では AI コーディングエージェントのコストのうち入力トークンが約 70% を占めています：
image 入力トークンが Cursor のコストを支配する
コンテキストのキャッシュを使用しない場合、トークンコストは 10 倍になります
Cursor は、新しい入力トークンを追加しても古いコンテキストを再生成しないよう、文脈のスマートなキャッシング（cache）を実装しています。このキャッシュ利用を考慮すると、Cursor が出力トークンに費やすのはトークンのわずか 0.6% に過ぎません。残りの 99% は、キャッシュ読み込み（90%）、キャッシュ書き込み（2.5%）、および入力トークン（7%）の間で配分されています：
image キャッシュ読み込みと書き込みを考慮すると、出力トークンはトークン使用量のわずか 0.6% に過ぎません
将来、コンテキストの再利用やキャッシングが AI の効率化における重要な要素となるでしょうか？AI トークンの生成にはコストがかかるため、どのような形での再利用も非常に理にかなっています。特に、既存の文脈を多く再利用するコーディングのようなワークフローではその傾向が強まります。
もちろん、Cursor がこの詳細を共有しているのも理にかなっています。なぜなら、効率的な AI エージェント・ハネス（harness）の構築は決して簡単なことではないと、全員に思い出させるからです。実際、独自のエージェント・ハネスを開発する場合も、Cursor のようなツールの効率性に匹敵する効率的なキャッシング層（caching layer）を整備する必要があります。
Opus は最も高価なモデルであり、Anthropic に悪影響を与える可能性も
公開時点では、Opus 4.7 が最も能力の高いコーディング・モデルと見なされていました。しかし、非常に高価でもあり、Cursor の自社データによると、同社の Composer 2.5 モデルと比較して約 10 倍の費用がかかることが示されています：
imageOpus 4.7 は GPT-5.5 の約 2 倍の費用がかかり、Composer 2.5 と比較するとほぼ 10 倍です。Cursor が単一のエージェント・リクエストのコストを比較している点は重要です。これはトークン同士の直接比較ではありません。また、このベンチマークを共有しているのが Cursor である点にも注意が必要です。Cursor には、自社の Composer モデルが最も低コストに見えるよう動機があるからです。
それでも、10 分の 1 の費用で同等の十分な結果が得られると仮定すれば、これは無視できない節約になります。特に中規模以上の企業にとってはなおさらです。より多くのテック企業が、重要度の低い作業には能力は劣るものの安価なモデルをデベロッパーに使用する方法を見つけることになっても驚きません。
高価なモデルほど採用率が高くなる
Cursor が共有する興味深い指標の一つが、モデルごとの「追加行あたりのコスト」です：
この指標は出力と相関するより現実的なコストです。「賢い」モデルは高価ですが、生成したコードが頻繁に採用される場合、エージェントリクエストあたりのコストという指標ではペナルティを受けますが、ここではそのような扱いを受けていません。
実際、Opus 4.7 は、GPT-5.5 と同じ「1 行あたり採用されたコードのコスト」を持ちながら、エージェントリクエストあたりのコストは半分です。この比較において、Cursor の Composer モデルは「わずか」5 倍の効率性しか持っていません。
両方のリストから欠落しているのは Google の Gemini モデルで、これは Cursor による奇妙な省略です。私は Cursor に問い合わせたところ、Gemini が除外された理由は単に、同社のプラットフォーム上でこのモデルの使用頻度が極めて低いこと、および同様に使用頻度の低い Grok モデルと同様の状況であるためだと説明を受けました。
開発者が手動レビューなしで AI による変更をほぼ半数が採用
私は最も興味深い部分を最後に残しました：わずか 1 か月で、Cursor を使用する開発者の間で、AI エージェントが手動ステップを経ずにコミットを作成することを許可していた割合は 10% から、開発者自身がコードを直接確認しなくなった人が約 40% にまで増加しました。
この急増は、Opus 4.7 と GPT-5.5 のリリース時期と一致しており、多くの開発者がこの世代のモデルによるコード生成能力を実感した結果、「手動でコードを書くことは死に絶えている」と結論付けた時期とも重なります。
詳細は Cursor の完全版レポートをご覧ください。このデータを公開してくれたチームに感謝します！
この抜粋が含まれる『The Pulse』の完全号をお読みいただくか、今日の最新号をチェックしてください。今日の号では以下を取り上げています：
Fable による Bun の Rust 書き換えから何を学べるか？
Anthropic の Fable、OpenAI の GPT-5.6 Sol、Cursor の Grok 4.5、Meta の Muse
北朝鮮のハッカーがフルリモート企業への侵入を試み続けています
業界パルス：Meta のキーロギングで機密データが露見、Xbox で大規模な人員削減、Google から十分な AI 容量を確保できなかった Meta、Qualcomm が Modular を買収、メモリ価格の高騰が Apple 製品に打撃。
原文を表示
Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics a past The Pulse issue. Full subscribers received the article below five weeks ago. If you’ve been forwarded this email, you can subscribe here.
Cursor has just released a new report based on two years of its aggregated usage data, and there are some interesting findings:
Power users generate 10x as many lines of code vs the median
imageSource: CursorThe median dev using Cursor (the p50) generates about 700 lines of code per week with it, while for the 90th percentile, it’s closer to 9,000 lines.
Top 1% of users create incredible volume of code
The p99 data is pretty stunning:
imageThe top 1% of Cursor users (p99) vs the top 10% (p90)The top 1% of users generate around 30-40K lines of code per week! That’s the equivalent of what ~45 “median” devs generate in the same period.
It’s worth asking how these top 1% of users are different. Are they writing a lot more greenfield code, do they have a bias for not using libraries, are they tokenmaxxing to get to the top of leaderboards? Do they generate 45x as many bugs, and importantly: are they adding a lot of business value with the software they ship?
Cursor consumes 10x more input tokens than it generates in output tokens
This is surprising: 90% of Cursor’s token usage is input tokens! This means that most of the tokens used are for reading the existing codebase and documentation. Outputting of code is a minority usage:
imageInput tokens (Cursor reading the codebase) is the bulk of token usageIn some ways, this usage makes sense: as devs, we always spent far more time on reading the code, compared to lines of code we typed out. The “10:1 read-to-write” ratio is a classic. Here’s Robert. C. Martin (aka “uncle Bob”) sharing this observation in 2008, in his book, Clean Code:
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code… [Therefore] making it easy to read, makes it easier to write.”
I find it amusing that we’re now seeing this 10:1 read / write ratio for token usage with AI agents!
Input tokens become the main AI token cost
Input tokens are priced at a fraction of output tokens: for example, Opus 4.7 charges 5x more for output tokens than for input tokens ($5 per 1 million input tokens and $25 per 1 million output tokens). Still, thanks to input tokens dominating token usage, Cursor is seeing input tokens account for closer to 70% of the cost of AI coding agents:
imageInput tokens dominate Cursor costsWithout caching context, token cost would be 10x higher
Cursor does smart caching of context, to avoid re-generating old context with more new input tokens. When taking cache usage into account, Cursor only spends 0.6% of tokens on output tokens. The remaining 99% is split between cache read (90%), cache write (2.5%), and input tokens (7%):
imageOutput tokens are only 0.6% of token usage when considering cache reads & writesI wonder if context reuse and caching will be a key AI efficiency component in the future? AI tokens are expensive to generate, so any form of reuse will make a lot of sense, especially in workflows like coding where a lot of existing context is reused.
Of course, Cursor sharing this detail also makes sense, as they remind everyone that building an efficient AI agent harness is far from trivial. Indeed, if you roll your own agent harness, you also need to put an efficient caching layer in place to match the efficiency of tools like Cursor.
Opus is the most expensive model & could hurt Anthropic
At the time of publishing, Opus 4.7 was still considered the most capable coding model. However, it’s also very expensive, and Cursor’s own data shows it’s close to 10x more expensive than its own Composer 2.5 model:
imageOpus 4.7 is twice as expensive as GPT-5.5 & nearly 10x more than Composer 2.5It’s significant that Cursor compares the cost of a single agent request; it’s not a direct token-to-token comparison. And it’s worth noting this benchmark is being shared by Cursor, which has an incentive for its Composer model to appear the lowest-cost.
Still, assuming you can get similar-enough results with a 10x cheaper model, it is a saving that’s hard to ignore, especially for mid-sized and above companies. I would not be surprised if more tech companies find ways for devs to use less capable – but cheaper – models for less critical work.
More expensive models result in higher acceptance rates
An interesting metric Cursor shares is cost-per-line-added, per model:
imageThis metric is a more realistic cost because it correlates to output: “smart” models that are expensive, but which produce code that is frequently accepted, are penalized by the cost-per-agent-request metric, but they’re not here.
Indeed, Opus 4.7 has the same cost-per-line-accepted as GPT 5.5 at half the cost per agent request. In this comparison, Cursor’s Composer model is “only” 5x as efficient.
Missing from both lists are Google’s Gemini models, a strange omission by Cursor. I reached out to Cursor and they told me that Gemini was left out simply because they see very little usage of this model on their platform, similar to the sparsely used Grok model.
Almost half of AI changes accepted without manual review by devs
I’ve left the most interesting part of this report to last: in just a month, among devs using Cursor, it has gone from 10% who let AI agents create commits without a manual step, to around 40% of devs who no longer personally check the code:
imageThe jump correlates with Opus 4.7 and GPT-5.5 being released, and around the time when many devs seem to have concluded that writing code by hand is dying after experiencing this generation of models’ capability at generating code.
Check out the full report from Cursor for more details. Thanks to the team for releasing this data!
Read the full issue of The Pulse this excerpt is from, or check out the latest The Pulse from today. Today's issue covers:
Bun’s Rust rewrite with Fable: what can we learn?
Anthropic’s Fable, OpenAI’s GPT-5.6 Sol, Cursor’s Grok 4.5, Meta’s Muse
North Korean hackers keep trying to infiltrate full-remote companies
Industry Pulse: Meta’s key logging exposed sensitive data, massive cuts at Xbox, Meta could not buy enough AI capacity from Google, Qualcomm acquires Modular, and memory price hikes hit Apple products.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み