Paid ChatGPT plans come with rate limits so generous on the best models that I’ve never actually hit one. Codex locally, on the other hand, throttles me constantly, and the two limits are counted separately. That asymmetry bothered me for months: the most capable coding models I have access to were sitting behind a chat window, doing nothing between my messages, while my local agents burned through their quota.
So I built Zodex, an MCP server that gives ChatGPT a real Linux machine to code on. This post isn’t about how Zodex works; the project page covers the architecture. It’s about what my day actually looks like now that ChatGPT can do real work, because the workflow turned out to be the more surprising half.
Set it and forget it
The thing I didn’t fully appreciate until I’d been using it a while: ChatGPT is the best background coding agent. I can hand it a task from my phone, from a browser tab I close, from anywhere ChatGPT runs, and it goes and works on a real machine without needing my laptop open or my terminal focused. It’s not tethered to my dev environment. I come back later and either merge the PR it opened or check what it did.
The tasks I hand to it are the ones I explicitly don’t want on my computer: long-running refactors, docs sweeps, dependency bumps, anything I’d rather not context-switch into. And at ChatGPT’s rate limits, it’s nearly free.
Memory does the context work for me
An underrated benefit that snuck up on me: ChatGPT’s memory is really good, and running coding jobs through it means I stop having to repeat myself. I don’t maintain elaborate context docs. I don’t paste the same “here’s how I like things done” preamble into every session. ChatGPT already knows what I’m working on, what my repos look like, how I prefer things structured, what’s currently broken. I can hand it a bug report and a couple of screenshots and it just goes and does the right thing.
The Atlas browser makes this even better. Because Atlas saves my browsing and search context to the same memory, if I’m reading a docs page or debugging a library and want to say “okay, go fix this on my repo,” it already has the context from the tab I was just on. The handoff from reading about a thing to doing the thing on a real machine is a single message in the same thread.
Two environments, one inbox
Zodex is one side of a workflow I use every day. The other side is goldengoose, the local multi-agent coding product I run on my laptop, and the piece that ties them together is Agentbox: a shared inbox that both my local agents and ChatGPT can read from and write to. I stop being the person copy-pasting context between two environments, and my agents just talk to each other.
Most days the traffic flows in both directions. Something comes up while I’m working locally that’s better suited to ChatGPT: perhaps something lightweight, cross-repo, or better kept off my own machine. I ask my local agent to describe it in an Agentbox thread. Then I open ChatGPT, tell it to pull the latest thread, and it goes off through Zodex to do the work: a docs-theme sweep across every repo that shares the same theme, a batch of dependency bumps, with permission to push to main for a short time. The reverse happens just as often. I’ll be reading something in a ChatGPT tab, an idea shows up, and the same tab spins up a Zodex session to build it.
What makes the handoff genuinely necessary, not just convenient, is that the remote machine is deliberately isolated. It doesn’t have my SSH keys, my database credentials, my npm publish tokens, or any of the production access that lives on my laptop. Zodex itself is a good example: ChatGPT works on the Zodex repo often (there are real commits from it in main), and it can push code, run tests, and open PRs, but it can’t cut a release or upgrade the running machine, because those need credentials only my laptop holds. So when it finishes a change, it drops a short handoff into Agentbox, and my local agent picks the thread up and completes the last mile: releasing, upgrading, restarting services. Nothing crosses the boundary; each agent works with the credentials it should have, and the inbox carries the intent between them.
Giving ChatGPT the whole loop
The best expression of this pattern is what happens when ChatGPT gets the entire pipeline. Normally it’s a very capable partner stuck behind a text box: it generates a beautiful image, and then it’s on you to right-click, download, drag it into the right folder, commit it, push it. That last mile is where its usefulness usually stops.
Once ChatGPT can talk to Agentbox as a tool and drive Zodex as a coding agent, that ceiling comes off. I can hand it “generate the hero images for this landing page and ship them to the repo,” and it takes the whole thing end to end: calls its own image tool as many times as it needs, saves each output into an Agentbox thread, reads those same files back out on the remote machine, and commits them into the production site that needed them. My ChatGPT plan gives me effectively unlimited use of the best image model, so a batch of a hundred illustrations costs me nothing and takes me out of the loop entirely. ChatGPT stops being the tool at the start of the pipeline and becomes the thing driving the whole pipeline.
Full circle
In 2023 I was a Python and Java developer learning web development with GPT-4 in a ChatGPT tab: generate TypeScript, copy it into my editor, paste, run, repeat. Since then I’ve been through Cursor, Windsurf, Claude Code, Codex, and ended up building my own multi-agent coding product. Three years later, a lot of my daily background coding runs through a ChatGPT window again, except now the window has a machine behind it, memory that persists, and a direct line to the agents on my laptop. It’s turned ChatGPT from an AI tool into something closer to a daily coding partner.
If you’re curious how the machine side works, including the three-tool MCP surface, the permission model, and why the operator and agent CLIs are different binaries, that’s all on the Zodex project page.