FAQ

No. OpenRig works with your existing Claude or Codex subscription. Agents run as normal coding sessions in tmux. They use whatever authentication your coding agent already has. No separate API keys, no per-token billing, no usage dashboards to watch.

Claude Code and Codex CLI are fully supported today. OpenRig drives each one through a runtime adapter, and there is also a terminal adapter for infrastructure sessions like dev servers and log tails. The adapter contract is the same for every runtime, which is how OpenRig launches, monitors, snapshots, and restores sessions uniformly.

Yes, and it is one of the most powerful patterns. Different models catch different mistakes. A common setup is Claude for implementation and Codex for review, or running them as an adversarial pair where both review the same PR. See the Claude vs Codex and Model Diversity guides for patterns.

OpenRig is open source under the Apache 2.0 license. No cloud, no hosted service, no paid tier. It runs entirely on your machine. The open specification is CC-BY-4.0.

Each one names something distinct that matters in practice.

Claude Code is a harness: it wraps one agent. A rig is the topology of multiple harnesses working together. Inside a rig, you group agents into pods (they share context). Each agent is a node. The YAML file that defines a rig is a RigSpec; the file that defines an agent is an AgentSpec.

You can use OpenRig without any of those words. But once you're running 10+ agents and want to talk about "the group that shares memory" or "the shape of the whole thing" or "the file I can share with a teammate," generic terms like "multi-agent framework" don't carry enough meaning. These words do.

See What is a Rig? for the layer model that ties them together, or Taxonomy for the full list.

Terminal tabs give you parallel agents. OpenRig gives you a topology: agents with defined roles, grouped into pods with shared context, connected by communication edges, with lifecycle management.

The practical difference: reboot your machine with terminal tabs and you spend an hour reconstructing your setup. With OpenRig, run rig up my-rig and everything comes back: sessions, context, roles, the whole graph.

A context window is finite, so a long-running agent eventually has to compact: it summarizes its history to make room. The risk is that the summary loses something important, and the agent comes back a little dumber than it was.

OpenRig's answer is to not keep all the working knowledge in one place. Agents in the same pod write their state out to shared memory the whole pod can read. So when one agent compacts, a pod-mate still holds the thread and can hand the working context back. Think of it like a database replica: if one copy goes down, another still has the data. The difference is that what is being kept alive here is not uptime, it is the agent's understanding of the work.

Underneath that, OpenRig supports several ways to bring an agent back: resuming the underlying session, replaying its transcript, or restoring from a checkpoint. If a resume fails, OpenRig says so plainly rather than quietly starting a fresh agent and pretending nothing changed.

No. Start with one agent. Add a review pod when you need one. Research team later. OpenRig detects changes and keeps the graph current. If you already have tmux sessions running, rig discover fingerprints them and drafts a candidate RigSpec. See the Growing Organically guide.

A pod is a bounded context group within a rig. Agents in the same pod share memory, communicate freely, and maintain each other's context. Think of it like a Kubernetes pod but for knowledge, scoping what agents know about and talk about.

A typical rig might have a development pod (implementer + QA), an orchestration pod (lead + coordinator), and a review pod (security auditor + style reviewer).

macOS and Linux. OpenRig requires tmux (for agent sessions) and Node.js. The daemon runs locally, manages state in SQLite, and provides the HTTP API that the CLI, UI, and MCP tools all consume.

Just use tmux. Seriously.

Every coding agent already runs in a terminal. tmux gives you named sessions that survive disconnects, inspectable output via capture-pane, input injection via send-keys, and session persistence across reboots. That's identity, communication, observability, and durability, all for free, from a tool that ships with every Linux server and every Mac.

OpenRig doesn't require agents to integrate with it, install a plugin, or even know they're being managed. It manages agents that have no idea OpenRig exists. That's only possible because tmux gives you a universal control surface beneath every terminal agent.

We see people build elaborate agent orchestration frameworks, custom IPC layers, and bespoke communication protocols, then hit a wall when they try to manage more than three agents. The answer is almost always: just use tmux. OpenRig is what happens when you take that idea seriously and build an entire control plane on top of it.

