Can Cursor clarify exactly which Grok Bot usage counts against the weekly pool vs Cursor Models / Other Models?

Support Help
, , ,
1

Can Cursor clarify exactly which Grok Bot usage counts against the weekly pool vs Cursor Models / Other Models?

I’m trying to understand the exact quota/billing behavior of Grok Bot, because there have been several official explanations that appear to overlap or contradict each other.

From what I understand, the following has now been officially stated:

1. Normal Grok Bot conversations use the separate Grok Bot weekly pool.

Cursor staff has said multiple times that normal Grok Bot usage has its own weekly allowance and should not consume the regular Cursor Models / Other Models monthly allowance.

2. On September 3, Mohit clarified that routines/automations and browser actions are different.

The explanation was:

  • Conversations → Grok Bot weekly pool

  • Routines / automations → Cursor plan / Other Models

  • Browser actions / cloud-agent work → Cursor plan / Other Models

It was also stated that this usage can potentially exhaust Other Models and block Claude/GPT even while the Grok Bot weekly pool still has capacity.

3. However, on September 7, Mohit gave another clarification about the grok-bot-* rows.

The explanation today was that grok-bot-* rows appearing under Cursor Models are only there because the dashboard groups requests by the model serving them rather than by product.

It was explicitly stated that these rows are display-only, do not consume the Cursor Models allowance, and will not cause rate limiting even if the displayed breakdown appears inflated.

But the same response also included this important note:

“Cloud agents launched from Grok Bot do count toward your Cursor plan.”

This leaves me with a few questions that I think would be useful to clarify officially.

1. What exactly happens with grok-bot-automation?

Does grok-bot-automation itself consume the Grok Bot weekly pool, the Cursor plan, or both?

For example, if a Routine runs automatically and consumes a large amount of context:

A) Is that usage deducted only from the Grok Bot weekly allowance?

B) Is it deducted only from Cursor Models / Other Models?

C) Does the Grok Bot orchestration consume the weekly pool while the underlying cloud-agent/model execution separately consumes the Cursor plan?

If C is correct, then technically a single Grok Bot automation can consume two different allowances for different parts of the same job. Is that the intended behavior?

2. What exactly does grok-bot-cua consume?

The dashboard also shows grok-bot-cua.

Since CUA appears to correspond to computer/browser interaction, should this usage actually count against Other Models / the Cursor plan, as previously explained for browser actions?

Or is the grok-bot-cua row itself also only a display artifact, with only some downstream cloud-agent execution being charged to the Cursor plan?

This distinction is important.

3. What does “cloud agents launched from Grok Bot” specifically mean?

Could Cursor define which Grok Bot actions fall into this category?

For example:

  • Routines / scheduled automations

  • Browser use

  • Computer Use / CUA

  • Shell commands

  • Coding tasks

  • Subagents

  • MCP calls

  • GitHub actions / repository work

  • Long-running tasks

  • Normal Grok Bot conversations that happen to use tools

Which of these consume only the Grok Bot weekly allowance, and which consume the regular Cursor allowance?

4. Can a Grok Bot task consume the weekly allowance AND Cursor usage simultaneously?

This is probably my biggest question.

Imagine I still have 80% of my Grok Bot weekly quota available and I ask Grok Bot to perform a task involving browser/computer use or an automation.

Does that task:

Grok Bot weekly pool only

or

Cursor Models / Other Models only

or

Grok Bot weekly pool + Cursor Models / Other Models simultaneously, because the Grok Bot orchestration and the underlying cloud agent are metered separately?

If both pools can be consumed by one task, I think this should be explicitly documented because it substantially changes how users should interpret the weekly Grok Bot allowance.

5. What exactly do these dashboard entries represent?

Could someone from Cursor confirm the accounting behavior for each of these?

Usage entry Grok Bot weekly pool Cursor Models Other Models
grok-bot-default ? ? ?
grok-bot-automation ? ? ?
grok-bot-cua ? ? ?

Not just where they appear in the UI, but which quota counters actually enforce the limits internally.

That distinction matters because the current dashboard can visually attribute hundreds of millions of tokens to Cursor Models / Other Models even when staff says some of that usage is only a display grouping issue.

6. What happens when one of the pools reaches 100%?

For example:

  • Grok Bot weekly pool still has capacity

  • Other Models reaches 100%

  • On-Demand is disabled

Can Grok Bot continue normal conversations?

Can it still run automations?

Can it still use Computer Use/browser actions?

Would only the cloud-agent portion stop?

And conversely, if the Grok Bot weekly pool reaches 100% but the Cursor Models / Other Models allowance still has capacity, what functionality remains available?

7. Finally, is Grok Bot quota based purely on tokens?

There have also been reports of Grok Bot interactions processing extremely large contexts, sometimes hundreds of thousands of tokens per interaction.

Is the Grok Bot weekly percentage calculated purely from input/output tokens, or does it also include agent steps, tool calls, computer-use actions, execution time, or another internal weighting?

It would be very useful if Cursor could provide either:

  • the approximate token equivalent of the weekly allowance for Pro / Pro+ / Ultra, or

  • a clear explanation of the formula used to calculate the weekly percentage.

