Yeah so right now OpenRig isn't trying to solve that problem yet, but thats a very interesting direction to take it someday. It currently assumes you the operator are running coding agents on a host you control, like your mac or a VPS, and you actually want all the agents to have access to the same network and file system, so they can work together without friction. It basically takes the core single-user UX of CLI coding agents like claude code and asks the question "what if i could scale this up and run 10, 50, 100 of these things in parallel." OpenRig is the result of the last 9 months of exploring that branch of the AI tree very heavily.
Yes exactly, topologies, aka rigs are basically ways of organizing work that benefits from agent collaboration, but it unlocks many benefits. One of the main benefits is "Context Domains", described in the linked video. Where you can extend the context window for the task you are working on by distributing it across multiple agents. Each agent or pod of agents works on a slice of the task together, sharing state, staying in their lane of expertise. The rig becomes a sum of its parts. A 10 agent rig, each agent with a 1 million context window, could effectively be viewed or operated as if it had a 10 million token context window. For my day job I work on very large brownfield codebases and this was one of my early solutions to being able to work on broad cross-cutting features. I don't rely on this alone but this general ability is quite useful for lots of things.
Thanks! It doesn't use A2A but that might be a good roadmap item, there's a ton of overlap with it. OpenRig already has a lot of A2A like wiring built-in but simpler and intentionally stripped down to keep things inspectable by a single human operator trying to manage a fleet of agents. It just uses TMUX for agent-to-agent messaging- super simple but effective. For tasks, handoffs, etc there is a custom event stream and queue system.
I posted a much earlier preview a few weeks ago. This version is the first one I’m actually inviting other agent-heavy developers to try, and I’d love feedback on where the mental model is confusing.
Yeah I can definitely relate with the snowballing. I am mostly building web apps (python/typescript) so ymmv. Have you tried to pair codex with claude? This is like the gateway drug for doing agent topologies. This is definitely worth trying. Claude is better at understanding your intent, but at the expense of it makes lots of mistakes. Codex makes less mistakes but at the expense of over-engineering. Together they are not perfect but significantly more accurate. They complement each other well. So Codex reviews claude, using TDD is even better because codex will gate each change claude makes. You can apply this pattern to implementation, reviews, PM, even research, etc. OpenRig has a spec called implementation-pair which lets you try this pretty easily. There is another one called adversarial-review which is the same topology just different starter context / instructions to make them less constructive, more combative. You'll get a feel for which one you need for a task pretty quick. But lots of people have made this pattern into skills. I think OpenRig is probably the easiest happy path to try it because the 2 agents can literally type into each others terminals using "rig send" and "rig capture" and see each other screens using tmux, as if you were the one typing the commands. But now you just sit back and watch them find and fix bugs. You dont need OpenRig to do this, just tmux, but raw tmux is a little fiddly to get working which is why i made the rig send command as a tmux wrapper.
Day to day I run a dev pod (implementor + qa + frontend design), a review pod doing adversarial review with one Claude and one Codex, and an orchestrator pair. I think the best flex here to illustrate real work being done is so far the longest single rig I've kept running continuously was about 4 days, so that means a large implementation spec being executed with test driven dev approach from obra superpowers + independent deep contextual code reviews at milestones (my own skill pack) + automated vercel agent-browser testing along the way. So currently it's a closed sdlc loop that is only limited by the amount of work I gave it. The "babysitting agents" part moves me up a layer to watching for spec drift and handling weird edge cases that come up. So its not set and forget but you can definitely have it work on something real overnight to get that 'my agents shipped code for while I slept' kind of outcome. I watch a demo video in the morning to see what they built, then do my own code review spot checks of pr's.
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.
OP here. Happy to answer questions or go deep on specifics.
Some 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.
Did you try llamaparse from Llamaindex? It’s a cloud service with a free tier. Recently switched to it from unstructured.io and it works great with the kinds of images and table graphics I feed it.
I have heard this claim before but I couldn’t follow the logic, genuinely would like to understand your perspective.
So “late untreated borreliosis” is a “real thing” but if someone gets borreliosis, gets treated, yet their symptoms persist (this scenario is what people usually mean by the term chronic Lyme) then that is NOT a “real thing”?
Does this mean that treatment is 100% effective or that if it didn’t work, then it wasn’t borreliosis to begin with?
Can you elaborate on the difference between the terms “late untreated borreliosis” and “chronic Lyme disease”? Borreliosis is just another name for Lyme disease. What distinction are you so sure about that I’m missing?
Reading this was very cathartic, I was nodding along and laughing as I had the exact same journey of WTF. And all along I just assumed I was 100% of the problem.
Hearing this perspective helps put my frustration in context. I need to lower my expectations and just get used to its quirks. Despite its issues I've had a ton of fun building with langchain and will keep using it.
There are many suggested treatments for inflammation, OP mentions “ginger”, my guess is that like everything else with the body certain treatments work for some people and not others. Like how CGM’s are used now not just for diabetes but for a tighter feedback loop on which foods, etc spike insulin, which allows a person to iterate their lifestyle faster. It’s the same with inflammation- If you have chronic inflammation and are trying to reduce it with diet, exercise, medication, naturopathic treatments, a tighter feedback loop would be a game changer, assuming it was possible. Perhaps CRP does not respond as quick to changes in the body as glucose, and measuring it all the time isn’t gaining much.
Reminds me of Forward Error Correction [1], a technique used by Satellite providers and even WAN optimization vendors like Silver Peak to "erase" packet loss events by injecting parity packets into the flow, which can be used to rebuild lost packets at the receiving end if needed. This prevents TCP synchronization, aka the throughput see-saw described in the article. This problem isn't limited to high latency / satellite links but exists on any path with packet loss, like your internet connection, or even MPLS.