Cursor vs Windsurf vs Claude Code — 12-org productivity benchmark.

The bake-off methodology that twelve orgs agreed to share

The procurement RFP that anchored the study was drafted by Priya Venkatesan, head of developer productivity at the financial services subsidiary that ran the original internal version in Q4 2025. Venkatesan circulated the methodology on the Developer Productivity Engineering Discord in early January 2026, and eleven additional organisations signed an information-sharing memorandum agreeing to run the identical protocol and pool the aggregated results. The agreement permitted each organisation to keep individual-engineer telemetry private while sharing the per-workload aggregate metrics, the procurement decision, and the qualitative debriefs from the post-trial review meeting. The dataset that emerged covers 1,847 engineers across the twelve organisations and 12,400 measured pull requests over the trial window.

The workload categories were defined precisely to avoid the most common bake-off failure: each team gravitating toward the workload its preferred tool handles well. The greenfield category required a feature spec of between 1,800 and 2,400 lines of code at completion, with a defined acceptance test suite written before the trial began. The refactor category required a 600-1,200 line change across at least four files, touching at least one shared utility module. The bug-fix category drew tickets from a queue of pre-triaged backlog issues each organisation maintained, with severity bands normalised across teams. The migration category was the most prescriptive: a database schema change with at least three downstream service consumers and a defined rollback plan. The code-review category measured turnaround time, review-comment density, and the rate at which the reviewer flagged an issue the original author had not caught. Each engineer rotated through the same workload using each of the three platforms in randomised order, with a 48-hour cooldown between trials of the same workload to reduce contamination.

The procurement criteria the RFP required each organisation to weight independently were: cost-per-PR-merged on the realistic 90-day workload mix, developer satisfaction NPS at trial end, integration overhead with the existing developer infrastructure (CI providers, code hosts, observability stacks), administrative controls (audit logs, model selection, prompt template enforcement, data residency), and a forward-looking criterion called platform trajectory — defined as the procurement officer's confidence that the vendor would still be the right choice in twelve months. The trajectory criterion was the most subjective and the most consequential. Three of the twelve organisations made their final selection on trajectory grounds despite a different platform winning on cost-per-PR. None of the twelve treated the developer NPS as the primary input. The procurement officers were uniform in their position that engineer preference, while informative, was downstream of total cost of ownership over the contract horizon.

The pricing data the study captured is more granular than the public pricing pages reflect. Cursor's Business tier at $40 per seat per month in Q1 2026 was negotiated below list at every organisation above 250 seats, with the negotiated price ranging between $28 and $33 per seat depending on commitment length and reference-customer willingness. Windsurf's Teams tier at $35 per seat per month carried a less aggressive discount curve, with negotiated prices ranging between $30 and $32 per seat for the same volume tier. Claude Code's pricing in Q1 2026 was structured differently — a base seat license of $30 per month plus metered usage against the Anthropic API, with the typical engineer's metered consumption running between $22 and $48 per month depending on workload mix. The implied all-in cost per Claude Code seat at the median ran higher than Cursor or Windsurf at the same seat count, but the cost-per-PR-merged calculation reversed the ordering once the productivity delta was factored in.

Greenfield vs refactor: where the platforms split

The greenfield feature category produced the cleanest separation between the three platforms, and the result is not what the marketing materials would predict. Cursor won the greenfield workload at eight of twelve organisations on the time-to-first-passing-test metric — an average of 41 per cent faster than the second-place finisher in the same organisation. The Cursor advantage on greenfield was concentrated in the early scaffolding phase: the first 90 minutes of a new feature, where context windows are unconstrained, the codebase touchpoints are minimal, and the model can generate substantial code from a high-level spec without needing to reason about existing patterns. Windsurf placed second at six of those eight organisations, and Claude Code placed third. The greenfield workload is the workload Cursor's product team has optimised against most explicitly, and the data confirms that optimisation has translated into a measurable productivity edge in the early-feature regime.

