The State of Cursor Adoption 2026

The benchmark targets the numbers teams actually argue about when they bring Cursor in: what a developer really costs under the credit model, how much time the tooling saves, where people spend their sessions and whether anyone has written the work down as policy. Each item below maps to a survey question.

• Real cost per developer per month under the credit model, versus the advertised $20/$60/$200.
• Time saved and PR-throughput change after adopting Cursor.
• Ask vs Agent usage split: which surfaces teams actually use.
• Policy maturity: what share of teams have a written AI-coding policy and spend caps.
• Release adoption: which teams have adopted Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition., Automations, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition., Design ModeA way to point at an element in Cursor's built-in browser and change it directly, instead of describing it in words. Press Enter for the full definition., Canvas and Organizations controls.
• Teams pricing shape: how Standard/Premium seats, Auto + ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. usage and third-party API pools affect real team cost.
• The hybrid stack: how many teams run Cursor and Claude Code together.

Cost sits at the top of that list because it is the question that stalls a rollout, and, as far as I can tell, the one teams answer least accurately. The advertised tier is an allowance, not a bill. What gets spent moves with the model mix and with whether usage-based pricing is switched on, so a team can name its plan correctly and still be a long way off on cost per developer. We ask for what the invoice said.

Two of these questions exist because adoption gets overstated in predictable ways. A team that has adopted Agent can still spend most of its sessions in Ask, and a team running Cursor next to Claude Code can report the cost of only one of them.

Three sources, combined transparently: a recruited survey of engineering teams, anonymized and aggregated usage signals from Learn Cursor learners (opt-in, no identifying data) and curated public benchmarks for context. We publish sample size, collection dates and method alongside every figure.

Three sources rather than one, because each covers a gap the others leave open. Survey answers are self-report, which is fine as far as it goes: they capture what a team believes about its own setup. The learner signal is behavioral and narrow at the same time, since it comes from people who arrived here to learn Cursor and it sees nothing inside a team's own install. Public benchmarks give the outside line to check both against.

If you run Cursor on a team, you can contribute to the benchmark. Participants get the full results first. Reach us via the contact page to join the survey panel.

Send this to whoever can see the billing page. That covers half of it at best, because the policy question gets answered somewhere else, usually by whoever owns security or engineering ops. On a larger org, expect one response to need two authors. Small teams have the reverse problem, where one person knows all of it and their single answer ends up standing in for the whole company.

We would rather have one considered response per team than ten from the same company.

Original research is only useful in context. This report will contrast its own survey findings with figures Cursor has already published. The numbers below are external reference points, not results from this study.

The three eras of AI coding

Cursor frames its own story as a maturity curve through three stages. The survey asks where each team actually sits on this curve today.

The part worth pushing back on is reading those three eras as a clean sequence. A team can sit in the third era on a service nobody depends on yet and in the first era on the payments code, and averaging the two produces a number that describes neither. When you place your own team on this curve, pick one repository and answer for that.

The mindset shift Cursor describes

By the third era the developer is directing Cloud agents and reviewing the PRs they open, not editing line by line in the editor. Cursor's claim is that the day moves from writing each line to setting intent and acceptance criteria, then checking what the agent returns. The survey measures how many teams actually work that way versus how many are still keystroke by keystroke.

A direct consequence Cursor names: as agents write more of the code, review becomes the new bottleneck. Throughput is gated less by how fast humans type and more by how fast they can verify, correct and merge agent output. The survey measures whether teams report review, not generation, as their constraint.

Named public figures we'll contrast against

Cursor has put several specific numbers on the record. The table pairs each one with the question the survey asks instead, so you can see exactly where a vendor claim ends and an independent measurement begins. Read the left two columns as Cursor's, the right column as ours.

Independent and scale reference points

One outside data point we contrast against is a University of Chicago study of about 1,000 organizations. After teams made Cursor's Agent the default way to work, the study reported roughly +39% organizational output and +39% merged pull requests. The same study found experienced developers accepted more agent-written code than juniors did. The authors' read is that senior engineers plan the work first, so what the agent produces lands closer to something mergeable.

We treat the Chicago numbers as a single external study, not proof of what any given team will see. The survey exists precisely to test that gap. For a fuller breakdown of the enterprise figures, see the Cursor enterprise results write-up at /research/cursor-enterprise-results. For how to read any productivity claim (including the +39% output number and what "merged PRs" actually measures), see measuring AI coding productivity at /research/measuring-ai-coding-productivity.

None of these reference points tell you what the gain cost. CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. Press Enter for the full definition. comes nearest, and it is Cursor's internal benchmark for comparing models rather than something a team can run against its own invoice. An output number paired with a spend number is what the survey is trying to add, and it is also the pair teams find hardest to produce.

Who actually holds the seats, and is it only engineers?

Most adoption framing assumes a Cursor seat equals a software engineer. Cursor's own positioning has widened past that. The company now describes its target as professional software engineering teams rather than individual professional software engineers. A team includes the PMs, designers and sales engineers who sit alongside the people writing the bulk of the code. The survey asks teams to report their actual seat mix, not just headcount.

Read that as a vendor statement about its largest customers, not a finding from this study. It still reframes the cost-per-developer question: if roughly a fifth of seats at the biggest accounts go to non-engineers, then per-engineer cost and per-seat cost diverge, and a policy written only for engineers misses a real slice of usage. The survey captures the split so teams can price and govern against who's actually in the tool.