Files, Pixels, Sessions.

How to run Claude, GPT-6 Astra and Grok Bot as one machine - a 12-step playbook.

---

Everyone is asking which of the three is best.

It is the wrong question, and the wrong question is expensive. I have watched people pay four figures a month for three subscriptions that duplicate each other's strengths and cover none of each other's blind spots.

Here is the thing nobody writes down.

These are not three competing assistants. They are three agents standing on three different floors, and each one can only check its own work in the substrate it can touch.

Claude Code lives in a filesystem. It writes a file, runs the test, reads the exit code. The check is deterministic. It can fail loudly, at three in the morning, with nobody watching.

GPT-6 Astra lives on a screen. It opens Blender, models, screenshots what it made, and looks. The check is perceptual. It can be satisfied by something that looks right and is wrong.

Grok Bot lives in live sessions. Its own cloud computer, your browser, your logins. It sends the email. It files the ticket. And the world does not return a diff.

Verification gets weaker as you go down that list. Blast radius gets bigger. That inversion is the whole problem, and almost every agent failure people blame on "the model" is a job that was placed on the wrong floor.

This is the 12-step playbook for placing it correctly, and for building the one thing none of the three vendors will build for you: the handoff between them.

---

Phase I -Draw the map

1. Name the substrate, not the product

Products change every six weeks. Substrates do not. Before you decide anything, write one line per agent - not what it is good at, but what it can prove.

2. Sort your jobs by what can fail loudly

Take the work you actually want automated and split it in two piles.

Pile one: anything where a machine can tell you it went wrong. A failing test. A diff that does not apply. A schema that does not validate. A render that does not match a reference.

Pile two: everything else.

Most people's automation backlog is 80% pile one and they route it as if it were pile two, because pile two is where the impressive demos are. The demos are impressive precisely because nobody is checking.

3. The pyramid is upside down

Draw it once and you will not forget it. The agent with the strongest verification has the smallest blast radius. The agent with no verification has your credentials.

That is not a design mistake by anyone. It is what happens when three companies optimise three different products in isolation. But it means the default gravity of your setup pulls work downward - toward the floor where it is easiest to start and hardest to check.

Your entire job is to fight that gravity.

---

Phase II - Route the work

4. The demotion rule

One sentence, and it is the most valuable line in this article:

Every job goes to the strongest verifier that can do it. A job only moves down a floor when the floor above it physically cannot reach.

Not when the floor below is more convenient. Not when it has a nicer interface. When it cannot reach.

5. Never let a model click what it could script

This is step 4 applied to the single most common mistake of the last month, and it has a number attached.

Astra can drive Blender two ways: by clicking through the GUI like a person, or by writing Blender Python and running it. The outputs are not comparable. One is a model guessing at a viewport from a screenshot that does not contain the geometry; the other is code that either runs or throws.

@sirHe12, who measured it:

"The cardinal sin is letting the AI drive the GUI like a human - screenshot round-trips burn your cap in two minutes. This whole pipeline is scripted: the model writes Blender code and Godot scene files directly. Roughly 100x cheaper."

And: "bpy and MCP are far more stable than pure Computer Use screenshot-clicking."

@op7418 built a complete 3D roguelike - day/night cycle, weather, texturing, weapon switching, melee and ranged enemies - for 3% of a 20x quota, fully scripted.

The rule generalises past Blender to everything: computer use is the fallback for software that has no API, not the default for software that does. Astra scores 72.6% on OSWorld 2.0, the computer-use benchmark. That is a good score. It is also a 27% failure rate on a thing you were about to leave unattended.

6. Price the routing decision, once

Two published numbers should end the "just add more agents" reflex.

Anthropic's own multi-agent research system outperformed a single agent by 90.2% on their internal eval - and consumed roughly 15x the tokens to do it. In their own analysis, token usage alone explained about 80% of the performance variance. Tool calls explained ~10%. Model choice, ~5%.

Read that again. The multi-agent win was mostly bought, not designed.

Which means a fan-out is a purchase decision, not an architecture decision, and it only clears when the task is worth more than the tokens. In a head-to-head build test this month, AICodeKing logged roughly $198 of tokens for one model against $113 for another on identical work - and preferred the cheaper one's output on the larger projects.

Cheap does not mean worse. It usually means better-routed.

---

Phase III - The handoff nobody is building

7. The artifact is the handoff, not the conversation

The three agents cannot talk to each other. There is no shared thread, no protocol, no common memory. People treat this as a limitation to route around. It is the best thing about the arrangement, if you use it properly.

Because it forces the handoff to be a file - and a file is the only thing all three can read, diff, and be held to.

Concretely: Claude writes BRIEF.md with the rules and the schema. Astra reads it, produces the asset, writes what it produced and how into the same directory. Grok Bot reads that, acts in the world, and writes back what it actually did with a link.

The chat log is not the record. The directory is the record.