I’m not reporting this as a complaint. I’m mainly trying to understand the system accurately.

Right now I think the confusion comes from three different things being mixed together:

Grok Bot orchestration / persistent conversation

vs.

cloud-agent execution initiated by Grok Bot

vs.

the way all of this is grouped in the Spending dashboard.

A definitive explanation of which quota each layer consumes would clear up a lot of the confusion around Grok Bot usage.

Thanks!

5

Hey, thanks for breaking it down so clearly. Here’s how it works today.

What each pool is charged for

Anything Grok Bot does on its own comes out of the weekly Grok Bot allowance: normal chats, routines and scheduled automations, browser and computer use, shell commands on the bot’s machine, its sub-agents, MCP calls, and repo work on the bot’s own machine. On the Spending page, these show up as grok-bot-default, grok-bot-automation, grok-bot-cua, plus sometimes some rows with normal model names without the grok-bot prefix. Those are models the bot picks server-side for helper steps (for example claude-opus-5-low), so they can appear even if you didn’t pick them. That’s expected behaviour, not a metering bug.

All of these follow one rule: as long as the weekly Grok Bot pool isn’t exhausted, they use that pool and do not touch your included Cursor Models / Other Models allowance. When the weekly pool runs out, they (like all other bot activity) switch to the shared On-Demand balance (more below), but that is paid On-Demand, not your included Cursor allowance.

The one exception to the “everything goes to the weekly pool” rule is when the bot hands work off to a Cursor cloud agent (the same cloud agents you can start from cursor.com/agents). Those runs bill to your Cursor plan like a normal cloud agent, and they show up as normal model rows (for example composer-2.5) with a cloud agent icon, not as grok-bot rows.

Your table

Usage entry Grok Bot weekly pool Cursor Models / Other Models (included)
grok-bot-default Yes No
grok-bot-automation Yes No
grok-bot-cua Yes No

All three use only the weekly Grok Bot pool. They can show under Cursor Models / Other Models because of a known display issue we’re tracking. The breakdown groups rows by the model that served the request, not by product, so these rows can visually take up part of the Cursor bars. The real limits are enforced by the percentages at the top of the bars, and those count only your activity in the Cursor app. So grok-bot-cua is just a normal bot turn (computer or browser use), not a separate charge to your Cursor plan. Same for grok-bot-automation: routines themselves use the weekly pool, not the Cursor plan.

Small dashboard note: attribution in the breakdown can be recalculated retroactively (for example a row first shows a small percentage and a few days later shows more) because it’s a side effect of that display issue. It doesn’t affect the actual limits.

Can a single task spend from both pools at the same time (your question 4, option C)

Yes, but only in one case: when the bot launches a cloud agent. The bot’s own turn uses the weekly allowance, and the cloud agent it launches bills to your Cursor plan. That’s intended behaviour. If the bot didn’t launch a cloud agent, the task uses only the weekly Grok Bot pool. You can confirm whether cloud agents ran on the Spending page. They show as separate model rows with a cloud agent icon.

What happens when a pool hits 100%

  • Other Models at 100%, On-Demand off: Grok Bot chats, routines, and computer use keep working. Only cloud agents launched by the bot are blocked (same as any other cloud agent).
  • Weekly Grok Bot allowance at 100%: with On-Demand on, all Grok Bot activity (not just cloud agents, but also helper rows like claude-opus-5-low) keeps working, but it uses the shared On-Demand balance, the same one Cursor uses. There isn’t a separate Grok Bot-specific cap yet, so the only way to limit this is the overall spend limit on the Spending page (setting it to $0 fully stops overflow). Charge order is weekly allowance, then referral or promo credits (if any), then paid On-Demand. With On-Demand off, all Grok Bot activity is paused until the weekly reset, and your work in the Cursor app isn’t affected.

How the weekly percentage is calculated (question 7)

It’s cost-based, not based on raw token count. Each model call is priced by input, output, and cached tokens at that model’s rate, and the percentage is your spend relative to your plan’s weekly allowance. Steps, tool calls, and execution time don’t count on their own, only through the model calls they trigger. Big jumps from a single run usually come from routines that include a long conversation history.

About the difference between the 3 September and 7 September explanations: for your account (Pro), the 7 September version is the right one. grok-bot-* rows under Cursor Models are display-only. Tell me if anything is still unclear.

7

Your table is the right ask. The dual-charge case (bot orchestration + launched cloud agent) is easy to miss when pacing a week. Are you mostly burning on routines or interactive chats?

9

Hey @Publicidade_Ja_Marke!

A quick follow-up on the display side of this.

The issue where grok-bot-default, grok-bot-automation, and grok-bot-cua rows appeared inside the Cursor Models / Other Models breakdowns on the Spending page has been addressed on our side. Those rows should no longer show up in the Cursor breakdowns, and the per-model percentages there should reflect only your Cursor app usage (plus any cloud agents launched from Grok Bot, which bill to your Cursor plan as described above).

Nothing changes about the actual limits. As explained above, they were already being enforced against the right pools, this only corrects how the breakdown is displayed.

Could you take a look at your Spending page in a day or so and let me know if the breakdown still looks off?