~$1,500 in one week running a Grok Bot fleet: expected, or a bug?

Support Help
1

We’re a scaling Belgian e-commerce startup (Angelo.be), with no enterprise budget. We’ve been running a Grok Bot fleet for about one week, and we’re very happy with what it does. But in that week we burned roughly $1,500 in extra usage, which is far more than we can sustain.

I’m posting for two reasons:

  1. Cursor Support: is this token usage normal, or is something going wrong (loops, retries, context bloat, agent-to-agent chatter)?
  2. Community: what best practices do you use to keep a multi-agent setup affordable?

Who we are

I’m CTO and co-owner, responsible for our digital landscape, without a technical background. We do our own fullfilment. To run the whole fulfillment proces we’ve build and run our own WMS, including our own support system. Storefront is Shopify.

Our bot setup: colleagues vs. tools

We deliberately split the fleet into two groups.

Colleague bots (handoffs, judgment, ownership)

  • Slaude: chief of staff. Routes requests, sets priorities, handles Slack inbound/outbound
  • Code Bot: implements changes and opens PRs on our WMS and related apps
  • Design Bot: UX for those product flows
  • Review Bot: reviews before merge
  • Documentation Bot: updates end-user docs in Notion after a change
  • Domain ops bots: Support, Finance, Marketing

Tool bots (narrow, repeatable jobs)

  • Shopify Bot: store admin and catalog operations
  • Klaviyo Bot: email/SMS marketing operations
  • Vercel Bot: reports deploy READY/ERROR and nudges the right coding bot
  • Migration Bot: applies Supabase SQL migrations, only when asked

Tasks live in Notion (a bot-managed kanban board plus a routines register). That keeps ownership visible without stuffing state into chat. Coding is done locally via Xirp on Claude models.

Where the time savings came from

The win wasn’t one smart chat. It was the chain. For example:

Bug report in our WMS → Code Bot fixes it → Design/Review Bot when needed → Vercel Bot watches the deploy → Documentation Bot updates Notion.

That’s team communication with bots, and that’s what we bought.

Slack integration

We also integrated Grok Bot into Slack by creating a Slack app that streams events to Grok Bot. Our staff work in Slack, and the flow is:

  1. Someone mentions @Slaude (the Slack app) with a question
  2. The question is sent via Slack Socket Mode to the chief of staff bot
  3. The chief of staff routes it to the right bot
  4. request is handled by the bot
  5. The answer comes back in the Slack thread

For humans it’s a simple mental model: one mention, and the right “colleague” picks it up.

What we’re now considering cutting

To stop the bleeding, we’d have to kill exactly the multi-agent behavior that made this worthwhile:

  • The chief of staff no longer delegates and follows up on tasks the other bots are working on
  • Bots no longer talk to each other
  • No more documenting steps
  • No more automatic Review / Design / Documentation passes

I’ve recently learned that you can start a bot with a blank chat to reduce context. Good that it’s possible, but it goes against the whole point of having everything in one window with one bot.

Bottom line

For a small ops team shipping its own WMS, cross-bot handoffs are the product. If we have to switch that off after one week just to survive on tokens, then Grok Bot’s main value is priced for enterprise budgets, not for startups.

I’m happy to share our usage data openly. If this really is the expected cost, small startups can’t sustain it, and the choice isn’t “optimize our prompts” but “gut the team model or leave.”

Scherm­afbeelding 2026-09-22 om 23.26.35
Scherm­afbeelding 2026-09-22 om 23.26.351910×1278 228 KB

Any insights, from Support or from others running similar setups, are very welcome.

Stijn

6

Hi @dotstijn Thank you for the post and glad to see your team taking advantage of Grok Bot and what it can do for you! I looked at your account, and I don’t see anything wrong or anomalous.

The cost comes from how Grok Bot works today. Every turn re-reads that bot’s whole conversation, so a bot that has been in one chat all week pays for its full history on every reply, even for a one-line handoff. Your busiest bots are re-reading roughly 80k to 90k tokens per step, and about a third of all turns are bots waking other bots.

You don’t need to give up the team model. For a setup like yours, these make the biggest difference:

  1. Fresh chat per task. Click the + at the top of the sidebar, pick the bot, and start a new chat for each bug or feature. Keep standing instructions in the bot’s Edit Profile and task state in Notion (which you already do), so a fresh chat loses very little. For Slaude, a fresh chat each morning with a short handoff summary works well.
  2. Quieter handoffs. Add a line to each colleague bot’s profile like: “Only message another bot when it needs to act. No acknowledgments, thanks, or progress pings. Send one summary when the work is done.” Each message that wakes a bot costs a full turn on that bot’s history, and its reply wakes the sender again.
  3. Space out routines. Two of your routines run roughly every 8 and every 30 minutes. Hourly or a few times a day will help to save money, as there is a cost associated with each routine iteration.
  4. Track your usage here: https://cursor.com/dashboard/usage Check on your stats here and see how these changes impact your daily spending.

Lmk any follow-ups!

7

Thanks for the swift reply. Just discovered the fresh chat option today :face_with_peeking_eye:. We have look at your suggestions straight away.

One small ask: would a one-time, exceptional usage reset be possible? Right now we’re (almost) locked out, which makes it hard to actually test and roll out the optimizations. A reset would let us get back to work and prove the setup can run a lot leaner.

Totally understand if that’s not possible, but pretty please :folded_hands:

Thanks again!

8

I’m not sure exactly how you’re determining when to run your routines, or what they are running, but lets say they are checking for new tasks (email/sms marketing), you may consider using webhooks so wherever those new tasks are being generated, they call a webhook to the exact and only grokbot whose job is to handle that task, which will wake it up on-demand, rather than constantly having to check with a routine. It may also be possible to actually pass useful information inside the webhook, therefore skipping the step of the bot having to go check a list, pick the new message, open it, read it, reply, etc, and instead just reply (ex: webhook contains the message id/url, and the message itself).
Webhooks are very powerful. Sometimes I have a grokbot whos job is to route certain things to the correct grokbot based on the webhook data - for instance, this is how I connected Astra/Codex to be able to wake grokbot and then message back the specific codex taskid who woke it up (that next turn is grokbot to codex over an MCP server I created).
Note that all of my webhook workflows were themselves created by Grok bot or a collaboration between grok bot and astra/codex.
Finally, if you need quick decisions about things, consider Jev (new system 1 model, ie: decisions) that is much more suited to binary decisions, classification, and even routing – so if you’re triaging/routing sms/emails/etc, you can take a lot of the initial work of what the message is and where it should be routed (including canned responses), and offload it to Jev at 20x-100x the speed and lower cost. It doesn’t replace the deeper thinking and actual language responses Grok Bot or any other agent can do, it JUST makes decisions/classifies).
Hope any of that was helpful.

10

Hi,

Thanks for the feedback. Almost no polling.

Token burning is related to old context reused on almost every message.

Stijn