Note that the best Grok Bot operators have independently converged on this inside one vendor - SpaceXAI's own guidance is to keep research, drafts, evidence and handoffs in /workspace rather than in chat, so any bot can pick up exactly where another stopped. The cross-vendor version is the same idea with the volume turned up, because across vendors there is no chat to fall back on.

8. Every handoff carries custody

A file that says "done" is worthless. A handoff needs three fields, and it takes ten seconds to write them:

• the claim - what this step says is true

• the evidence - the test name, the screenshot, the row id, the message id

• the producer - which agent, which run, when

This is not bureaucracy. It is the thing that lets you answer "why does the system think that" six weeks later, and it is the difference between an agent chain you can debug and one you can only restart.

There is research behind this.

9. Wire the vendors with code, not with yourself

The moment you find yourself copying output from one app into another, you have become the integration layer, and you are the slowest and least reliable component in it.

This is already solvable today, and hardly anyone is doing it. AI LABS demonstrated the pattern: a command-line tool that lets an agent create Grok Bot bots and dispatch tasks to them programmatically. Finish a feature in Claude Code, and Claude sends the test job to a group of bots that are actually signed into your product; you get one summary back. No app switching.

Their own framing of why this specific pair works is the cleanest statement of the whole thesis I have seen anyone make out loud:

"Claude Code can already drive a browser and test your app, but it isn't signed into anything. When a Grok Bot test comes back wrong, the lead bot can open Supabase and check what actually happened behind it."

That is two substrates covering each other's blind spot. Deterministic verification from the floor above; live session access from the floor below. Neither one could produce that result alone.

---

Phase IV - Gates, perimeter, decay

10. Put the gate at the substrate boundary

Most people put one approval step at the end, where it is too late to be cheap and too vague to be useful.

Put it where work changes floors instead. That is where information is lost - a deterministic result becomes a picture, a picture becomes an action - and lost information is exactly where a chain amplifies its own mistake.

Two gates, and open them on reversibility, not confidence:

• files → screen: does the artifact match a reference the file layer can check?

• screen → session: is this action reversible? Reversible passes. Irreversible waits for a human, permanently, regardless of how sure anything claims to be.

Confidence is the weakest possible input to that decision, for a reason that is easy to miss: it is the only variable the model itself controls.

11. You have one perimeter, and it is not the one you are watching

Everything above is about correctness. This one is about the thing that will actually hurt you.

Grok Bot's design is that your bots share one persistent cloud computer - one browser, one set of logins. Sign into an account once and every bot you ever create can use it. That is the feature. It is also, in Nate B Jones's words, "one shared computer authorizes every bot at once."

So the perimeter is not per-bot. It is per-account, and it is permanent. Three rules, and they cost nothing:

• Connect only what is currently needed, and disconnect what stops being needed.

• Never type a credential into a chat message. The correct pattern is the login handoff: the bot hits the wall, hands you the screen, you authenticate, it resumes with a session - not a secret.

• Draft-only by default on anything outbound. Let the reversible work finish unattended and let everything irreversible queue.

That third rule is the one that turns an always-on system from a liability into an employee.

12. Delete your setup when a model ships

Every layer you write - the instructions, the workarounds, the elaborate prompt scaffolding - was written to compensate for a model that no longer exists.

Anthropic cut roughly 80% of Claude Code's own system prompt when Opus 5 shipped. Boris Cherny's rule for what to delete is the only one you need:

Would the model have worked this out on its own? If yes, delete it.

Run that pass on your CLAUDE.md, your AGENTS.md, your bot descriptions and your soul.md files every time any of the three vendors ships.

The instructions that survive are the ones encoding something about your work that no model could infer. Those are worth keeping forever. Everything else is a tax you are paying on every single turn.

And while you are there, add the one Boris says people get most wrong: a check strict enough to fail.

He had Claude rebuild the Claude desktop app in Swift with a pixel-by-pixel screenshot comparison as the gate - and it ran for over two weeks. Without a check like that, he notes, an agent stalls out inside an hour.

Two weeks versus one hour. Same model. The check is the difference.

---

Sources

• MAST taxonomy - 1,642 annotated traces, 7 frameworks, 14 failure modes, 41.8 / 36.9 / 21.3 split: arXiv 2503.13657, Why Do Multi-Agent LLM Systems Fail?

• 90.2% multi-agent uplift, ~15x tokens, 80% of variance from token usage: Anthropic, How we built our multi-agent research system

• 100x scripted-vs-clicked, "cardinal sin" quote: @sirHe12

• 3D roguelike for 3% of a 20x quota: @op7418

• OSWorld 2.0 72.6%: OpenAI's published GPT-6 Astra benchmarks

• ~$198 vs ~$113 token cost on identical builds: AICodeKing, 5 Sept 2026

• "isn't signed into anything" / Grok Bot CLI pattern: AI LABS, 3 Sept 2026

• "one shared computer authorizes every bot at once": Nate B Jones, 14 Aug 2026

• ~80% of Claude Code's system prompt cut at Opus 5; the two-week Swift eval: Boris Cherny, via AI LABS