Cursor Teams Plan Billing Controversy: Why Can't Paid Seats Be Reassigned?

Cursor Teams Plan faces scrutiny after users discover paid seats allegedly can't be reassigned to new team members.
A Cursor Teams Plan power user reported that their annual contract seats cannot be reassigned after a member departs—requiring new seat purchases instead. This contradicts standard SaaS seat licensing practices where seats function as reusable capacity units. While the incident awaits official Cursor response and may involve customer service miscommunication, it highlights transparency concerns in AI programming tool billing models and offers practical lessons for team procurement.
A Billing Complaint from a Power User
Recently, a development team lead who describes themselves as a deep Cursor user posted on Reddit, questioning whether the seat billing logic of Cursor's Teams Plan is reasonable. This wasn't a simple rant—according to their description, this is a small 5-6 person development team that signed an annual subscription contract long ago, processes hundreds of millions of tokens per month through Cursor, and has the vast majority of their code assisted by Cursor. In their own words: "We're fans of this product, so this isn't a hate post."
The tokens mentioned here are the basic units that large language models use to process text, roughly equivalent to 3/4 of an English word or one Chinese character. When a team consumes hundreds of millions of tokens monthly, it means they're generating enormous model invocation volumes across code generation, completion, refactoring, and other scenarios. AI programming tool billing typically involves a two-layer structure: a base seat fee (fixed monthly charge) and token usage fees (calculated by actual consumption). This hybrid model exists because the underlying LLM APIs themselves charge by token, and tool vendors need to pass this variable cost through to users.
However, it was precisely this kind of power user with strong willingness to pay who encountered a billing situation that "feels absolutely wrong," and publicly sought corroboration from other team users.
What Happened: A Paid Seat "Evaporates"
The trigger wasn't complicated. Previously, a team member took unpaid leave, and the team wasn't sure whether they would return, so they removed that member's seat.
First Communication: No Refund for Used Seats
Since the seat had generated usage records during the annual contract period, Cursor's customer service informed them: this seat would continue to be billed until the contract period ends, and no credit would be issued.
The poster said they understood this—"That's a committed seat, fair enough." This aligns with the standard business practice of "no refunds on committed capacity" in most annual contracts. Annual commitment contracts are a common pricing strategy in the SaaS industry: vendors offer 10-30% discounts to annual subscribers in exchange for predictable recurring revenue (ARR, Annual Recurring Revenue), which is the core metric for SaaS company valuations. For enterprise customers, annual contracts lock in pricing but sacrifice flexibility. Contracts typically specify that committed seats cannot be reduced or refunded, but industry convention allows reassignment within the committed quantity.
Second Communication: Paid Seats Cannot Be Reused
The real controversy arose afterward. When the team wanted a developer to use this seat that was "already paid for in the annual contract," customer service replied: that's not possible—you must purchase a brand new seat.
In other words, according to customer service's explanation, Cursor's seat policy is:
- Once a seat has been used, it cannot be reused
- It cannot be reassigned to a replacement member
- No credit is issued
- Every time there's a personnel change on the team, net-new capacity must be purchased, while already-paid capacity simply "evaporates"
Is This Really Industry Standard?
The poster's core challenge hits the nail on the head: "That's not how seat licensing typically works."
Common Practices in Traditional SaaS Seat Licensing
In the vast majority of SaaS tools, a seat is essentially a "capacity unit." When someone leaves the team, administrators can typically reassign their seat to a newly joining member, as long as the total paid seat count isn't exceeded. This is a licensing logic centered on "paid capacity" rather than "bound to an individual."
SaaS seat licensing models have evolved from "named user licenses" to "floating seats" to "usage-based" models. Early enterprise software licenses (like Oracle, SAP) were typically bound to specific individuals and non-transferable. As cloud subscription models became prevalent, modern SaaS vendors like Slack and Atlassian introduced more flexible seat pool concepts—administrators can freely add and remove members within the total purchased quantity. This flexibility is considered one of the core advantages of the SaaS model over traditional perpetual licenses. Gartner research shows that enterprises average 15-20% employee role changes annually; if seats aren't reusable, it significantly increases total cost of ownership (TCO).
Taking common team collaboration and development tools as examples: Slack, GitHub, JetBrains, Figma, and others mostly support free reassignment of members within paid seat quantities. This is also an important reason why the "per-seat subscription" model is widely accepted by enterprises—it provides flexibility for personnel turnover.
Why Cursor's Approach Seems Anomalous
If customer service's explanation is accurate, then Cursor's logic is closer to a "single-use consumable" than "reusable capacity": once a seat is activated, it becomes deeply bound to the initial user, and even after that person leaves, the paid capacity cannot be reclaimed.
To understand the possible internal logic of this approach, one needs to understand Cursor Teams Plan's product positioning. Cursor's pricing tiers are Hobby (free), Pro ($20/month), and Teams ($40 per seat per month, with annual discount). The Teams Plan adds centralized admin console, team-level usage analytics, admin permission controls, SSO single sign-on, and other enterprise features on top of Pro—and more importantly, includes higher token quota limits and priority model access. This means a seat is not just "usage rights" but also comes with specific compute resource quotas. This resource binding may be one of Cursor's technical or business reasons for restricting seat reuse—preventing circumvention of usage limits through frequent member rotation.
But even so, for a team that has already signed an annual contract committing to pay for the full year, this means any normal personnel movement (leave, departure, role change) could trigger additional seat purchases, while the capacity already paid for cannot deliver value. This is the root of why the poster feels something is "absolutely wrong."
Key Questions That Need Clarification
Interestingly, this incident is currently based entirely on a single source user account, and has not yet received an official response from Cursor. Before drawing conclusions, several questions need clarification:
First, is there a possibility of customer service misinterpretation? The poster themselves raised this question—"Is this standard policy, or are we getting a bad read from support?" Front-line customer service for SaaS products sometimes gives responses inconsistent with official terms when handling edge cases.
Second, where is the definitional boundary of "used seat"? Cursor distinguishes between seats that were "never used" and those that "generated usage records"—the former might be adjustable, while the latter is locked. This distinction may have internal logic under a hybrid model of usage-based billing (token consumption) and seat-based billing, but transparency for users is clearly insufficient.
Third, the specific terms of the annual contract. Non-refundable annual committed seats is a common clause, but "non-reusable" is a different matter. This needs to be confirmed against the specific contract text the user signed.
Implications for Team Procurement of AI Programming Tools
As AI programming tools like Cursor, GitHub Copilot, and Windsurf enter enterprise procurement consideration, the complexity of their billing models is gradually being exposed.
In 2024-2025, competition in the AI programming tools space has intensified dramatically. GitHub Copilot holds a first-mover advantage through its deep integration with the VS Code and GitHub ecosystem, with enterprise pricing at $39 per seat per month. Cursor, as an independent AI code editor built on a VS Code fork, has won over many power developer users with its Agent mode and multi-model support (Claude, GPT-4, etc.). Windsurf (formerly Codeium), Amazon Q Developer, JetBrains AI, and others are also competing for market share. What makes this space unique is that underlying model costs are high and volatile, and vendors need to find balance between user experience and cost control—which also explains why billing models are more complex than traditional SaaS.
These products often layer "seat subscription + token usage" hybrid billing, which differs significantly from traditional pure seat-based SaaS.
Key Points to Confirm Before Procurement
For organizations planning to procure AI programming tools as a team, this incident provides several practical references:
- Clarify seat reuse policy: Get written confirmation before signing whether seats from departing or role-changing members can be reassigned—don't rely on verbal customer service responses.
- Understand the boundaries between commitment terms and flexibility: Annual contracts typically offer better pricing, but evaluate the tradeoff between team personnel turnover frequency and contract rigidity.
- Watch for hidden costs in hybrid billing: How token usage and seat fees stack up, and which costs are recoverable versus non-recoverable when personnel changes occur.
- Keep communication records: Customer service responses may be inconsistent with official terms—written documentation helps with subsequent appeals.
- Compare flexibility terms across competitors: Make horizontal comparisons of seat management policies among GitHub Copilot, Windsurf, and other competitors, incorporating billing flexibility into your evaluation criteria.
Conclusion
This incident remains a one-sided account from a heavy-paying user; Cursor's official position is unclear, and customer service misinterpretation cannot be ruled out. But it reveals a real pain point: the commercialization of AI programming tools is moving extremely fast, while the transparency and flexibility of their billing models have not yet fully caught up with enterprise users' expectations.
For a product as beloved by developers as Cursor, how to provide team users with reasonable seat flexibility while protecting revenue will be key to maintaining user trust. And for users, before paying for powerful AI productivity tools, understanding the billing fine print may be just as important as evaluating product capabilities.
Key Takeaways
Related articles

Coze Beginner's Guide: A Complete Tutorial for Building AI Agents with Zero Code
A detailed guide to ByteDance's Coze platform covering core features, China vs. international version differences, and practical use cases. Learn to build AI agents with zero code through drag-and-drop.

Hands-On Tutorial: Building a Godot Game AI Agent with DeepSeek + Harness
Learn how to build a dedicated AI agent plugin for the Godot game engine using DeepSeek models and the Harness framework, with auto code fixes and real-time editor refresh.

Model Distillation: The Core Technology for Compressing Large Model Intelligence into Your Phone
A clear explanation of model distillation (Knowledge Distillation) principles and process. Learn how teacher-student knowledge transfer compresses large model capabilities onto phones for offline face recognition, translation, and more.