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.