Cursor Enterprise Pooled Usage: Shared Budget & Spend Limits

On a Teams plan, each paid seat has its own pool, and one seat can't draw on another's. On Enterprise, the whole account shares one committed budget, which Cursor's pricing pages describe as pooled across Grok and Cursor. Of the differences below, member limits change daily administration the most.

Teams seat tiers carry different pools. A Super seat's weekly pool is 3.75 times a Premium seat's, and an Ultra seat's is 12.5 times. When one engineer runs out early, their further work bills to the team's shared prepaid balance while teammates still have headroom, because seats never share pools. Teams created before The X SubscriptionThe subscription Cursor is sold through: one plan for Grok, Cursor and X, with Free, Plus, Premium, Super and Ultra tiers, per-seat Teams, a weekly included pool for Cursor models shared with Grok, and third-party models billed at API list price from prepaid credit. Press Enter for the full definition. keep Standard and Premium seats with monthly pools, and there Premium carries 5 times the Standard allowance. Pooled usage removes the per-person ceiling by putting the budget in one place.

Pooling also moves the spend signal. On Teams, the signal is a seat running out of its pool, after which the admin dashboard tracks that person's prepaid-credit spend. With one shared pool, nobody has a personal allowance to run out of. Nothing stops or warns about one person's expensive month unless an admin has set the spend limits and alerts described below.

For teams on The X SubscriptionThe subscription Cursor is sold through: one plan for Grok, Cursor and X, with Free, Plus, Premium, Super and Ultra tiers, per-seat Teams, a weekly included pool for Cursor models shared with Grok, and third-party models billed at API list price from prepaid credit. Press Enter for the full definition., Cursor's pages disagree about member limits. The team pricing docs list a default monthly limit per member, with per-member overrides. The spend limits help page describes one monthly limit for the whole team, fixed or per seat, and lists member-level limits only under Enterprise.

Pre-committed usage is the minimum amount of usage-based fees your order form commits you to pay during the service term. Cursor's Pricing Policy pools it across all users under the same account number, and unused commitment doesn't roll over to the next term. Members draw from it as they work, and the pool reserves no share for any person or team.

Usage past the commitment is on-demand usage. The Pricing Policy charges it at the rate in your order form and bills it monthly in arrears, based on actual consumption.

Because the pool reserves nothing, one automation started on the first of the month can use up the share a spreadsheet promised to a department. That allocation lives only in the spreadsheet, and Cursor doesn't know about it.

The commitment also behaves differently from a weekly reset, and the difference shows up in forecasting. A Teams seat's pool refreshes every week, so an expensive week doesn't carry into the next. A committed pool draws down instead, and Cursor tracks it cumulatively across the full contract term. An expensive March lowers the balance for the rest of the term. Track the pool as a burn-down against the commitment, not month by month.

Enterprise admins can set spend limits for the team and for individual members. On pooled usage accounts, a member limit applies to total usage, committed and on-demand alike. That differs from Teams, where limits cap only additional usage.

Turn on Only Admins Can Edit Usage Settings before you rely on any limit. Cursor's pooled usage docs say only admins can adjust pooled usage settings. The spend limits help page says that until an admin turns on that toggle, under Permissions in the Spending tab, any team member can turn on-demand usage on or off and change the team-level limit. Member and group overrides are always admin-only.

Cursor's June 2026 Teams pricing post said alerts could go to Slack or email. The current spend alerts help page and the pooled usage docs mention email only.

We'd set the team-level limit and at least one alert before anyone signs in, then size the rest to the account. On a twenty-person account that pair is usually enough. You can still name everyone who might spend, and individual limits mostly generate requests to raise them. Past a couple of hundred people, one default either blocks your heaviest users or leaves everyone else unchecked. Put group limits on the teams that spend most and member limits on the exceptions.

Take care with the member limit when you move from Teams. On pooled usage it covers all of a member's usage for the period, so a figure that looked generous as an overage buffer is tight as a total. Set it too low and your heaviest users stop early while the pool is still nearly full.

Dynamic Spend Limits adjust the team spend limit to the current seat count. As you add seats, the limit rises in proportion, and as you remove seats, it falls. An admin turns it on with a toggle in the Spending tab, and after that nobody has to edit the limit each time the team changes size.

Use Dynamic Spend Limits when headcount changes often, as on a fast-growing team or one with seasonal contractors. Set a fixed limit when finance wants a firm ceiling whatever the headcount. If finance has already committed to a number for the year, we'd start from that number and move it on purpose rather than let the limit track hiring.

A limit that follows seats has a blind spot on Enterprise: service accounts spend from the pool without holding a seat. Adding automation raises spend while a seat-based limit stays where it was. Give each service account its own spend limit, because new ones start with none.

Billing groups attribute usage to departments for reporting and internal chargebacks. They don't create separate pools, and the whole account still shares one. Each member's usage is tagged to their group for reporting, but every request draws from the same shared budget.

A department that asks for its own budget is asking for something the pool can't give directly. Say so during rollout, before it comes up in a chargeback meeting. The closest substitute is member limits on that group's people, adding up to roughly the promised number, checked against the group's reporting line. That substitute is stricter than a real department budget. Individual limits don't share, so a group with one heavy engineer and four light ones can hit a limit while its total sits well under the department's figure.

If your groups already sync from the identity provider, set that limit on a SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. directory group instead of person by person. It still applies to each member individually, and someone in two groups gets the higher of the two limits.

The Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud. Press Enter for the full definition. and headless CLI agents draw from the same shared pool as everyone else, and they don't take a seat of their own. Any member can create an API key and start spending against the pool.

Programmatic agents authenticate with an API key instead of an interactive sign-in, so there is no seat to assign. Their usage lands in the same pool as members' own Agent sessions, and a busy CI pipeline or a fleet of 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. shows up directly in the burn-down.

On Enterprise, the sanctioned route is a service account: a non-human account that authenticates the CLI and starts Cloud Agent runs without depending on anyone's personal login. It holds no seat license and draws from the same team pool as human members. Every team admin can see the Cloud Agent runs it starts. Cursor's security best practices call for a separate service account for each automation workflow. On a pooled account, that separation also shows each workflow's spend in analytics.

Pooled usage draws down at each model's published per-token rate, plus the Cursor Token Rate on eligible third-party models, unless your agreement with Cursor sets other rates. To turn SDK and CLI activity into a figure you can charge back, estimate the input, cached-input and output tokens a run uses, then price them from the model table. Token counts vary with the model and the context, so check the estimate against a week of real spend before anyone bills a department on it.

When the pool drains faster than your estimate, start with the per-member view in analytics, then check whether anything non-human was spending. Automation shows up there as usage. AI code tracking covers the Cursor CLICursor's command line: the full agent, all modes and models, in the terminal and pipeable into scripts and CI. Press Enter for the full definition. and 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., so their commits count toward the AI share of committed code. CLI commits have to be scored on the machine where the code was written.