The refactor category inverted the ordering. Claude Code won the refactor workload at nine of twelve organisations on the metric the procurement officers cared about most: the rate at which the refactor PR merged without requiring a follow-up correction PR within the next 30 days. Claude Code's correction-PR rate on refactors averaged 11 per cent. Cursor's averaged 28 per cent. Windsurf's averaged 24 per cent. The procurement officers read this as a quality signal that the headline velocity numbers obscured: Cursor and Windsurf could generate the refactor faster, but the resulting change required follow-up engineering work at meaningfully higher rates. When the procurement officers re-priced the cost-per-PR metric to amortise the follow-up correction work into the per-PR cost, Claude Code moved from third place to first place on refactor cost-per-PR at ten of twelve organisations. The lone exception was a startup whose refactor workload was heavily concentrated in TypeScript codebases of under 50,000 lines, where the correction-PR rate gap narrowed to within statistical noise.

The bug-fix category produced the narrowest separation. All three platforms posted bug-fix throughput within 12 per cent of one another at every organisation in the study. The procurement officers consistently flagged this category as the least diagnostic for vendor selection, because the bug-fix workload at most organisations decomposes into a high volume of small, well-scoped issues where any of the three platforms produces acceptable results. The qualitative debriefs surfaced a more interesting signal: developers reported that the platform they preferred for greenfield was rarely the platform they preferred for bug-fix work. The engineers at the four Fortune 500 organisations were the most likely to prefer different tools for different workloads, and several engineering managers in those organisations argued during the procurement review that a multi-tool entitlement — Cursor or Windsurf for greenfield, Claude Code for refactor and migration — would produce the best aggregate productivity even at the cost of higher per-seat licensing.

The migration category was the workload where Claude Code's lead was widest and least contested. Database schema migrations with multiple downstream consumers require the platform to reason about a long horizon of consequence: a model that generates a fast migration that breaks a downstream consumer two services away does not produce a usable result. Claude Code's longer-context architecture and its more aggressive use of tool-call chains to inspect downstream consumers before recommending a migration step produced a 62 per cent lower rate of post-migration incident at the seven organisations that ran the migration workload to completion. Cursor's migration performance trailed substantially. Windsurf's was closer to Claude Code than to Cursor, but Windsurf's review-comment density on migration PRs ran 40 per cent higher than Claude Code's, suggesting that Windsurf's outputs required more human review work to clear the same quality bar. The procurement officers at the three Fortune 500 organisations with the heaviest migration loads — two were running multi-year monolith-to-microservices decomposition projects — weighted migration performance as the single most important workload category, and all three selected Claude Code on those grounds.

The cost-per-PR economics that reordered the decisions

The cost-per-PR-merged metric was the input that drove the largest number of procurement decisions, and the way the three platforms decomposed on that metric tells a more complete story than any single workload comparison. At the median organisation in the study, an engineer using Cursor merged 14.3 PRs per week during the trial. The same engineer using Windsurf merged 13.1 PRs per week. The same engineer using Claude Code merged 11.8 PRs per week. On raw volume, Cursor and Windsurf produced more output. The cost-per-PR calculation that the procurement officers ran factored in the all-in seat cost, the metered consumption (for Claude Code), and the follow-up correction PR rate within 30 days. Cursor's median cost per merged PR at the negotiated business-tier price was $4.12 — and rose to $5.27 when correction PRs were amortised in. Windsurf's median was $4.61, rising to $5.71. Claude Code's median was $5.84, falling to $5.42 when correction PRs were amortised in.

The procurement reframe — moving from cost-per-PR-merged-as-shipped to cost-per-PR-merged-net-of-correction — flipped the cost ordering at seven of twelve organisations. Cursor's nominal cost advantage narrowed substantially. Claude Code's nominal cost disadvantage inverted. The procurement officers who ran the analysis at higher granularity broke the calculation down further: separate cost-per-PR figures for greenfield, refactor, bug-fix, and migration. The disaggregated view produced procurement decisions that were workload-weighted rather than monolithic. Six of the twelve organisations selected a primary platform and then provisioned a secondary platform for a subset of engineers whose workload mix justified it. The most common pattern was Cursor as primary with Claude Code provisioned for the platform engineering and SRE subteams whose work was heavily refactor- and migration-weighted.

The developer satisfaction NPS data complicated the cost analysis in ways that the procurement officers had to absorb rather than resolve. The aggregate NPS across the twelve organisations was 61 for Cursor, 54 for Windsurf, and 47 for Claude Code. The Cursor NPS lead was driven primarily by the in-editor experience and the perceived speed of the autocomplete loop. The Claude Code NPS lag was driven by two factors: a steeper learning curve for engineers who came in with no terminal-fluency baseline, and a tendency for the platform to ask clarifying questions before generating code that some engineers interpreted as friction rather than care. The procurement officers who selected Claude Code despite the NPS gap typically argued that NPS is a leading indicator of adoption but a lagging indicator of productivity, and that the productivity numbers were the constraint that mattered. The procurement officers who selected Cursor despite Claude Code's stronger productivity numbers on refactor and migration typically argued that low engineer NPS produces compliance problems — engineers who do not like a tool find ways to use it less, regardless of mandate.

