Is your Grok Bot burning too many tokens coding?

Is your grok bot burning tokens like crazy when you use it for coding?

IDE vs Grok Bot

If you live in the Cursor IDE, token use is usually visible and you have direct control over the model etc. You start a chat, pick a model, stop the agent when the edit is done. The IDE is excellent, because it is easy to manage a durable memory pattern via progressive documentation (massive token savings ... ask your cursor agent in the IDE to plan out a durable memory pattern that will work best for your project).

If you use Grok Bot to manage Cursor Cloud Agents, the work can look similar, but the token bill can be insane. That gap is usually settings and billing pools.

Some Basics

Grok Bot chat is not the Cloud Agent it launches.

• Conversations with Grok Bot draw from the Grok Bot weekly pool.

• Cloud Agents launched from Grok Bot count against the regular Cursor plan.

Grok Bot’s own model turns are tracked as: grok-bot-default, grok-bot-automation, grok-bot-cua.

Check the Spending Page

Open cursor.com → Dashboard → Spending / Usage and sort the rows:

• Cloud agent icon → actual Cloud Agent runs (Cursor plan)

• grok-bot-default → Grok Bot chat and orchestration (weekly Grok Bot pool)

• grok-bot-automation / grok-bot-cua → routines, scheduled jobs, computer use (Cursor plan)

If most tokens are grok-bot-*, Cloud Agent settings will not save you. Pause unused routines, start a fresh Grok Bot thread per task, and turn on-demand off or set a hard $0 on-demand limit so weekly-pool overflow cannot keep charging.

Then look at the model id (not the label).

Fast Grok is 2× standard Grok.

• Grok 4.6: $2 / $0.50 / $6 per million (input / cache read / output)

• Grok 4.6 Fast: $4 / $1 / $12

• Grok 4.5 Fast is even worse on output: $18 / million

• Composer 2.5 non-Fast is in a different league: $0.50 / $0.20 / $2.50

If the rows say cursor-grok-4.6-high-fast, the default is expensive before the agent writes a line.

Next Check Defaults

Cloud Agents → Default model

Path: cursor.com/dashboard/cloud-agents → Default model.

When Grok Bot starts an agent and does not name a model, it uses this default. You can also tell Grok Bot which model to use for a task.

Do not trust the closed picker. Open / Edit and check four things:

1. Model family. Grok High vs Composer 2.5. Composer is the cheap workhorse for routine maintenance coding and it works great with a durable memory plan in place in the IDE.

2. Fast. It is hidden behind Edit. The closed label often just says “Grok 4.6 High” even when Fast is on. There have been real bugs where Fast-off still billed Fast on follow-ups and on some Grok Bot-launched agents. Confirm in usage rows.

3. Effort. High effort means more thinking tokens. Use it for hard work only.

4. Context window. Cloud Agents let you pick a larger window. Official docs say that increases token use and cost. On some Grok variants, crossing ~200k doubles rates. Leave the default unless the repo actually needs it.

After changing the default, start a new agent. Old runs keep the model they were born with.

Next Turn off long-running agents unless you absolutely need them

Team setting: Cloud Agents dashboard → Team feature settings → Long running agents.

An agent that keeps looping resends the whole conversation, tools, and rules every turn. That is how a modest coding job becomes millions of tokens. Overnight autonomy is a product feature and a cost feature.

Grok Bot Computer use is a different, heavier loop

If Grok Bot is driving a desktop or browser for work that could be a normal repo agent, expect more tool calls and more tokens. Cursor has improved efficiency here. It is still not a local IDE edit.

Follow-ups and thread length

Team follow-ups let more people keep talking to an already-long agent. Every follow-up resends accumulated context.

Same rule as in the IDE: one task, one agent. Do not append to a day-old Cloud Agent. Late-turn cache-read inflation is a classic Cursor cost pattern. A 10-line change at the end of a long thread can cost more than the same change in a fresh run.

MCP, rules, skills, and a bad environment

These are not billing toggles. They add tokens on every request.

• Enabled MCP servers ship tool schemas every turn. Disable the ones that job does not need.

• Always-apply user, team, and repo rules, plus a fat AGENTS.md.

• A cloud environment that cannot install deps or run tests makes the agent retry setup instead of shipping the change. That is extra loops, not extra intelligence. Snapshot the environment first.

Check Parallelism

Grok Bot can launch several Cloud Agents at once. Cursor’s own usage data says the heaviest users are the ones running agents in parallel. Cap how many agents and routines are allowed to run unattended.

Put a spend cap on Cloud Agents

Cloud Agents ask for a spend limit the first time they are used. Confirm it still exists and is not “No limit.” They bill at the selected model’s API price on top of plan pools.

TLDR:

1. Spending page: grok-bot-* or actual cloud-agent rows?

2. Default model: Edit → Fast off → drop Effort for routine work → keep the context window small.

3. Default routine coding agents to Composer 2.5 non-Fast. Save Grok High for hard problems.

4. Disable long-running agents and unused routines.

5. New agent per task. Do not follow-up on stale runs.

6. Trim MCP servers and always-on rules.

7. On-demand off, or a hard dollar cap.

8. After a change, inspect the next run’s billed model id. Look for -fast.

If the numbers still look wrong, send Cursor a few Cloud Agent run IDs at hi@cursor.com. The picker has lied about Fast more than once. The usage row has not.