OpenRig explained: coordinate coding agents without losing the operator
OpenRig explained: coordinate coding agents without losing the operator
Understand rigs, seats and the local daemon before adding a second agent
What you will learn
- The useful unit is a seat
- Follow the control path
- Understand the first side effect
Before you start
- Node 22 or 24 and tmux on a supported host
- One working provider account and a disposable repository
Turn the first owner/checker run into evidence for a safe rollout decision
Key takeaways
- A seat is a stable role, not a proof of correctness.
- The TUI observes coordination; tmux hosts the sessions.
- Managed startup can change trust and hooks.
The useful unit is a seat
OpenRig reads a RigSpec and starts a team of persistent roles. A seat such as `dev-owner@first-project` has a stable address, while the agent session occupying it can change. Pods group seats and edges describe their working relationships.
That model is useful when an owner and a checker must discuss the same candidate. It does not make their answers correct. The operator still defines a bounded task, inspects the result and decides whether any code should land.
Follow the control path
The documented stack is CLI, TUI or MCP into a local Hono daemon, then domain services, SQLite, tmux and provider adapters. Claude Code and Codex can occupy the same rig when the corresponding local accounts work.
The shared TUI shows coordination state; tmux holds the actual terminals. Closing a viewer does not stop the seats. This distinction matters when a team appears to have vanished after a terminal window closes.
Understand the first side effect
Installing the npm package adds the CLI, but daemon startup and managed seats may change provider hooks, trust records and workspace files. The README separates those moments and warns that `OPENRIG_HOME` does not isolate provider configuration.
Read the change table before trying a starter rig. A safe evaluation uses a disposable repository, a selected provider and a record of configuration files before and after launch. This series did not install or execute OpenRig.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Name the owner and checker roles for one task.
- 2
Inspect the daemon, seat and terminal boundaries.
- 3
Record provider and workspace files before first launch.
Copy-ready example
RigSpec -> seats and edges
CLI / TUI / MCP -> daemon -> SQLite + tmux
operator -> inspect exact candidateFrequently asked questions
Do I need two model subscriptions?
No. The guide says to use an account that already works, with one provider or both.
Does closing the TUI stop a rig?
No. The underlying tmux sessions continue until explicitly stopped.
Sources
- OpenRig / README.mdSource checked 2026-10-04
- OpenRig / docs/reference/getting-started.mdSource checked 2026-10-04
- OpenRig / docs/reference/rig-spec.mdSource checked 2026-10-04
- OpenRig / docs/reference/instance-layout.mdSource checked 2026-10-04