Cursor Enterprise Pooled Usage: Shared Budget, Spend Limits & Dynamic Caps

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 eliminates that per-person ceiling by putting the budget in one place.

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.

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 — which is a meaningful difference from the Teams plan where member limits only cap on-demand spend.

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.

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.

The Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud. 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 Cmd+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.

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.