Cursor Pricing: The Procurement Model Behind the Flat Per-Seat Number
An honest cost-modelling read on Cursor's Free, Pro, Business, and Enterprise tiers — what fast premium requests actually mean, what triggers overage, the worked example for a 20-engineer team, and where Cursor's per-seat model wins and loses against Claude Code and Copilot.
The Berlin finance partner I sat with last quarter had the Cursor proposal in front of her — a clean per-seat number, the headcount, the annual commitment, the Enterprise Agreement-style contract her team knew how to process. Procurement-shape, the easy decision. Three months earlier the same finance team had pushed back hard on a Claude Code line item because the usage-based pricing did not fit their modelling shape. The CTO was about to approve the Cursor proposal in the meeting when the head of engineering walked her through what the team’s actual agent usage looked like once Composer-heavy engineers started burning through the included allowance. The Year 1 estimate rose meaningfully above the headline seat cost once realistic on-demand usage and power-user needs were modelled in. The lesson was the same one every Cursor procurement runs into: the per-seat number is honest as far as it goes, and it does not go as far as a finance team modelling from the pricing page assumes.
That is the gap this page is about. Cursor’s pricing is genuinely simpler than Claude Code’s three-billing-mode shape, and the simplicity is a real procurement advantage that the finance function will reward. The simplicity also hides the variable that decides whether the model is right — the fast-premium-request consumption rate at the engineering organisation’s actual workload mix. The pricing-page screenshot will not surface that variable; the engineering organisation has to do it.
This page is the model. Cursor’s four tiers and what each is for, the fast-premium-request mechanics and what triggers overage, the worked-cost example for a 20-engineer team, the Composer Agent cost shape, and where Cursor’s flat subscription wins and loses against Claude Code’s usage-based and Copilot Enterprise’s per-seat models. If you are sizing Cursor for a procurement decision, this is the page that gives you the math the finance partner will sign off on.
The four tiers, briefly
Cursor sells through four tiers, and the procurement decision is which tier covers which population of engineers at what allowance level.
Hobby (Free). A genuine free tier with limited monthly usage — small allowance of fast premium requests, slow-queue access to the premium models, full IDE access. Useful for trial and for solo developers; not viable for professional engineering use at scale. Mention only because the engineering organisation will have some engineers running on Hobby for personal projects.
Pro, $20 per user per month. The individual paid tier. Larger fast-premium-request allowance than Hobby, faster slow-queue access, the Composer Agent included. Pro is the consumer-grade subscription equivalent to Claude Code’s Pro plan. Procurement-wise it has the same friction — it is a personal subscription that procurement cannot easily centralise across an enterprise tenant.
Teams, $40 per user per month. The first procurement-grade tier. Central billing, administration, team privacy controls, usage analytics, and SAML/OIDC SSO. The current public model includes an included usage allotment rather than the older request-count shorthand that many earlier writeups relied on. This is where most procurement-led Cursor rollouts land in 2026, because it clears the billing and identity friction without forcing an enterprise contract immediately.
Enterprise, negotiated pricing. Enterprise plans are priced per seat with an included usage allotment, and Cursor documents options to pre-commit additional usage for high-volume teams while maintaining admin-side cost controls. The contract negotiates the usage shape, which is the procurement-relevant variable, not the per-seat headline.
The procurement choice between Business and Enterprise turns on two questions: whether the organisation needs the audit and admin surface the Business tier does not provide (regulated industries: yes, most others: not yet), and whether the engineering organisation’s fast-premium-request consumption rate exceeds the Business-tier allowance frequently enough to make the Enterprise upgrade cheaper than the overage. Both questions have to be answered against actual usage data, which procurement does not have before signing — which is the chicken-and-egg problem this page exists to help with.
The usage mechanic, demystified
The variable that decides whether the Cursor cost model is right is heavy-user consumption, and the mechanic is worth spelling out because the pricing page necessarily abstracts it.
Cursor’s public model now centers on included usage, optional on-demand usage after the included amount is consumed, and newer team constructs such as premium seats and pre-committed usage for heavier populations. The operational meaning is straightforward: light autocomplete users stay near the headline seat cost; heavy chat and agent users do not.
What matters in practice is that Cursor has separated the baseline seat from the heaviest agent usage. Teams can now buy the $40 seat, then decide whether a subset of engineers needs more included usage, premium seats, or additional committed spend. That is cleaner than the older request-counter framing, but it does not remove the underlying modelling task.
The consumption rate is the variable to model. The shape that matters:
- Autocomplete suggestions are the cheapest workload shape. They rarely stress the plan on their own.
- Chat and inline agent assistance consume included usage faster because they involve longer prompts, more turns, and premium models more often.
- Composer and cloud-agent workflows are the real budget drivers. Multi-file agent work burns materially more usage than autocomplete-shaped work, and a small senior population can dominate the bill if you do not model them separately.
The mid-case modelling assumption that has held up in the engagements I have advised: most engineers stay close to the included seat economics, while a smaller power-user cohort consumes a disproportionate share of paid usage. The overage line on the procurement model is real, and the seat-only model does not match the engineering organisation’s actual workload.
Enterprise plan deltas
The Enterprise tier adds five things that matter to the procurement function above the Business tier.
SAML SSO with policy controls. Business-tier SSO is competent; Enterprise adds finer-grained group-based access controls and policy enforcement that the security team will require for regulated workloads. For a 20-engineer team without that requirement, the Business-tier SSO is adequate; for a 200-engineer enterprise rollout in a regulated industry, the Enterprise tier is the floor.
Audit logging. The Enterprise tier produces audit events at the per-user level with SIEM-export capability — authentication, configuration changes, usage. The CISO will require this for regulated workloads; outside regulation, the requirement is softer and depends on the organisation’s internal control posture.
Centralised admin and provisioning. The Business tier gives admins control over the team membership; Enterprise gives admins control over the policy applied to that membership — model access restrictions, data-handling defaults, project-scoping. For a large rollout, the admin surface saves real platform-engineering time over the year.
Higher and more controllable usage capacity. The Enterprise contract lets the customer negotiate the included usage shape and pre-commit additional spend for high-volume teams. The point is not a universal number; it is cost control for the heavy-user population.
Data-handling guarantees. Enterprise provides explicit data-handling guarantees — no training on customer data, configurable retention, the standard SOC 2 / ISO 27001 attestations, BAA availability for the healthcare-customer cases. The Business tier is competent here but the Enterprise tier is the procurement-grade documentation the legal team will want for regulated workloads.
The Enterprise tier is genuinely worth the premium over Business for any organisation with a real compliance requirement, a 100+ engineer rollout, or a heavy-usage population whose overage would exceed the price delta. For a smaller team with no regulatory pressure and lighter usage, Business is the right floor.
Worked-cost example: 20-engineer team
The same shape as the Claude Code worked example so the comparison runs cleanly. Twenty engineers, senior-heavy distribution, Cursor as a primary IDE tool potentially complementing GitHub Copilot or Claude Code.
| Population | Plan | Monthly cost | Annual cost |
|---|---|---|---|
| 8 senior engineers (heavy Composer Agent users) | Business | $40 × 8 = $320 | $3,840 |
| 8 mid-level engineers (moderate Cursor users) | Business | $40 × 8 = $320 | $3,840 |
| 4 mid-level engineers (occasional Cursor users) | Business | $40 × 4 = $160 | $1,920 |
| Base subscription total | $800 | $9,600 | |
| Included-usage overage / premium-seat uplift for heavy users | Modelled from actual team behavior | ~variable | ~$2,500-$10,000 |
| Spike-month contingency | — | ~$3,000 | |
| Platform engineering integration time | One engineer, 5% allocation | — | ~$7,500 |
| Year 1 total (mid-case) | ~$22,790 |
The mid-case still lands materially above the headline seat cost and materially below a Claude-Code-heavy rollout for the same 20 engineers. The cost gap is real and it is the procurement-relevant signal. The gap closes when the engineering organisation runs heavier Composer and cloud-agent workloads and widens when the workload is lighter. The pattern that breaks the model is the same as before: heavy users hit the included allowance, experience degrades or spend rises, and the finance model has to treat that as a real deployment cost rather than an edge case.
The high-case version of the same model lands meaningfully higher once the organisation upgrades heavy users or prepays additional usage; the low-case lands much closer to the base seat cost when usage stays light. The honest model spans all three; the budget-meeting ask is the mid-case with the high-case contingency budgeted.
Comparison with Claude Code and Copilot at the licence level
The cost picture at the 20-engineer scale, side by side:
| Tool | Mid-case Year 1 total |
|---|---|
| GitHub Copilot Enterprise | ~$9,400 (flat per-seat) |
| Cursor Business | ~$23,000 (this page’s model) |
| Cursor Enterprise | ~$35,000-$45,000 |
| Claude Code (Pro + Max + API mix) | ~$52,000 (Claude Code pricing page model) |
The shape worth naming. Copilot Enterprise wins on the headline per-seat cost because Microsoft’s procurement engine is built to optimise that number for the broadest possible adoption. Cursor Business sits in the middle — more capable agent than Copilot’s default, less procurement-grade than Cursor Enterprise, materially cheaper than Claude Code at the same population. Claude Code is the most expensive at this scale because the agentic terminal loop is a different shape of product, and the senior population that benefits from it is paying for capability that Copilot and Cursor do not yet match.
The decision is not about the cheapest number. It is about the workload mix the tool actually serves. For a 20-engineer team whose work is predominantly IDE-native and whose senior engineers run Composer Agent rather than terminal-native agents, Cursor Business is the defensible procurement choice. For the same team whose senior engineers do heavy multi-file terminal refactor work, the Claude Code premium is defensible. For a team whose work tilts heavily toward routine business logic and autocomplete, Copilot Enterprise wins on cost and adequacy simultaneously. The Cursor vs Claude Code and Cursor vs Windsurf pieces cover the workflow-fit decision in detail.
Hidden costs the pricing page does not mention
Three lines that finance teams miss on the first Cursor pass.
Composer Agent overage during refactor sprints. Composer Agent runs consume multiple fast premium requests per turn, and a senior engineer running heavy Composer Agent work during a multi-week refactor can exhaust the Business allowance early in the month. The overage line is real, predictable in shape (it tracks the engineering organisation’s refactor calendar), and not captured by the pricing-page allowance. Budget a 25-40% contingency on the senior-engineer line or the model will be wrong on the months that matter.
Model swap costs. Cursor lets engineers choose the model for chat and Composer Agent — GPT-5, Claude Opus 4.7, Gemini 2.5 Pro, the cheaper auto-model. Premium-model selection consumes fast premium requests at the published rate; the auto-model is cheaper but materially less capable on hard tasks. Engineers who default to the premium models for everything consume the allowance faster than engineers who switch deliberately. The cost-discipline conversation worth having: which model defaults are right for which task class, and what the organisation’s standard is. Without that conversation, the model-default behaviour decides the overage rate, and the finance team is reading the consequence rather than setting the policy.
Large context costs. Composer Agent loads large context windows during multi-file refactors, and the context loading consumes fast premium requests at the same per-call rate as the model output. Engineers working on large codebases consume meaningfully more than engineers working on smaller ones, even at the same workflow type. The cost shape correlates with codebase size as well as with workload mix, which the per-seat pricing does not surface and the procurement model has to account for.
When Cursor’s flat subscription stops winning
The vendor-honest version of the same question Cursor’s marketing will not write.
When the workload is heavy on terminal-native agentic loops. Cursor Composer Agent is competent and the agent capability has improved fast through 2025-2026, but the terminal-native agentic loop Claude Code provides is a different shape of product. Engineering organisations whose senior population does heavy multi-file refactor work running through the engineer’s existing shell, makefile, test runner, and deployment scripts will get materially better outcomes from Claude Code at the senior tier despite the higher per-seat cost. The procurement decision is to scope the Claude Code spend to that population rather than try to replace it with cheaper Cursor seats.
When the organisation is at full enterprise scale and Microsoft-shop. At 300+ seats inside a Microsoft Enterprise Agreement, Copilot Enterprise’s volume discounting and the Microsoft compliance integration depth structurally beat Cursor on the like-for-like baseline rollout. The Cursor spend is defensible when scoped to the senior subset or to specific teams whose workflow demands the Cursor experience; it is not defensible as the full-engineering-organisation baseline at this scale and inside this compliance posture.
When the engineering organisation cannot enforce model-default discipline. Cursor’s flat-per-seat economics depend on the engineering organisation establishing model-default policies that keep the fast-premium-request consumption inside the allowance. Engineering organisations that cannot or will not establish those defaults will see the overage line grow until the model breaks. In that case the structural answer is to either move to the Enterprise tier (higher allowance flattens the volatility) or to a different tool whose pricing model handles the discipline gap differently.
How this connects
The AI coding tools hub covers the broader category. The Cursor vs Claude Code piece covers the workflow-fit decision that sits underneath the pricing comparison. The Cursor vs Windsurf piece covers the other IDE-native competitor in the same procurement category. The Claude Code pricing page covers the equivalent cost-modelling exercise for the agentic terminal loop alternative. The AI for engineering teams page covers the team-level shipping gain the Cursor Year 1 spend is being defended against.
The strategy decision upstream of the procurement choice lives at the root hub and the capabilities hub. If your engineering organisation is being asked to buy Cursor without a strategic frame for what the spend is supposed to produce, the procurement model will be defensible at the line-item level and indefensible at the strategic level. Write the strategy frame first; size the Cursor line against it second.
Sources & methodology
- Cursor — Pricing — primary vendor reference for the current Teams price and included-usage model
- Cursor — Teams pricing docs — current team-plan and seat-type reference
- Cursor — Teams pricing update, June 2026 — current public explanation of premium seats, added usage pools, and cost-control changes
- Anthropic — Claude Code pricing — comparison reference for the Claude Code cost-model alternative
- GitHub Copilot pricing — comparison reference for the Copilot Enterprise per-seat baseline
- Stack Overflow Developer Survey 2025 — adoption-rate data underlying the workload-mix assumptions in the worked example
- Methodology: cost-shape and worked-example figures drawn from fractional CTO procurement engagements (2024-2026) across organisations sizing Cursor and competing AI coding tool spend. Pricing reflects published vendor list pricing as of mid-2026 and will move; treat the worked example as a model template rather than a current-quarter price.
Pricing on Cursor changes frequently. Before signing a contract, rerun the worked-cost example against current published pricing and your engineering organisation’s actual consumption data — the model template stays valid; the inputs will need refreshing. If the structure of the model is wrong for your organisation’s shape, send the disagreement and the next refresh will reflect it.