The four Fortune 500 organisations in the study landed on two distinct strategies. Two of them selected Cursor as the enterprise-wide platform on adoption-velocity grounds. Two of them selected Claude Code on cost-per-PR-merged-net-of-correction grounds, with a deliberate plan to invest in adoption tooling — internal training, paired-programming rotations with the developer productivity team, and bonus structure adjustments that rewarded refactor PRs at higher weight than greenfield PRs. Both Claude Code adopters reported that the adoption curve through April 2026 was slower than the Cursor adopters reported, but their cost-per-PR trajectory was on track to deliver projected annual savings of $3.8M to $5.2M depending on the engineering headcount projection through Q4 2026. The trade-off between adoption velocity and per-PR economics is the trade-off that will define this segment of the procurement market for the next eighteen months.

What the twelve organisations actually decided

The procurement decisions cluster into three groups, and the clustering is more informative than any single org's choice. Five of the twelve organisations — concentrated among the Series B startups and one Series D — selected Cursor as the primary platform. The pattern in this group is consistent: engineering organisations heavily weighted toward greenfield feature work, with relatively thin platform engineering bench, where the developer NPS advantage compounds because the developer productivity team is too small to push back against engineer preference. Cursor's product strategy is calibrated to this segment, and the procurement outcomes reflect that calibration. The negotiated pricing at this tier averaged $31 per seat per month for the business tier, with one organisation securing a $26-per-seat price in exchange for a reference customer commitment. The contract terms in this segment were uniformly 12-month with a renewal option.

Four of the twelve organisations — concentrated among the Fortune 500 engineering divisions and two of the Series D growth-stage companies — selected Claude Code as the primary platform. The pattern in this group is also consistent: engineering organisations with significant refactor and migration loads, mature developer productivity teams capable of running adoption programmes, and procurement officers who weight 24-month total cost of ownership over 6-month adoption velocity. The metered pricing structure was a procurement friction point but not a deal-breaker; all four organisations negotiated metered consumption caps and unlock thresholds that produced predictable monthly billing within a 15 per cent variance band. The contract terms in this segment were uniformly 24-month with year-two renewal options that included rate cards refreshed quarterly.

Three of the twelve organisations adopted a multi-platform strategy, provisioning two of the three tools to different engineering populations. The most common configuration was Cursor for product engineering teams and Claude Code for platform engineering and SRE teams. The second configuration, adopted by one Series D growth-stage company, was Windsurf as the default tool with Claude Code provisioned for the data engineering subteam whose work was heavily migration-weighted. The multi-platform strategy added administrative overhead — separate procurement contracts, separate security reviews, separate adoption programmes — and the engineering leaders who adopted it argued that the overhead was justified by the productivity gain at the per-team level. The procurement officers in this group were the most willing to revisit the strategy at the 12-month mark, and several flagged that a future contract cycle might consolidate to a single platform if one of the three vendors closed the workload-specific gaps the multi-platform configuration was designed to address.

Windsurf finished without a primary-platform selection at any of the twelve organisations, which is a sharper outcome than the marketing position would predict. The procurement officers consistently rated Windsurf as a credible alternative to Cursor on greenfield work, but the cost-per-PR delta was insufficient to justify a switch from Cursor for the organisations that prioritised greenfield, and Windsurf's refactor and migration performance trailed Claude Code by margins that the procurement officers found difficult to bridge. The qualitative debriefs surfaced a recurrent theme: Windsurf's product trajectory in Q4 2025 and Q1 2026 — particularly the feature releases under the new Codeium leadership team — had not yet produced a workload category where Windsurf was the clear leader. The procurement officers were uniformly willing to revisit Windsurf at a future cycle, but the present cycle did not produce a Windsurf primary selection. The implication for Codeium's competitive position is that the next twelve months will be defining: closing the refactor and migration gap to Claude Code or extending the greenfield lead over Cursor are the two strategic options that would produce a different bake-off outcome.

The trajectory criterion that overrode the data twice

