Cursor Enterprise Pooled Usage: Shared Budget & Spend Limits

Enterprise pooled usage puts one budget behind the whole account, so any member can draw on it. A Teams plan splits the same budget per seat. The table sets the two structures against each other, and the member-limits row is the one that changes day-to-day administration.

On a Teams plan, Standard seats get one allocation and Premium seats get 5× that. If one engineer burns through their allocation early, they go on-demand while teammates still have headroom. The allocations never combine. Pooled usage removes that per-person ceiling by putting the budget in one place.

What goes with that ceiling is a per-person spend signal. On a Teams plan the allocation does that work, so a heavy user reaches it and continues on-demand, tracked per user in the admin dashboard. Pool the budget and that signal moves onto the account, where one person's expensive month stays invisible until somebody totals the pool. Which is fine, as long as an admin has set the spend limits below.

Pre-committed usage is the usage volume included in your Enterprise contract, pooled across all users under the same account number. Members draw from it in the order their requests arrive; there is no per-member reservation within the pool. When the pool is exhausted, on-demand usage continues service at the same rates and bills at the end of the month.

Consumption order reads like a technicality and it matters more than it looks, because nothing in the pool reserves a share for a person or a team. One automation started on the first of the month can eat the slice a spreadsheet promised to a department, and Cursor has no notion of that allocation.

Replenishment works differently from a reset, and the difference shows up in forecasting rather than in anybody's editor. A Teams allowance comes back on the billing date and does not roll over, so an expensive March is closed out by April. A pre-committed pool draws down instead, which leaves that same expensive March missing from the balance for as long as the pool has to last.

Track it as a burn-down against the commitment rather than month by month.

Enterprise accounts support spend limits at two levels: team-wide and per-member. On pooled usage accounts, member spend limits apply to total usage, not just on-demand. That is a meaningful difference from the Teams plan, where member limits only cap on-demand spend.

The usual advice is to set both limits before anyone signs in, and I would qualify it by size. On a twenty-person account the team-wide limit plus one alert is enough, since you can still name everybody who might spend and a per-member number mostly generates requests to raise it. Past a couple of hundred people that inverts, because nobody is watching individuals and the member limit is the only control that acts on one person before the invoice does.

The member limit is probably the easiest number to get wrong during a migration. On pooled usage it covers the person's whole month, so a figure that looks generous as an overage buffer is tight as a total. Set it low and your heaviest users stop early with the pool still nearly full.

Dynamic Spend Limits automatically adjust the team-wide spend cap based on current team size. As you add seats, the cap rises proportionally; as seats are removed, it falls. This removes the administrative overhead of manually adjusting the cap every time your team scales, and prevents underspend controls from blocking new hires on day one.

Use Dynamic Spend Limits when headcount changes frequently (fast-growing team or seasonal contractors). Set a fixed team-wide cap when you want a firm monthly budget ceiling regardless of headcount. If finance has already committed to a number for the year, I would start there and move it deliberately rather than let the cap track hiring.

A cap sized by seats has a blind spot on Enterprise, where service accounts spend from the pool without holding a seat, which is easy to miss because adding automation raises the spend while the cap stays where it was.

Billing groups attribute usage to departments for reporting and internal chargebacks. They do not create separate usage pools. The whole account still shares one pool. If your team uses billing groups, each member's consumption is tagged to their group for reporting, but all requests draw from the same shared budget.

A department that asks for its own budget is asking for something the pool cannot hand over directly, and the time to say so is during the rollout rather than in a chargeback meeting. The closest thing to it is per-member limits on that group's people, summing to roughly the number they were promised, with the group's reporting line to check them against. That approximation leaks in one direction. Individual ceilings do not share, so a group with one heavy engineer and four light ones can hit those ceilings while its total sits well under the departmental figure.

If the groups already sync, setting 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 is less work than doing it person by person. It still lands on each member individually, and a person who sits in two of them takes the larger of the two figures.

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 agents draw from the same shared pooled usage as everyone else. They do not consume a paid seat and they do not require an Enterprise license. Anyone on the account can generate an API key and start spending against the pool.

Because programmatic agents authenticate with an API key rather than an interactive sign-in, there is no seat to assign. Their requests land in the same pool as Tab, Agent and ⌘+K usage, so a busy CI pipeline or a fleet of background agents shows up directly in the pre-committed burn-down. Set spend limits before you point automation at the pool.

On Enterprise the sanctioned version of this is a service account, a non-human account that authenticates the CLI and starts cloud agent runs without hanging off somebody's personal login. It holds no seat license and draws from the same team pool as human members. Cloud agent runs it starts are visible to every team admin, and Cursor's own guidance is one service account per workflow, a separation that keeps the spend legible in analytics later.

The request-mapping math for cost allocation

Pooled usage is denominated in requests. To turn raw SDK and CLI activity into a dollar figure you can charge back, map activity to requests and price each request. Request 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 the estimate said it would, start with the per-member view in analytics, then ask whether anything non-human was spending. Automation shows up there as usage, though AI code tracking does not cover Background Agents or 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., so the chart for AI share of committed code will not account for any of it.