OpenRig vs Claude agent teams

Why I publish comparisons. This category is new. The vocabulary isn't settled. Nobody has a complete mental model of what's in the space, including me. The comparisons here are an attempt to find the shape of the category — what approaches are being taken, what each approach looks like, what we might learn from each other. Not a bake-off.

Claude agent teams started from: what if a Claude Code session could spin up more Claude Code sessions as teammates, with their own contexts and direct messaging, managed from within the same UX? The answer is an in-harness feature. You enable the flag, create teammates with TeamCreate, and Claude Code gives you multi-Claude coordination from inside a single operator surface. The team lives inside Claude Code, scoped to Claude Code, and feels like a natural extension of it.

OpenRig started from a different question: what if you could arrange any mix of shipped coding agents — Claude Code, Codex, terminal processes — into a topology you define outside of any single vendor's product, run it as local infrastructure, and have the whole thing survive reboots? The answer is a topology-first control plane. OpenRig doesn't live inside Claude Code — it manages Claude Code (and Codex, and terminals) from outside, the way Docker Compose manages containers.

Both answers are valid. They optimize for different things. Agent teams optimizes for smooth multi-Claude work inside the Anthropic-blessed UX. OpenRig optimizes for durable, cross-runtime, operator-driven topologies.

Because these are close peers, the more useful question is when each one fits.

Claude agent teams is well suited to: day-to-day multi-Claude work you do entirely inside Claude Code. You're already living in the Claude TUI, you want to spin up a few parallel Claudes for a specific task, message them from a lead session, and tear the team down when you're done. All of that is natural in Claude Code with the feature flag on, and you don't have to leave the product.

OpenRig is well suited to: arrangements you want to keep. You're running a coding setup that mixes Claude Code with Codex and maybe a terminal or two. You want to boot it with one command, save it before you shut down, and bring it back next week with a rig up. You might have arranged your agents organically in tmux and you want to adopt what's already running into a managed topology without rebuilding. You're operating the system as infrastructure rather than working inside a single harness.

Because they live at different layers — one inside Claude Code, one outside all harnesses — they can also coexist. A node in an OpenRig rig is a real Claude Code session; nothing stops that session from using agent teams internally if the feature helps. The layers compose.

The overlap is real, so it's worth being clear about where OpenRig does something agent teams doesn't:

• Cross-runtime. Claude Code and Codex in the same rig, coordinating with each other. Agent teams is Claude-only by design.
• Persistence by name. rig down snapshots the topology; rig up <name> brings it back. Per-node outcomes reported honestly (resumed, rebuilt, fresh, or failed). Agent teams doesn't document this kind of whole-topology restore.
• Adopt what's already running. rig discover finds Claude Code and Codex sessions you launched manually in tmux; rig adopt binds them into a rig. You don't have to start from scratch.
• Services inside a rig. A rig can ship actual software alongside a specialist agent whose job is to run it. The shipped example is HashiCorp Vault with a vault-specialist agent — one command and you have a secrets manager as part of the rig.
• Operator surface outside the harness. A dedicated CLI, a topology graph, a node detail panel, a system log. All the operator work happens in tools designed for it, not inside the harness being coordinated.

None of this is a criticism of agent teams. Agent teams is doing something specific — multi-Claude work inside Claude Code — and doing it well. OpenRig is doing something adjacent: running a cross-runtime topology as local infrastructure. If you need both, you can have both.