TL;DR
Six always-on bots ran 27 scheduled jobs for ten days and drafted 12 posts. I used four of them.
Grok Bot shows you no usage number, so nothing warns you that a job is wasteful until the plan runs dry.
Forty-three rules came out of it. About fifteen transfer to anyone running agents. The rest are house rules.
What I actually ran
On 21 August at 15:31 I switched on the first scheduled job. Ten days later six bots were running 27 of them, unattended, on a schedule I never touched again. Every number in this post comes from that window, 21 to 30 August, pulled off the machine rather than from memory.
The roster:
Gandalf is the front door. I talk to him, he hands work out.
Obi-Wan drafts posts.
Sheldon watches my repositories.
Bilbo writes to my Obsidian vault.
R2 handles inbox and messages.
Threepio covers life admin.
None of these is a chat window. A bot in Grok Bot gets a computer in the cloud, logins, its own memory, and a clock. A chat dies when you close the tab. A bot with a clock does not.
I have written before about what is real in AI agent loops and how to build a folder-native AI agent. This is the version that keeps working while I sleep, and the first one that cost me something to get wrong.
The number that does not exist
I asked my own fleet to report its worst spending day. The answer came back: not available.
There is a usage screen in settings. It shows a percentage bar broken down by product: API, Build, Chat, Imagine, Voice. Grok Bot is not on that list. Bot work is billed on its own allowance, separate from your plan, which is sold as a benefit and reads to most people as free.
It is not free. There is no per-bot number, no per-day number, no spend cap you can set, and no audit view of what a bot did. An audit view is listed as coming. Go past the allowance and you pay by token at published overage rates.
So the only signal you get arrives late. The plan runs dry and every bot freezes until the week resets.
That gap is why the rules exist. When you cannot measure a cost, you cap the behaviour that creates it. Every expensive thing a bot does can be named in advance. Searching the open web is expensive. Clicking through a browser is expensive. Thinking about a job that produces nothing is expensive.
So I wrote limits instead of dashboards.
What ten days actually produced
The six bots sent me 104 notifications in seven days. Two of them sent more than half: the front door sent 32, the vault bot sent 31. There are no read receipts anywhere in the product, so whether I opened any of them is not measurable. I know the pattern from my own behaviour. I stopped looking.
The drafting bot produced 12 posts in the same week. I published four. Eight went in the bin, most of them because I had already posted something better that day and nobody told the bot to stop.
That is the real failure mode of an always-on fleet, and it is not the one the viral threads warn you about. Nothing crashed. No bot went rogue. It worked, and two thirds of the work went nowhere.
The rules that carry the weight
Forty-three survived the first pass. About fifteen do the actual work. They fall into three groups.
Money rules
Only one bot may search the open web on a job. The others wait. A five-bot search swarm is the single fastest way to empty a weekly plan, and it almost never produces a better answer.
Put a new job on a bot that already does that kind of work. Six live bots means six mouths on one plan, not six free workers. A new bot is a new bill.
Use the connected app before the browser. Browser clicks are slow, they burn more, and they trigger sign-in prompts that stop the job dead.
If a job can spend money, the instruction names the maximum. The bot still waits for a yes before paying.
Silence rules
A scheduled job notifies me only when something new needs a decision. No “nothing to report” messages. The first week taught me that five identical unread alerts train you to ignore the sixth one, which is the one that mattered.
Each job remembers what it already told me and never repeats it.
Clocks sleep between midnight and eight in the morning. A repository check at three in the night spends the budget I need at nine.
The bot does the long read, and I get three lines: what it is, whether it matters, what to do. If a job does not save me that reading, it gets slowed or removed.
Stop rules
If the same screen, the same permission prompt or the same error appears twice, the bot stops and logs it. It does not retry. Retrying a blocked page for an hour is how you spend a week’s budget on nothing.
Every job names its outcome before it runs. A draft to post. A comment on a pull request. A decision to make. A job that only “checks” gets deleted.
Nothing sends, publishes or pays without me saying yes. That is three gates, and only three. Everything else the bots do on their own, because a bot that asks permission for ordinary work is worse than no bot.
What I threw out
The other twenty-eight rules are not wrong. They are just mine.
Several are the same rule written twice. One rule says put new work on an existing bot, another says do not hire a bot for a job someone already owns. That is one rule. Three separate rules describe how a job gets handed over, in slightly different words.
Others are reactions to a thread I read rather than to something my fleet did. Do not depend on a particular task app. Do not add a bot just because a screenshot showed a bigger setup. Ignore the crypto replies. All true, and none of it is fleet operations. It is a note about my reading habits wearing a rule’s clothes.
If you copy anything from this, copy the fifteen.
How to set this up in twenty minutes
Name the jobs you want gone, not the bots you want. Inbox triage is a job. Drafting is a job. Watching a repository is a job.
Give each job to one owner and write the owner list down. A job with no owner never finishes.
Run every new job once by hand and read the output before you put it on a schedule. A schedule you have never seen spends money silently.
Write the three gates into every bot: it does not send, publish or pay without you.
Every Sunday, look at which alerts you ignored all week and slow those jobs down.
Step five is the only one that compounds. Everything else is setup.
Frequently asked questions
What is Grok Bot?
It is xAI’s always-on agent product, first opened up on 11 August 2026 and now sold across the SuperGrok and Cursor plans. Each bot gets a cloud computer, logins, memory and a schedule, so it keeps working when you close the tab.
Does Grok Bot show how much a bot costs to run?
No. The settings usage bar breaks down API, Build, Chat, Imagine and Voice, and leaves Grok Bot out. Bot work runs on a separate allowance with no per-bot number, no spend cap and no audit view yet, so you find out you overspent when the plan stops working.
How many bots should I start with?
One. Add a second only when a job exists that the first one genuinely cannot own. Extra bots share the same plan, so every bot you add makes every other bot slower to reach.
Do multiple bots give me better security separation?
No. All bots share one cloud machine, including its files and its browser logins. A second bot can reach everything the first one left signed in.
Why did two thirds of the drafts go unused?
Because nothing told the drafting bot I had already posted that day. An always-on job keeps producing whether or not the output is still needed, so the rule now kills the second draft.
How long does this take to set up?
About twenty minutes for the structure. The rules come later, from watching what your fleet actually wastes in the first week.
Key takeaways
Grok Bot is missing from the settings usage breakdown, so hard limits replace the dashboard you do not get.
Six bots running 27 scheduled jobs sent 104 notifications in a week and produced four posts I used.
The real failure of an always-on fleet is not a rogue agent. It is working perfectly and producing output nobody needs.
All bots share one cloud computer, so adding a bot adds cost and access, never a security boundary.
Only three actions deserve a permission gate: send, publish, pay. Everything else should run without asking.
Forty-three rules collapsed to fifteen. The rest were duplicates or reactions to something I read.
Further reading
AI Agent Loops Decoded: What’s Real, What’s Hype - what an agent loop actually is, before you schedule one.
How to Build a Folder-Native AI Agent - the local version of this setup, with files instead of a cloud machine.
obsidian-second-brain on GitHub - the open-source vault system these bots write into.
The xAI Grok Bot product page at x.ai/bot
About the author
Eugeniu Ghelbur builds AI tooling and writes The AI Operator. He maintains obsidian-second-brain, an open-source Obsidian and Claude Code system used by over 4,300 developers. He writes about what he ships, including the parts that did not work.