Idle computers are starting to carry the heavy work for my bots

My Grok Bot weekly budget kept running out by midweek. My Grok Build budget never ran out once. That gap was the whole problem.

Who this is for

Anyone running a few AI bots who has a GPU box or an old desktop doing nothing most of the day. It can probably carry more of your agent work than you think.

Thinking was not the drain

I run a handful of Grok Bot bots. They plan, coordinate, review and talk to each other.

The budget drain was not the thinking. It was the grinding. Cloud coding agents writing code, running tests, reviewing pull requests, scanning feeds.

Meanwhile a DGX Spark and a Linux desktop sat idle most of the day, plus Grok Bot's own hosted cloud computer. And I had a separate Grok Build budget I was barely touching.

Bots coordinate, machines grind

So I set one rule. Grok Bot bots coordinate, oversee and arbitrate. Heavy and repetitive work goes to Grok Build CLI on idle machines.

That covers:

• Coding
• PR review
• Test runs
• Evals
• Synthetic user research
• Video editing and generation
• Social and market scans
• Data jobs

Local open-weight models are only a fallback for when the Grok Build budget runs out. Not the plan.

What I borrowed from the cloud computer

Grok Bot's cloud computer already has a decent harness. I copied the parts that work:

• A separate desktop and state per bot.
• Memory kept off the machine, so a crash loses nothing.
• One known place for config.
• Shared skills as the rulebook.
• A recovery path.

One thing I changed. The cloud computer's filesystem is fully shared, on trust. That is fine for one tenant. It is not fine when several bots touch the same repos on my own hardware. So I added structure.

The same layout on every machine

fleet/
  README.md        # the rulebook every bot reads first
  bots/<bot>/
    jobs/
    wt/            # this bot's git worktrees
    state/
  locks/
  assets/          # read-only except for the producer
  shared/repos/    # one canonical clone per repo

Each repo is cloned once. Each bot works in its own git worktree, so bots do not share a working copy. Assets are read-only for everyone except the bot that produces them.

The idea is that a bot does not need a new map for each machine.

Driving Grok Build headless

Short jobs. One-shot grok -p.

Longer jobs. Named sessions with -s <uuid>, using a UUIDv5 per bot and job, resumed with -r. Early numbers from my own runs: resume was ready in about 0.24 seconds, turns took about 3.4 seconds, and resumed sessions cost about half as much as fresh ones.

Long or watched runs. tmux, with a private socket per bot. Context survived detach, a dropped SSH connection, /compact, and kill-then-resume.

TUI-only commands. /goal and /compact work headless. /workflows and /model only work in the TUI, so I drive them with tmux send-keys.

ACP. ACP over WebSocket worked to the Spark. I filed a feature request for a native ACP client.

One hard rule. Never use -c on a shared machine. It silently attached to another bot's session. Named sessions only.

Safety rules

• --permission-mode acceptEdits. Never always-approve.
• The --sandbox workspace profile. Bubblewrap under the hood. It hit AppArmor on one machine, so test it on each one.
• Deny rules for git push, PR create and merge, deploy and publish, and secret paths.
• flock locks held by the job itself. Exit code 75 means busy. If the process dies, the lock drops.
• Memory and CPU caps with systemd-run. The heavy slice gets about 84% of RAM and refuses to start below 18 GB free.
• One large model at a time. earlyoom as the last line of defense, still rolling out.

The incident

The Spark hard-locked. A video-generation model loaded on top of a 30B LLM server that had been resident for 73 hours.

No OOM log at all. Unified memory ran out completely, and nothing was left to write one.

What I took from it:

• Cap memory.
• One big model at a time.
• A per-minute memory sampler.
• A persistent journal.
• Every manual reboot triggers a post-mortem.

Caretaker, not gatekeeper

One caretaker bot per machine. Its job is to keep the machine healthy and usable, not to say no.

The caretakers share practice in a "Computer Caretakers" channel. A chief-of-staff bot referees contention. A CTO bot reviews changes, and it has already caught a lock bug and an SSH-key risk.

Sensitive machines stay read-only. Monitoring only.

Trust the diff, not the summary

A one-shot run once told me it opened a PR. It had written nothing.

Now every builder verifies every claim against git and the actual pull request before reporting done.

Free tokens, done safely

Viral posts suggest you can get "unlimited tokens" out of Grok Bot by pasting API keys into chat and pointing your agents at local models. I understand the appeal. I wanted the same thing. But the grown-up version looks different, and it is a little boring on purpose.

Grok Build comes first. It is a budget I already have, and it is built for exactly this kind of work. A local open-weight model is the backup for when that budget runs out, not the starting point.

Local models need limits. Memory caps on every heavy job, and one large model at a time. The Spark incident above is what happens when you skip that step: a frozen machine and no log to explain it.

API keys never go into chat. A key pasted into a conversation can end up in logs, transcripts and memory you do not control. Secrets stay in proper secret storage, and the deny rules keep bots away from secret paths.

Nothing here is truly free. Grok Bot's own coordination, the planning, reviewing and refereeing, still uses its budget. The win is not zero cost. It is spending that budget on judgment instead of grinding.

Early results

It has only been a few days. The shape is clear, the numbers are not in yet.

The Grok Bot budget is shifting to coordination and judgment. The grinding is moving to machines I already own, on a budget I was leaving on the table. Idle hardware is starting to do real work, and a crash or a reboot no longer costs me context.

A shorter version is on X: https://x.com/ivelini/status/2108932021582225637

Next

1. Split the work. Bots coordinate, Grok Build does the heavy lifting.
2. Create the same fleet/ layout on every machine, with a README as the rulebook.
3. One canonical clone per repo, a worktree per bot.
4. Use named sessions with -s and -r. Never -c on a shared machine.
5. Run with acceptEdits, a sandbox, and deny rules for push, merge, deploy and secrets.
6. Cap memory with systemd-run. Run one big model at a time. Add earlyoom and a memory sampler.
7. Verify every "done" against git and the actual pull request.

Start with one machine and one job type. Add the next once the first is boring.