Cursor Reveals Developer AI Token and Code-Volume Patterns

Cursor's two-year aggregated usage data reveals that 90% of its token consumption is input tokens, with a 10:1 read-to-write ratio, and that the top 1% of users generate 30,000-40,000 lines of code per week, compared to a median of 700 lines. The findings highlight that AI coding costs are driven more by reading existing code than by generating outputs, and that a small cohort of power users accounts for outsized code volume, affecting cost modeling and productivity measurement for engineering teams.

Cursor Reveals Developer AI Token and Code-Volume Patterns 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. Try 250 free problems /problems