I would like to know what the Cursor Agent Headless RPM (requests-per-minute) and TPM (tokens-per-minute) are, specifically for OpenAi models?
I am looking to move some batch processing images/text applications that i have that go direct to the Openai API > Cursor headless as i want to ensure that i get a similar RPM. I have had some issues in the past with Cursor agent headless throttling requests i.e. timeouts and slow responses (specifically gemini models), and wanted to be sure that the Cursor Ultra plan can handle similar throuhput in parallel ?
e.g. My current openai api limits (though even 1000 RPM would be sufficient for my current apps):
Hey, good question. Cursor doesn’t publicly document specific RPM or TPM limits for the headless CLI. The usage model is based on a monthly API budget, not raw request throughput. On the Ultra plan, you get 400 dollars per month of API agent usage.
A few things to keep in mind:
Cursor headless is built for code-focused agent tasks like analysis, refactoring, and reviews. It’s not meant to be a general-purpose API proxy for model providers. Each request is an agent session that can include multiple model calls, tool use, and file reads, so it’s a different setup than direct OpenAI API calls.
For batch processing images or text at the scale you’re describing, like 1 000+ RPM, direct OpenAI API access will almost certainly give you better throughput and more predictable rate limits. Cursor adds an orchestration layer on top of the models, which adds overhead and isn’t ideal for high-volume batch jobs.
The throttling and timeout issues you saw with Gemini models are a known area. Model availability and latency can change depending on load.
If you have a specific use case where you need guaranteed throughput through Cursor headless, like CI CD pipelines or automated code reviews, I’d recommend reaching out to the team via [email protected]. They can share more specific guidance for your workload.
For pure batch processing of images or text, sticking with the direct OpenAI API is probably the better fit.