Cursor Cloud Agents for Enterprise Teams: The Real Costs

Cloud Agents now create more than 60% of pull requests merged internally at Cursor, and the company wants your enterprise team to adopt the same pattern. Cursor Cloud Agents for Enterprise Teams promise persistent, cloud-hosted coding agents that run in the background, open pull requests, and keep working after your developers close their laptops. The reality is more complicated than the marketing suggests. The flat per-seat price is just the entry point—actual costs scale with agent usage, third-party model spend, and the infrastructure choices you make around self-hosted execution.

Cursor’s June 2026 Teams pricing overhaul introduced a Premium seat and split usage into two pools, but the math still surprises procurement teams. Cursor Teams Standard is priced at $40 per user per month for monthly billing and $32 per user per month for annual billing, while Cursor Teams Premium is priced at $120 per user per month for monthly billing and $96 per user per month for annual billing, providing 5 times the included usage of the Standard seat. Cursor Enterprise plan pricing is custom and not published; it is not available for self-serve purchase. On top of seat fees, Teams and Enterprise plans pay a Cursor Token Rate of $0.25 per million tokens on third-party model requests, a charge that does not apply to individual plans.

Each Teams seat includes at least $20 per month of agent usage that resets each billing cycle, split between a First-party models pool for Cursor’s own models and a Third-Party API pool for external models. The split matters because Cloud Agents consume included API usage first before triggering on-demand billing charges; on-demand usage must be enabled regardless, and a spending limit must be set before launching the first cloud agent. That last detail corrected an earlier support response that incorrectly claimed cloud agents bypassed included allowances entirely—a mistake that led some teams to underestimate their true burn rate.

The gap between headline seat price and actual total cost of ownership is where most enterprise budgets break. Consider a 50-developer team with 40 Standard seats and 10 Premium seats on annual billing: the base subscription cost is 40 × $32 + 10 × $96 × 12 = $26,880 per year. That’s the procurement-friendly number.

What I call the Seat-Agent Divergence pattern explains why: the per-seat number is honest as far as it goes, but it doesn’t capture the fast-premium-request consumption rate at your actual workload mix. Cursor’s own documentation puts daily Agent users at $60 to $100 a month in total usage, which means a $20 Pro seat covers only a fifth to a third of what a daily Agent user actually spends. For teams, the math is steeper because third-party model requests carry that Cursor Token Rate surcharge. If your engineers default to frontier models for complex agent tasks, the included pools drain faster than the dashboard suggests—especially given reporting lag that created the false appearance of no usage deduction during the early cloud agent rollout.

The Premium seat is Cursor’s answer to this: 5x the included usage for 3x the price. Cursor frames the Premium seat as a cost-control measure for teams, offering 5x usage for 3x the price to cover heavy agent users and reduce unpredictable on-demand costs. But Independent analysis notes the Premium seat adds only usage limits and no additional governance or admin features, so its value is entirely dependent on a team’s actual agent usage mix, with no benefit for teams with uniformly light usage. If you have five engineers burning through included allowances daily, Premium makes sense. If you have five engineers using Tab autocomplete and occasional chat, you’re overbuying.

Deployment Option	Pricing	Key Features	Target Audience
Cursor-hosted Cloud Agents	Teams Standard $40/user/mo or Premium $120/user/mo (annual: $32/$96) + usage-based billing cite	Isolated VMs per agent, secret redaction, egress controls, signed commits cite	Teams wanting turnkey operation without infrastructure management
Self-hosted Machines	Teams/Enterprise seat pricing + customer infrastructure costs cite	Execution on customer infra, 8 backends (AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel, E2B) cite, outbound HTTPS only, no inbound firewall changes cite	Teams needing internal service access, custom hardware, or data residency
Coder Agent Relay	—	Air-gapped deployment, sandboxed temporary environments, centrally defined policies, audit logs cite	Regulated sectors (banking, defense, government) requiring strict compliance cite

What does self-hosted execution actually solve for regulated teams?

Self-hosted machines let Cloud Agent tool execution run on customer-controlled infrastructure while Cursor retains the agent loop, inference, and planning in its cloud. Workers connect via outbound HTTPS only, and Cursor never initiates inbound connections to customer networks. Self-hosted machines for Cursor Cloud Agents are supported across eight backends: AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel, and E2B. The pitch is control: keep code, build outputs, and secrets inside your network boundary.

