My Codex setup has evolved beyond a normal coding assistant. It now works as a background operational coordinator for my daily work, particularly email, quotations and the small decisions that would otherwise constantly interrupt me. I receive around 120 emails per day. A large percentage is internal chatter or information I need to be aware of but don't need to act on. Others require quotations, replies, follow-ups or specific actions. Instead of manually processing that stream, I have a coordinator chat in Codex that periodically receives my email and decides what should happen next. It can classify emails, archive or mark them unread, suggest what I should do, create drafts, send emails when appropriate and delegate work to specialised chats. For example, quotation requests are sent to a dedicated quotation chat with its own strict skill and workflow. When the quotation is finished, that chat communicates the result back to the coordinator, which then tells me that it is ready for review. The important part is that I remain in the loop without having to operate the system continuously. Codex's live voice is particularly valuable here. I can be working on something completely different while the coordinator continues processing things in the background. When something genuinely needs my judgement, it can simply talk to me: «“You received this. I think it should be archived and marked unread. Do you agree?”» Or: «“The quotation is ready for you to check.”» I answer by voice and continue working. Instead of reading and deciding what to do with 120 emails, I mainly deal with the relatively small number of decisions that actually require me. Why the model matters This is also why I currently cannot simply replace Codex with Grok Bot, even if Grok can technically perform the same orchestration. I have tested this. The problem isn't whether Grok can read an email, delegate to another chat or communicate results back to the coordinator. It can. Most of the architecture works.

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.

Hi @Ray Fernando or anyone else. When you did your T3 Code stream you were talking about finding an open source version of Grokbot. What are you or anyone who has tried it thoughts on Open Maus Bot: https://www.openmausbot.com/

I tried the codex app's computer use functionality last week with 5.6 luna. I had it delete an email, then delete an email based on the sender's name. Then change my brave browser's default search engine from brave to google search. It oneshotted everything. I was surprised because a year ago I tried something similar with computer use and gpt-4o. It failed miserably. Codex only released in feb and it's computer use is already so good. I am in the construction industry doing a startup and computer use has so many use cases, it can input hundreds of items that have to be normally written manually. Saves hours of time. Haven't been this impressed about something ai related in a while 😁

Got access to Astra on my pro account and decided to start trying to build a mobile game my friend and I have talked about for a while now. inspired by Ray's stream the other night I just kind of riffed a bunch of game concept information with a couple reference images generated by image 2. It's gotten pretty far just vibing and we've got a basic scaffolding of a game with working mechanics in test flight we are iterating on. My Question: At which point do more "experienced" devs turn this into a spec driven workflow and start using something like the pstack, etc to fine tune this and turn it into a valid game? What plugins/processes do people like to use to turn an starter project like this into a spec?