The procurement criterion that the RFP labelled platform trajectory deserves a separate examination, because it was the input that overrode the quantitative data at three of the twelve organisations. The trajectory criterion asked procurement officers to rate, on a five-point scale, their confidence that each vendor would still be the right choice in twelve months. The criterion was deliberately subjective. It captured the procurement officer's read on vendor financial health, product strategy coherence, distribution moat, and exposure to incumbent disruption. Anthropic scored highest on trajectory across the study — a median rating of 4.6 — driven by a combination of Claude model momentum, the Anthropic enterprise sales motion's maturity, and the absence of meaningful pricing pressure from the model layer below. Cursor scored second at 3.9, with procurement officers noting concern about Cursor's exposure to model-layer commoditisation and the lack of a defensible distribution moat outside the IDE surface. Windsurf scored lowest at 3.2, with procurement officers flagging the Codeium acquisition transition and the relative narrowness of the Windsurf positioning in a segment where Cursor's brand recall and Claude Code's vertical integration each provide more durable positioning.

The three organisations where trajectory overrode the quantitative data were all Fortune 500 engineering divisions. In each case, the procurement officer selected Claude Code over Cursor despite Cursor winning on time-to-first-passing-test and developer NPS. The argument the procurement officers articulated was consistent: a multi-year enterprise contract is a bet on the vendor's trajectory more than on the present product, and the trajectory analysis produced a different ordering than the workload analysis. The procurement officer at one of the financial services Fortune 500 divisions phrased the position precisely during the post-trial debrief: the team was not buying a tool, it was buying a six-year relationship with a vendor whose product would change four times over the contract horizon, and the trajectory question was therefore the substantive question that the workload comparison was a proxy for. The other two organisations articulated similar positions, and the consistency of the trajectory argument across three independent procurement processes was the dataset's most consequential finding for the vendors competing in the segment.

The implication for Anthropic, Cursor, and Codeium is that the procurement market is bifurcating along a horizon dimension as much as a workload dimension. The buyers selecting on twelve-month productivity outcomes are choosing differently from the buyers selecting on six-year vendor trajectory. The buyers in the former group skew toward startups and growth-stage companies with shorter contract horizons and more flexibility to switch. The buyers in the latter group skew toward Fortune 500 organisations with longer contract horizons and higher switching costs. The product strategies that win in one segment may not win in the other, and the vendors that try to win in both will face the strategic question of whether to bias their roadmap toward immediate workload performance or toward the credibility signals — financial health, governance maturity, model layer ownership — that the trajectory buyers weight most heavily. Anthropic's vertical integration into the Claude model layer is the structural advantage in the trajectory segment. Cursor's IDE distribution is the structural advantage in the workload segment. Windsurf's position in the trajectory segment is the more pressing concern, and the procurement data from the present cycle suggests that without a strategic move that reframes the Windsurf trajectory story, the next cycle will produce similar outcomes.

What to watch

The twelve organisations in the study committed to a follow-up data share in October 2026, six months after the procurement decisions were made. The October dataset will be the first opportunity to measure whether the procurement decisions held up against actual production usage rather than trial conditions, and the dataset will be more informative than the trial data because the variables that trial conditions suppress — adoption resistance, vendor account-management quality, real-world workload mix — operate freely once the tool is in production.

• Whether the Claude Code adopters in the Fortune 500 cohort hit the cost-per-PR projection that justified the selection over Cursor; the projection assumed an adoption ramp that several of the procurement officers described as aggressive, and a missed ramp would erode the cost advantage that the trajectory argument was designed to compound.
• Whether the multi-platform organisations consolidate to a single platform at the 12-month renewal mark; the administrative overhead of running two procurement contracts, two security reviews, and two adoption programmes is justified only if the per-team workload advantage continues to compound, and consolidation would signal that the vendors have closed the workload-specific gaps the multi-platform configuration was designed to address.
• Whether Windsurf produces a credible workload-category win — refactor, migration, or a new category that the platform creates — that would reframe its trajectory rating in the next procurement cycle; without a workload win, the Windsurf position depends on Cursor stumbling or Anthropic mispricing, neither of which is a strategic posture a Codeium leadership team can rely on.
• Whether Cursor responds to the refactor and migration performance gap with a product release that closes it, or whether the Cursor product team continues to optimise for greenfield work on the assumption that the segment splits cleanly enough to defend; the strategic decision is not obvious, because closing the refactor gap would require investment that does not improve the metric Cursor's NPS lead currently rides on.
• Whether the trajectory criterion holds its weight in the next procurement cycle; if the financial-services and industrial Fortune 500 buyers continue to weight trajectory above near-term productivity, Anthropic's structural advantage compounds, and Cursor's path to enterprise share in those segments narrows to a financial-engineering question — pricing aggressively enough to compensate for the trajectory gap — that the present pricing data suggests Cursor is not yet running.