For regulated industries, that control is necessary but not sufficient. Coder Agent Relay, with SpaceXAI as launch partner, enables Cursor Cloud Agents to run on customer infrastructure with air-gapped deployment options, targeting regulated sectors such as banking, defense, and government. Gartner projects that 80% of enterprise software engineers will need to upskill for generative AI by 2027, but in tightly controlled environments, security and compliance reviews still determine which tools reach developers. Self-hosted execution removes the data residency objection, but it doesn’t remove the vendor.

Because Cursor retains control of inference and planning, it likely remains classified as an ICT third-party provider under the EU’s Digital Operational Resilience Act (DORA) even when Cloud Agents execute on customer-owned infrastructure. The data suggests this is a structural limit, not a bug. Cursor controls the model, the planning, and the orchestration—everything that actually reasons about your code. The execution environment is just a worker. Under DORA, the arrangement and the provider behind it matter more than where code executes. That means the contractual work—Article 30 processing terms, Article 28 provider registers, exit plans—remains entirely intact regardless of which backend you choose.

If you’re a bank or defense contractor, self-hosted machines answer a real objection by keeping source code and secrets on machines you control. But don’t mistake that for eliminating vendor risk. You’re still contracting with Cursor for the AI layer, and that relationship carries the same regulatory weight as the hosted version. Self-hosted machines allow Cloud Agent tool execution to run on customer-controlled infrastructure while Cursor retains the agent loop, inference, and planning in its cloud. The firewall rule is cleaner—outbound HTTPS only, no inbound holes—but the vendor dependency isn’t. If you’re trying to understand how the async model differs from local agent mode, Cursor Background Agents: What Changes When AI Code Is Async covers the context reset limitations and ideal use cases.

When do Projects change the agent economics?

Projects, launched September 10, 2026, is powered by Cloud Agents, maintains context over months of work, delegates tasks to thousands of subagents, and supports subscriptions to Slack channels, schedules, and PRs. Cursor internal data shows new Projects users merge 30% more PRs, while users who primarily use Projects merge six times as many PRs as before. That’s a productivity multiplier, but it’s also a cost multiplier.

The shift is architectural. Traditional agent mode works on a single chat context—prompt, response, maybe a few tool calls. Projects runs a coordinator agent that never writes code itself but delegates to thousands of subagents across cloud and local machines. Cloud Agents support event triggers, long-lived goals via the /goal command, scheduled tasks, monitoring of pull requests and Slack threads, and isolated subagents running on dedicated virtual machines. A project can watch a Slack channel for bug reports and spin up agents to fix them, or monitor PRs and address CI failures without human intervention.

The economic implication is that persistent, event-driven agents consume more included usage over time and generate more on-demand charges during long-running work. A team that adopted Projects for a migration might see a single coordinator running for weeks, delegating to hundreds of subagents, each burning tokens against the included pools. The “six times” PR merge figure comes from Cursor’s own employees, measured by merged PR count. Nobody has any numbers yet on how rework and rollback rates change once outside teams start using it. That’s the gap you need to model before committing to fleet-scale agent deployment.

How should you size your Cursor deployment?

The right approach depends on your team’s size, codebase maturity, and tolerance for workflow disruption. There’s no universal best configuration—there’s only the best configuration for your specific constraints. Any claim to the contrary is marketing.

Start with seat type. If your team has a mix of light and heavy agent users, the Standard/Premium split is worth modeling. Run that model against your actual headcount and usage patterns before signing an annual commit.

Then consider execution environment. If your compliance requirements demand code stays inside your network, self-hosted machines are the answer. But remember the DORA tension: Self-hosted machines allow Cloud Agent tool execution to run on customer-controlled infrastructure while Cursor retains the agent loop, inference, and planning in its cloud. You’re buying data residency, not vendor independence. For air-gapped environments, Coder Agent Relay, with SpaceXAI as launch partner, enables Cursor Cloud Agents to run on customer infrastructure with air-gapped deployment options, targeting regulated sectors such as banking, defense, and government. That’s the only option if your security policy prohibits outbound connections to vendor clouds for inference.

Finally, set spend controls before you enable agents. Cloud Agents consume included API usage first before triggering on-demand billing charges; on-demand usage must be enabled regardless, and a spending limit must be set before launching the first cloud agent. The dashboard shows usage split between pools, but reporting lag can create false confidence. Start with a low spending limit, run a pilot for 30 days, and adjust based on actual token consumption—not the headline seat price. For a deeper dive into how credit-based billing creates cost spikes depending on model selection, Cursor Usage Limits Explained breaks down the pricing mechanics.

The tools that win long-term are the ones that integrate transparently into existing workflows rather than demanding workflow rewrites. Cursor’s agent layer is powerful, but it’s infrastructure, not magic. Price it accordingly.