For practitioners, Cursor's usage signals two operational realities that affect cost modelling and productivity measurement: token bills are driven more by reading existing code than by generated outputs, and a small cohort of "power users" account for outsized code volume. Reported facts: Per a Pragmatic Engineer post summarizing Cursor's two-year aggregated usage data, the median Cursor user generates about 700 lines of code per week while the 90th percentile is near 9,000 lines, and the top 1% produce roughly 30,000-40,000 lines per week. The same report finds that 90% of Cursor's token consumption is input tokens, a roughly 10:1 read-to-write token ratio, and notes that input tokens are priced at a fraction of output tokens; Pragmatic Engineer cites Opus 4.7 as charging 5x more for output tokens.
Editorial analysis
This data set surfaces two operational levers that matter to engineering teams and platform owners: cost exposure from context-reading and the heavy-tailed nature of AI-assisted coding productivity. Teams tracking AI spend or designing chargeback should treat token-read volume and a small set of high-usage developers as primary drivers of consumption, not just generated outputs.
What happened
Per a Pragmatic Engineer blog post summarizing Cursor's two-year aggregated usage data, the median Cursor user (p50) generates about 700 lines of code per week, the 90th percentile (p90) is close to 9,000 lines, and the top 1% (p99) produce roughly 30,000-40,000 lines per week. The post reports that 90% of Cursor's token usage is input tokens, implying an observed 10:1 read-to-write token ratio. The writeup also notes that input tokens are priced at a fraction of output tokens and cites Opus 4.7 as an example that charges 5x more for output tokens (Pragmatic Engineer).
Industry context
Companies instrumenting agent or assistant usage often under-estimate the cost of context because reading repositories, documentation, and history accumulates tokens quickly. Observed token ratios like 10:1 convert directly into billing dynamics when input context is large or when assistants rehydrate long histories for reasoning.
For practitioners
Pay attention to token composition when forecasting costs; instrument input-token counts separately from output-token counts. Also plan analytics for user-level skew: Cursor's p99 producing roughly 45x the median developer's lines suggests a small group can dominate consumption and therefore influence cost-optimization priorities and quota policies.
What to watch
Metrics teams should monitor per-user token breakdowns, common context sizes that drive input-token spikes, and whether top users are producing high-quality, reviewable output or generating noise that increases downstream review cost. The original post quotes Robert C. Martin to connect the historical read/write time ratio to the token read/write ratio observed today (Pragmatic Engineer).
Key Points #
- 1Industry context: Token bills are often dominated by input/context tokens, so read-heavy workflows can drive unexpectedly high costs.
- 2Industry context: Developer usage is heavy-tailed; p99 users can generate tens of thousands of lines weekly, concentrating consumption and operational risk.
- 3For practitioners: Track input vs output token usage per-user and instrument top-percentile consumers to focus cost controls and quota design.
Scoring Rationale #
Cursor's usage data highlights measurable cost and productivity patterns that matter to engineering teams and platform owners, but the findings are operational rather than paradigm-shifting.
Sources #
Public references used for this report. Practice interview problems based on real data
1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with.