Cut your Grok Bot team’s usage

1. Where the usage goes

Grok Bot measures usage in agent steps and tokens, not in messages. Each time a bot runs, it reads its instructions, its tools and the conversation so far, then does the work. In a long chat, the reading dwarfs the work. Cursor’s own staff put it plainly when people asked why their totals were so high: each run re-sends the conversation’s context.

A group chat multiplies that. Grok Bot groups hold two to six bots, and xAI’s guide says to “write normally to let the participating Bots decide who should respond”. A bot cannot decide without reading, so a message with no @ is read by every bot in the room.

Then the replies. xAI is explicit: every bot reply counts toward your usage, including replies in a group and messages between bots. Each reply also makes the conversation longer, so every later read costs more. Four bots saying “got it” is four billed turns, and a longer chat for all of them.

So the lever is not shorter prompts. It is fewer bots reading on each message, and less for them to read when they do.

2. One lead bot per project

1. One lead bot owns the conversation. You talk to it, not to the room. If you followed how to set up a Bot Team, this is your manager bot.
2. Shared state lives in a notes file.Open tasks, decisions, who owns what, the job ids. Bots read it when they need it, not the whole history. In the Bot Team guide this is the board. It has to sit somewhere every bot can reach, because each bot’s own memory and chats are private.
3. Specialists are called for real work.The lead sends a specialist a short brief by direct message and points it at the notes file. The specialist does the step, reports back, and goes quiet. It does not sit in the room reading every “ok”.
4. Every bot gets the quiet rule. Ask each one to remember it.

Do not reply with acknowledgements. Only reply if you have something to contribute or were @-mentioned. Do not message other bots unless the lead bot asked you to.

A standing brief for the lead:

You are the lead for this project. I talk to you, not to the specialists.

Keep the project's shared state in the notes file: open tasks, decisions, who owns what, the job ids. Update it when something changes. Keep it short: state, not history.

When a task needs a specialist, send that bot a direct message with a short brief and point it at the notes file. Do not paste the conversation. When it reports back, update the notes file and tell me in one line.

When this chat gets long, write a handover into the notes file and tell me to start a fresh chat.

Do not reply with acknowledgements.

You do not have to tear down a working channel to start. The first two wins (an @ on the lead, the quiet rule) work in the channel you have. The test in the next section tells you whether the rest is worth it.

3. Test it before you change it

Grok Bot does not show a wake count per message, and the usage percentage moves in coarse steps, so the only honest way to know what your layout costs is to run the same messages through it twice and count. We put the pieces in an open-source test harness on GitHub: an estimator, the test sequence, a compare script and the prompts. It needs only Python.

Step 1. Estimate, for free

The estimator models a group chat against a lead bot on the same messages, and spends no usage:

python -m harness.estimate --bots 5 --messages 20
python -m harness.estimate --bots 5 --messages 20 --directed-share 0.8
python -m harness.estimate --bots 5 --messages 60 --fresh-after 15

Swap the defaults for numbers from your own chats: how many bots, how often you @ one, how often they reply.

Step 2. Measure, on a throwaway group

1. Make a test group with two or three low-value bots, so you are not paying to re-read a big history.
2. Note your usage: under Usage at grok.com/dashboard on The X Subscription, or in Grok Bot under Settings, Usage & Billing on a legacy Cursor plan.
3. Print the log (python -m harness.sequence --run baseline > baseline.csv) and send these seven messages, one at a time:

After each one, write down how many bots showed activity (in the group or in their own chat), how many replied, and the usage before and after. Leave a cell blank rather than guess.

Step 3. Ask the lead bot for its view

Paste the audit prompt into your lead bot. It changes nothing until you say so. Treat its counts as a second opinion beside your log, not as a meter.

List every group chat I'm in with more than one bot. For each, count how many bots woke up on my last 20 messages and how many actually replied. Propose one lead bot per chat and move shared context into a notes file. Show me first, change nothing until I confirm.

Step 4. Change one project, and run it again

Move one project to the lead bot and notes file, send the same seven messages as a second run, and compare:

python -m harness.compare baseline.csv lead-bot.csv

The compare script reports wakes per message, idle wakes (a bot read everything and added nothing) and the usage change, split by undirected messages, directed ones and acknowledgements. Read the wake counts first; the usage percentage is the check.

4. What the model shows

The estimator, with its default numbers: five bots, 20 messages, an 8,000-token base for every bot, each message or reply adding 400 tokens, and half the bots that read a message replying. These are a model, not a measurement. Your own run is the one that counts.

Three things stand out:

• The @ does most of the work. Addressing the lead instead of the room takes the gap from about five times to under one and a half, with no other change.
• Acknowledgements are not free. The quiet rule alone cuts the group’s re-reading by about a third, because every reply lengthens what every bot reads next.
• The gap grows with the chat. Run the same group to 60 messages and it re-reads nearly seven times what the lead bot does. Long group chats are where usage runs away.

5. Hand over to a fresh chat

Even a lone lead bot re-reads its own chat every time. When a project chat gets long, have the lead write a short handover into the notes file and start a new chat that begins from the notes, not the history. Cursor’s staff gave the same advice for long-running conversations: a fresh one cuts usage a lot.

In the model, a 60-message project handed over every 15 messages cuts the lead bot’s re-reading to a little over half what it was as one long chat, and the group’s to about 40%. The notes file is what makes it painless: the new chat already knows where everything is up to.

6. The order to do it in

1. Baseline: the audit prompt, a usage snapshot and one run of the seven messages.
2. Move one project to a lead bot and a notes file, with the quiet rule on every bot.
3. Send the same seven messages and the audit prompt again.
4. Compare wakes per message and the usage change.
5. Move the next project only where the numbers say it is worth it.

Grok Bot changes most weeks, and what counts toward usage could change with it. That is why the test is the point, not our numbers: run it again when the product changes.

7. Questions