Yes, this is a first-class use case. OpenRig ships with 17 MCP tools that let any MCP-capable agent manage topologies programmatically: boot rigs, check node status, create snapshots, restore sessions, send messages to agents, and capture terminal output. The CLI is also designed for agent use: structured output, clear error messages, no interactive prompts.

Those are orchestration frameworks: they define how agents talk to each other in code. OpenRig is a layer below: it manages the infrastructure that agents run on. It's closer to docker-compose than to a web framework.

You can run any harness framework inside OpenRig. The open specification (AgentSpec, RigSpec, RigBundle) is deliberately tool-independent. You define topology in YAML, and any compliant tool can boot it.

OpenRig is not a plugin. A plugin extends one tool: it adds a capability inside a single coding agent or harness, and it lives and dies with that one tool. OpenRig sits a layer above any single tool. It is the control plane that coordinates a whole topology of agent harnesses, the layer where you say which agents exist, how they are grouped, how they talk, and how they recover. A harness wraps a model. A rig wraps your harnesses.

One thing can cause confusion, so it is worth naming directly. OpenRig does have its own packaging mechanism called a plugin, managed with rig plugin: a way to bundle an extension so it can be discovered and used inside a rig. That is a component you can use within OpenRig. It is not what OpenRig itself is. OpenRig is the coordination layer; a plugin is one of the things you can package and run inside it.

Claude teams are a delegation primitive inside Claude: one Claude breaking work up and handing it to other Claudes.

OpenRig works a layer out. It runs the whole topology: booting agent sessions across runtimes like Claude Code and Codex, and letting you inspect and attach to any one.

Claude Managed Agents is a hosted runtime primitive: a way to run Claude agents in Anthropic's infrastructure.

OpenRig runs agent topologies on your own machine. You mix runtimes, group agents into pods, attach to any session directly, and recover the whole system after a restart.

It also picks up agents you already have running, sessions you launched yourself before OpenRig got involved, and shows the topology as a live graph you can click around.

A harness framework wraps a base model with focus persistence, memory, tool use, and lifecycle management, turning a model into a productive coding agent. Examples include Claude Code's built-in harness, Codex CLI, GSD, G-Stack, Super Powers, and any custom setup you build.

OpenRig doesn't compete with harness frameworks. It manages the topology they run in. Build your own harness framework, or use an existing one.

Yes. A RigBundle is a portable archive that bundles a RigSpec plus all vendored AgentSpecs. Anyone with OpenRig installed can import and boot it. Think of it like a Docker image for agent topologies.

That depends on your machine and your subscriptions. The developer of OpenRig runs 70+ agents at the current stable count. OpenRig itself imposes no hard limit; it manages whatever your hardware can support. Each agent is a tmux session, so the overhead per agent is minimal.

There are two ways to work, and they trade off against each other.

The disposable way: start an agent, give it a task, and throw it away when the task is done. The next task gets a brand-new agent. Most multi-agent tools assume this. It is simple, and it sidesteps the whole problem of managing a context window over time.

The long-lived way: keep the same agent running across tasks and sessions. Manage its context window so it stays sharp, and when it has to compact, carry its identity and working knowledge over to a fresh session. Same agent, same role, fresh window.

The long-lived way tends to produce better results, for a practical reason. An agent that has been working on your codebase for three days has a feel for it that a fresh agent does not. It knows why you named things a certain way, which patterns you prefer, and what you tried last week that did not work. That accumulated judgment is expensive to rebuild from scratch every morning.

Most people start fresh anyway, because keeping an agent alive and in context has been fragile and tedious without tooling. That is the gap OpenRig is built to close. Persistent identity across sessions, shared memory within a pod, and snapshot-and-restore so a whole topology comes back by name. These are what make the long-lived way practical instead of painful.

Both ways are valid. Disposable agents are fine for narrow, context-light tasks. But if your agents need deep knowledge of a project, or you want them to build up judgment over time, keeping them alive is the better choice. There is a hard part still being worked on: saving the facts an agent learned about a codebase is relatively easy, but saving the reasoning behind its judgment, the why behind what it believes, is much harder to automate. Until that is fully solved, simply keeping a good agent running is the more reliable path.

No, and there are no plans for one. OpenRig is a local tool by design. Your code, your agents, your machine. The daemon is a local HTTP server with a SQLite database. Nothing phones home.