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. Adapters for Pi and OpenHands are in active development. OpenRig manages any agent that runs in a terminal — launching, monitoring, snapshotting, and restoring sessions.

Yes — this 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.

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.

This is the core problem OpenRig solves. Agents in a pod externalize state to shared memory. When one agent compacts or needs to refresh, the others can restore it — the pod acts like a database replica for understanding, not uptime. OpenRig calls this mental-model HA.

Additionally, OpenRig supports multiple restore strategies: resume token, transcript replay, checkpoint restore, or fresh start with distilled context. Session 10 doesn't read 1.5M tokens — it gets distilled wisdom in 40k.

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 — 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.

Anthropic launched Claude Managed Agents as a cloud-hosted runtime for deploying Claude-only agents at $0.08 per session-hour. It's a serious product — and it validates that multi-agent infrastructure is a first-class problem worth solving.

OpenRig is the open source, local-first answer. It runs on your machine, works with Claude Code and Codex in the same topology, with adapters for Pi and OpenHands in development, and costs nothing. You can attach to any agent session and talk to it directly. You own your data, your agents, your topology.

There are also capabilities OpenRig ships that Managed Agents doesn't have: discovering and adopting existing sessions you didn't launch, pods with shared memory and continuity policies, portable topology artifacts (RigSpec, RigBundle), a visual topology graph, a spec library, and 36 CLI commands designed for both humans and agents. Managed Agents supports one level of agent delegation — OpenRig supports any topology shape at any depth.

Think of it like Terraform and AWS. Terraform doesn't compete with AWS — it manages resources across clouds. OpenRig manages topologies across runtimes. Managed Agents could eventually become one of those runtimes via an adapter. Full comparison.

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 Agent Focus (ships with OpenRig as the default), 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 author runs 10+ agents across 4 pods daily. 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.

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.