How to Scale Cursor API Usage?

We embed the Cursor TypeScript SDK (@cursor/sdk) as a local agent in a desktop product (workspace cwd on the user’s machine). Credit users authenticate to Cursor with one company CURSOR_API_KEY (or an Enterprise service account, if we can get one). We are not using Cloud Agents as the primary path.

As the user base grows, many concurrent local agents will hit the same Cursor account/team. We need the recommended way to scale that:

  1. Burst / req-per-minute (and any hour window) on SDK/agent inference — not only the monthly usage pool. Does Ultra or Enterprise raise that, and is it per team or per key? Do extra service accounts add rpm, or do they share one team throttle?
  2. Monthly usage — is Enterprise pooled usage the right model for a product key, vs one Ultra seat?
  3. Is there an OEM / platform / higher team rate-limit path if we cannot put a Cursor key on every end user?

We have tried Cursor Sales for Enterprise for ~4 weeks with no response. If this is a sales-only quota, please point us at the right contact.

Hey @Meraky_Development,

1. Burst/rate limits - limits are per API key, not one shared team throttle, so each additional service-account key gets its own bucket. Back off on the Retry-After/X-RateLimit-* headers, prefer webhooks over tight polling, and cache repo-listing (it’s strict). Higher ceilings can be raised via [email protected]. Refs: API overview, Cloud Agents API.

2. Monthly usage - yes, Enterprise pooled usage over a single Ultra seat. Service accounts draw from the shared pool, no per-seat cost.

3. OEM/platform - Enterprise + service-account keys is the path for centralized usage across many end users (no key per user), with higher limits grantable on top. Embedding Cursor as your product’s backend is intended SDK use.

On Sales: the team works through their own criteria and it can take a little time, so I’d email [email protected] for a status update on your request. In the meantime, a Team plan is self-serve and bumps you to the higher concurrency tier, which can help you keep scaling while the Enterprise conversation lands.

@mohitjain

Thank you, this is exactly the information I was looking for.

Our use case is an AI development platform where our own users are the end users, so we need centralized usage through service-account/API keys rather than a Cursor seat for every user.

The Enterprise + service-account approach sounds like the correct solution for us, especially with higher rate/concurrency limits and pooled usage.

We have already been trying to reach Sales for about 4 weeks without getting a response. Is there any way to escalate our existing Enterprise request or get in contact with someone who can help us set this up?

Our expected scale is approximately 1,000–10,000 end users, so the standard Team plan would not be sufficient for our architecture.

What should we do in this case?

Thanks again!

Still no update from the sales team… after 1.5 months… seriously?? :neutral_face:

@Meraky_Development - I hear you, and sorry it’s been slow. To be realistic: Enterprise onboarding takes time and goes through its own eligibility criteria, so it isn’t always a quick turnaround. The best way to move it forward or get a status update is to email [email protected] with your company details and expected scale.

In the meantime, a Team plan is self-serve and bumps you to the higher concurrency tier with pooled usage. It’s not the final architecture for 1k–10k end users, but it lifts your immediate limits without waiting on the Enterprise track.