Frequently asked

Why did Windsurf finish without a primary-platform selection at any of the twelve organisations?

Windsurf's product was rated as a credible alternative to Cursor on greenfield work, but the cost-per-PR delta was insufficient to justify a switch from Cursor at the organisations weighting greenfield, and Windsurf's refactor and migration performance trailed Claude Code by margins the procurement officers could not bridge. The qualitative debriefs surfaced a structural finding: Windsurf had not produced a workload category in which it was the clear leader, and primary-platform selection requires a workload anchor. Several procurement officers indicated willingness to revisit Windsurf at the next cycle if the Codeium leadership team produced a workload-defining release.

What is the cost-per-PR-merged-net-of-correction metric, and why did it flip the cost ordering?

The metric measures the per-PR cost of merged work amortised against the rate at which a follow-up correction PR is required within 30 days. The reframe captures the engineering cost of fixing a PR that merged but did not produce production-quality output. Claude Code's correction-PR rate on refactor work was 11 per cent versus 28 per cent for Cursor, and amortising the correction work into the per-PR cost moved Claude Code from third place to first place on refactor cost at ten of twelve organisations. The metric is a more honest signal than nominal velocity for procurement decisions on the 24-month horizon, because the correction work is real engineering cost that the nominal-velocity metric obscures.

How did the trajectory criterion override the quantitative data at three Fortune 500 organisations?

The trajectory criterion asked procurement officers to rate vendor durability over a twelve-month horizon. Anthropic scored 4.6, Cursor 3.9, Windsurf 3.2 on the five-point scale. Three Fortune 500 procurement officers selected Claude Code over Cursor despite Cursor's stronger workload data, on the argument that a multi-year enterprise contract is a bet on vendor trajectory more than on present product. The procurement reasoning was that the product will change four times over the contract horizon, so the question is which vendor's product will still be the right choice when the contract reaches year three. The trajectory argument is not a deflection from the data; it is a different read of the data, weighted on a longer horizon.

Why did three organisations adopt a multi-platform strategy instead of selecting one tool?

The multi-platform organisations had workload mixes that decomposed cleanly into greenfield-heavy product engineering teams and refactor-heavy platform engineering teams. The procurement officers in this group argued that the productivity gain from matching the tool to the workload exceeded the administrative overhead of running two procurement contracts. The most common configuration was Cursor for product engineering and Claude Code for platform engineering and SRE. The strategy adds friction at the security review and identity management layer, and several of the procurement officers in this group flagged that consolidation to a single platform at the 12-month renewal mark is plausible if the vendors close the workload-specific gaps.

How did the metered pricing structure of Claude Code affect the procurement decisions?

The metered consumption model produced procurement friction at all four organisations that selected Claude Code, but it did not produce deal-breaker friction. All four organisations negotiated metered consumption caps and unlock thresholds that produced predictable monthly billing within a 15 per cent variance band. The procurement officers initially preferred the flat-seat pricing of Cursor and Windsurf, but the cost-per-PR analysis revealed that the metered structure was actually more economically efficient at the workload mixes these organisations ran, because heavy refactor and migration users justified the consumption while light bug-fix users consumed less and the average evened out at a competitive per-PR figure.

What does the developer NPS gap between Cursor and Claude Code imply for the procurement decisions?

The NPS gap — 61 for Cursor versus 47 for Claude Code — is real and reflects a steeper learning curve and a different interaction model in Claude Code that some engineers interpret as friction. The procurement officers who selected Claude Code despite the NPS gap typically argued that NPS is a leading indicator of adoption but a lagging indicator of productivity, and that the productivity data was the binding constraint. They also committed to investing in adoption tooling — internal training, paired-programming rotations, bonus structure adjustments that reward the workloads Claude Code wins on. The trade-off between near-term engineer satisfaction and longer-term cost-per-PR economics is the trade-off that will define the segment for the next eighteen months.