5 Grok Bots Cover My Night Shift, and None of Them Is Allowed to Press Send

Most Grok Bot multi-bot setups don't make it to Thursday. On day one you spin up 7 bots, each login connects, and routines fire every few minutes. By the weekend, 6 are unwatched, 1 has done something nobody approved, and the budget is burned through.

A user (@0xDepressionn, called Dep below) went the opposite direction. 5 bots, each doing only one thing, running at night inside guardrails. Code tasks are handed to Opus 5.5 on a branch, never touching main. And one bot does nothing but check the other four before you wake up.

The status in the screenshot is blunt: the draft is written by a bot, the send button is pressed by a human.

The night shift and a chat window are two different things

A model is only responsible for answering. The layer outside the model decides what it can touch, what it can see, who checks the output, and when it stops. Grok Bot gives you that layer ready-made. The bot runs on a cloud computer with a browser, files, and a terminal, and it keeps running when the laptop is closed. The bot retains memory between runs and can be started on a schedule or by a trigger.

A user (Debbie O'Brien) put it clearly: many people think Grok Bot is just a chat window, but in fact each bot has its own computer, its own browser, email, and desktop.

That's where the opportunity is, and where the risk is. A bot that works while you sleep will also make mistakes while you sleep. So the whole setup revolves around three things: guardrails, so nothing irreversible happens before morning; a reviewer, another bot that checks the work; and real code work, with Opus 5.5 running through Claude Code on a night branch.

Five people, one role each

• Scout: every morning, finds what's blowing up in your field, up to 10 items, each with a link; if it hasn't been opened, it doesn't report it.
• Video finder: digs up long interviews worth clipping, with timestamps.
• Metrics: pulls real data, one table plus what moved; it doesn't write down numbers it hasn't reopened.
• Reviewer: opens every link, rechecks every number, gives each item a pass or fail plus the reason, and never quietly fixes anything.
• Lead: the only bot you talk to directly; it writes plans by slot and drafts posts.

Build order: reviewer, scout, and lead first. Once those three survive a week, add coder and metrics.

No bot can publish directly. Everything lands in the drafts box, and a human presses send.

Paste the rules block first, then talk prompts

All bots paste the same rules block first. The most important rules: the criterion is whether something can be undone; small actions can be permanent, big actions can be drafts; anything that needs your nod at 3 a.m. waits until you wake up; each routine keeps only the last 20 run records, because its own log is the evidence at 9 a.m.; claims without sources don't go into the brief.

The official Grok Bot account gave one use case: use it to scan the customer service queue and clear 204 tickets in one go, with one engineer approving the whole batch.

The schedule is deliberately slow

01:00 coder, 02:00 scout, 06:00 metrics, 07:00 reviewer, 07:30 lead. Choose the slowest schedule the task can tolerate. Every routine wake-up is billed, whether or not anything happens. Going from every hour to every 5 minutes makes 12 times as many runs. A user (Gipp) calculated: a routine on a 5-minute clock wakes 8,640 times a month, about $400 at Grok 4.6 API prices; hourly is $33. Same bot, same model, same prompt.

Some replies go the other way. One user said his bot clocks off at 11 p.m.; whatever it finds at 3 a.m. can wait until morning, and reading something fresh is better than waking up to a backlog from 5 bots.

Opus 5.5 handles the code

After the October update, Grok Bot chooses the backend model for a task itself, and Opus 5.5 is one of them. But there is no selector, so you can't force it. To make sure you're using Opus, go through the terminal.

The coder bot runs Claude Code in the terminal, logs in with your own Claude subscription, and works on your repo. Refactoring, running tests, checking dependencies, small fixes—all done at night. Know one thing first: all bots share the same computer, and every bot can use that login.

You need tighter guardrails. Allow reversible work: read, edit, test, lint, commit. Ask before push or adding a new dependency. Deny catastrophic operations: recursive delete, force-push, hard reset, .env, raw network requests. Deny takes precedence over allow, so no broad rule can open that wall.

The reviewer is the bot that matters

Every bot can be confidently wrong. Scout links a post that says something slightly different, metrics copies yesterday's number, coder's summary doesn't match the diff. A bot checking its own work passes every time.

The reviewer is the only bot with no stake in whether the other bots are right. It opens every link, reopens every number, and checks the coder's summary against the branch diff. Anything that doesn't pass doesn't reach your brief; it shows up as fail plus the reason, so you know what to fix.

Once a week, have the lead ask each bot: what do you believe about my setup. Correct what's out of date. Memory carries good habits forward, and it also carries Tuesday's wrong assumption to Friday.

Pitfalls, in the order you'll hit them

1. Too many bots on day one. 3 that survive beat 7 that die.
2. The clock is too fast. A 5-minute routine burns budget on runs where nothing happens.
3. Overnight approvals. Waiting for your yes at 3 a.m. means waiting until you wake up.
4. Connections. Every bot shares the same computer, files, and logins. Connect only what the work needs.
5. No model selector. Inside Grok Bot you can't control when Opus 5.5 is used. The terminal route is the guarantee.
6. Other vendors read your data. The model handling the task reads what the bot reads. For some work, that's a hard blocker.
7. Coder scope creep. One task per night. A branch you can't get through over one coffee is too big.

When you don't need this setup

If you're mainly asking questions and reading answers, ordinary chat is enough. If you can't describe the task to a new employee in one paragraph, fix the description first. If you have only one repetitive task, this setup doesn't start paying off until three or four tasks.

Short version: 5 bots, one role each, build the reviewer first. One rules block: drafts only, every claim has a source, stop after two failures, write one line of log per run. The slowest schedule, and 3 a.m. doesn't wait for anyone. Opus 5.5 runs code through Claude Code on a night branch, with the deny list standing guard behind it.

Draw the guardrails once, and the morning check fits on one screen.

One more thing: build the reviewer first. It's the bot everyone skips, but the one you'll check first every morning.