Show HN: OpenRig – agent harness that runs Claude Code and Codex as one system (github.com)
So I built OpenRig, a multi-agent harness. A harness wraps a model. A "rig" wraps your harnesses. You describe your team in a YAML file, boot it with one command, and get a live topology you can see, click into, save, and bring back by name. Claude Code and Codex run together in the same rig. tmux is still doing the talking underneath. I didn't try to add a fancier messaging layer on top.
The project is still early. My own setup uses the config layer extensively (YAML, Markdown, JSON) for prototyping functionality that outpace what's shipped in the repo and npm package. But the core primitives are there and the happy path in readme works. It's built to be driven by your agent, not by you typing commands by hand.
README: https://github.com/mvschwarz/openrig Demo: https://youtu.be/vndsXRBPGio
5 comments
[ 2.9 ms ] story [ 12.6 ms ] threadSome topics I've been asked about: tmux as a transport primitive (actually a pretty nice unlock), how snapshot/restore actually works in practice, hows this different from a harness framework, why I didn't just build this into Claude Code, why I think the topology layer needs to stay independent from any one vendor's platform, etc.
(14 years lurking on HN. First post.)
The original motivation for making OpenRig is this pattern works well I've been doing this for months now, and I'm sure many people have also gotten something like to work, but the topology is fragile. Like the sessions die, your laptop needs a reboot, you lose the setup you built up that took weeks to perfect. OpenRig makes the topology itself a first-class thing, like a docker-compose but for the topology of claude codes / codex on your machine and all their specific context and configs you fine-tuned.
Regarding supervision - that is the key question for sure - I can't really babysit more than 4-5 agents without feeling like I've lost the plot a bit. So the demo pod in the onboarding includes an example of a pattern I use where there are 2 orchestrators in a "high availability" pair, so I just really interact with 1 agent for the workstream - the orch-lead. The peer is there to monitor and absorb the lead's mental model in realtime, and can take over for the rig if the lead's context limit hits the wall, or something else goes wrong.