Grok Bot with T3 Code · Start My AI

14h • Chat

Grok Bot with T3 Code

I’ve been running pstack inside Cursor for a while. It's a great setup with one problem. Every delegate runs at Cursor usage rates, so the models I actually want on hard tasks were too expensive to use by default and maxing out my free other usage that I prefer go to bug bot. Meanwhile I'm already paying for Claude Max, ChatGPT Pro, and SuperGrok Heavy. I wanted the pstack playbooks with my subscriptions doing the work.

So I forked it. Grok Bot became the orchestrator and T3 Code became the execution layer which would give me similar workflows to using grok bot with cursor cloud agents except the cloud is my hardware, and I can use my subscriptions instead of cursors api rates for my other models as well as incorporating my local models and open router if necessary. And I can do it all from my phone which allows me to leave my office and still get work done :)

Grok Bot holds the router, the playbooks, and the table that says which model handles which kind of job. It decides what runs where and writes the brief. T3 Code runs on a Mac Studio in my home network and wraps the coding CLIs I already pay for: Claude Code, Codex, Grok Build, and a local model. For each step, Grok Bot opens a T3 thread on the right provider, sends the brief, waits, and reads the results.

My original plan was to have Grok Bot use T3 Code the way I do: through the app. That went badly. T3 is built for a human with a screen, and the Bot struggled to drive it reliably. It could get a thread open, but sending work in, knowing when the delegate was actually finished, and pulling the result back out was fragile every time. An orchestrator that can't tell "done" from "still thinking" isn't an orchestrator.

The fix was to stop asking the Bot to use a UI and give it a tool shaped for a bot. We built a small command-line tool with exactly the handful of actions the playbooks need: start a thread, send it work, wait for it to finish, read what came back, cancel it. Every action has a clean start and a clean end. Once the Bot had that, the pilot lanes ran hands-off. That's the biggest lesson in the whole project: if an agent is fumbling a tool, don't write a better prompt, build a better interface.

The second problem was memory. In Cursor, a pstack delegate is spawned from the parent conversation, so it inherits what the orchestrator already knows. A T3 thread is a brand new session. It has never seen the Bot's conversation, the previous thread, or the review it's supposed to build on. Nothing carries over.

That forced a rule I now think is correct anyway: every brief has to make sense to a stranger with no access to the chat. Briefs follow a fixed structure, and when one delegate depends on another, the earlier result gets pasted in whole rather than referenced. The shared guidance the delegates need lives in the repo where every CLI finds it on its own, so a delegate reads from disk instead of expecting the orchestrator to have explained it. And the Bot never reopens a thread to add scope; it starts a fresh one with the full picture. Threads are disposable. Briefs are the contract.

That created one more gap. Some of pstack's best skills look backward: they mine past transcripts to recall how a similar problem was solved, or to reflect on a run and turn what happened into lessons. In Cursor that history is right there in the conversation. In the fork, it's split in two. What the delegates actually did lives in T3's session files on the Mac Studio, and why the orchestrator made the calls it made lives in Grok Bot's own history. So we wrote a small script on the T3 host that reads the session files and turns any thread into a plain transcript the Bot can pull into a brief, and pointed the recall skill at that. The reflect skill goes the other way and reads the Bot's own history, because the decisions are what you want to learn from, not the diffs. Losing Cursor's transcripts felt like a step back at first. Having the two kinds of history separated turned out to be cleaner.

I learned quite a bit on this project that will definitely help me on my journey.

**Don't fork the thing that ships daily.** My first instinct was to fork T3 Code itself. It updates constantly and I'd have been rebasing forever. Instead our tool pins to a specific T3 version with a simple bump procedure. Fork the plugin, not the platform.

**T3 is the window, not the harness.** Each thread is one provider session underneath. All the routing logic has to live in the orchestrator.

**Record the job before you start it.** We lost the ability to cancel a run once because the bookkeeping happened after the work kicked off. A log that only records finished work can't stop anything.

**Silence isn't a stall.** A delegate that was waiting on purpose looked hung. Check whether it's alive before declaring it dead.

**Write down what you didn't test.** Every phase's status notes which checks were skipped. A status report that only lists passes is how gaps go invisible later.

So whats next? The PR lifecycle consisting of watching PRs, handling review comments, and landing stacked changes, all running on the T3 host on a timer for hours at a stretch. At some point if there is interest and I feel the quality is acceptable I will make some public GitHub repo’s for the community with my cli and the forked T3 version of pstack.

2 comments

Grok Bot with T3 Code