With unlimited tokens, the constraint becomes compute power: CPU, memory, disk space. Dan Luu’s and Dennis Snell’s work inspired me to move from managing Codex sessions to assigning it a big task and a pool of compute resources to maximize.
It burns tokens! I’ve got through ~120 billion tokens since Thursday. Dan is at ~300 billion total.
How I’ve started 80 codex sessions
My home cluster has a total of ~80 CPU threads, 288 GB of RAM, and 20TB worth of fast SSDs:
I’ve started two VMs with 20 CPU threads and 40 GB of ram each, and one smaller VM with . Then I started codex in a tmux session in each. I’ve asked them to:
- Build a direct PHP -> binary compiler
- Port Lightning css, libsqlite, pandoc, and other tools to PHP
- Build a push my changes to the remote site feature for Reprint
My prompts could be summarized as:
/goal you will supervise a swarm of codex sessions to build projectspec.md. One worker = one tmux window so I can inspect. Have a critic to candidly evaluate your performance every hour and nudge you in new directions. Maximize the available cpu and memory, use git worktrees, integrate and commit frequently, update progress.html on github pages every 15 minutes.
Until today, most of my Codex interactions were telling it what it did wrong. In this project, I don’t want to do that. I’m delegating this responsibility back to Codex.
Shortly after prompting, I had ~80 codex sessions actively working on my three projects!
Codex loves being lazy
It wasn’t a one-shot prompt. I had to poke the supervisors to actually delegate the work, use the CPU and ram, not kill its own PID, keep reporting the progress, you get the idea.
Codex also keeps misrepresenting the progress. The PHP compiler project got up to 88%, down to 60%, then 92%, then 70%. The porting project got up to 95% and just stayed there despite intensive GitHub activity.
I also asked it to optimize its own workflow and reorganize around more performant setups. Reprint push got stuck in an overthinking loop and kept lying that it’s working in a productive direction. I had to strongly nudge it two or three times before it confessed and reoriented.
Nonetheless, I’ve prompted it maybe ~30 times since Thursday. Not too bad!
Results so far
All three projects are still running. The progress updates are published on GitHub a few times every hour:
Will they reach a satisfactory standard? Hopefully! I will continue monitoring those swarms until some closure emerges, whether that’s a finished project, hitting a wall, or unlimited codex running out.
One more idea!
I’d love to try the following idea once I free up some compute resources:
Hey Codex! Here’s a repository, find the largest opportunities and the most pressing issues and use 10 agents working in separate lanes continuously improve it. Your goal is to be an always running improvement agent. Do creative things, use the browser, write and run tests, profile code, try weird things and learn from them, use sqlite as your memory and coordination layer.
Until then, feel free to snatch it and explore it!
Leave a Reply