openrig

Open source alternative to Conductor

8.1K stars
Apache-2.0
Active this week
Last commit today

Last verified Oct 22, 2026

Orchestrate Claude Code and Codex agents as a persistent coding team, with YAML topologies, lead-agent delegation, and cross-agent messaging.

Visit website GitHub8.1K

Read the full breakdownWho it is for, how it works, trade-offs, the quick start and the FAQ

who it's for

Who openrig is for#

Developers running multi-week projects with specialized agents

OpenRig fits developers who need several agents working on distinct parts of a codebase over time: a UI owner, a backend maintainer, a QA reviewer. Each specialist retains context and decision history across sessions, so a `dev-app@factory` agent that built a shared client last month still has that decision when asked about it today.

Skip if:

Single-session tasks or one-shot code changes. If your project fits in a single agent context window and completes in one run, the YAML setup and daemon overhead add more friction than they remove.

Teams exploring cross-runtime agent coordination

OpenRig is the only open source tool that treats Claude Code and Codex as peer specialists in the same topology. Teams curious about combining both runtimes can start with the `first-project` starter (two Codex seats) or `conveyor` (four seats mixing both) before writing custom RigSpecs. The TUI shows what both runtime types are doing in one view.

Skip if:

All agents use the same runtime. If your team runs only Claude Code or only Codex, simpler multi-agent approaches without cross-runtime coordination overhead are available.

Developers building agent-managed infrastructure rigs

The `secrets-manager` starter ships a HashiCorp Vault instance operated by a specialist agent that boots Vault, monitors health, and responds to queries. This pattern, software packaged alongside the agents that manage it, suits developers who want to give an agent permanent ownership over a service rather than a task.

Skip if:

Teams that need multi-user access or a network-accessible management API. OpenRig runs locally as a single-user daemon; the TUI and CLI are not multi-tenant.

the problem

The problem it solves#

Running multiple AI coding agents on a real project breaks down quickly. You open Claude Code for the backend, Codex for the frontend, and another for review, but each session starts cold with no memory of the others and no shared work queue. When the project spans weeks, you spend as much time re-briefing agents as reviewing their output.

The underlying challenge is that individual tools manage one conversation at a time. Assigning a task to a named specialist with durable persistence requires either careful manual setup or a dedicated orchestration layer. Inter-agent messaging means copy-pasting context between terminals. Topology state does not survive a reboot. The coordination overhead scales with the number of agents, making long-horizon projects impractical without a tool built for this.

how openrig solves it

How it solves it#

Declarative YAML topology definition

Define agent teams as RigSpec files: pods (groups of seats), named addresses like `dev-owner@first-project`, edges between seats, and continuity policies. Boot the entire topology with `rig up <name>`. Predefined starters include `first-project` (two seats for a focused first run), `product-team` (orchestrators, implementation, QA, design, and two reviewers), and `conveyor` (four seats mixing Claude Code and Codex in an intake-to-review handoff).

Lead-agent delegation with tracked work queues

A lead agent takes your brief and assigns bounded tasks to named specialists via `rig queue`. Each task keeps its seat owner and progress visible for later follow-up. Agents can message teammates directly with `rig send` for quick questions without creating a tracked assignment. Work assigned to a seat survives the conversation that created it and remains visible in `rig queue list`.

Persistent seats with stable addresses and retained context

Each seat in a rig holds a stable address (e.g., `dev-app@factory`) with retained authored context and decision history. The conversation occupying a seat can change while its identity and queue ownership stay in place. `rig down --snapshot` captures full topology state to disk; `rig up <name>` restores from the latest snapshot and reports per-node outcomes: resumed, fresh, or failed.

Terminal UI with topology graph and seat detail

The TUI shows rig topology as a graph and a table of seats with runtime, model, context usage, and current state. Navigate with keyboard, mouse, or the command bar. Views include Projects, Specs, Feed, Terminals, and System. With herdr or cmux installed, all agent terminals open alongside the dashboard in one integrated workspace.

MCP server for agent-managed topology

Agents manage their own team through the built-in MCP server. Tools include `rig_up`, `rig_ps`, `rig_send`, and `rig_chatroom_send`, letting a lead agent launch new seats, inspect team state, and broadcast across the group without human intervention. This enables automated coordination loops: a lead can spin up a temporary subagent, assign it work, wait for results, and fold them back into the main task.

strengths · trade-offs

Strengths and trade-offs#

Strengths

Apache 2.0 license with full self-hostingOpenRig is Apache 2.0 licensed. Run it on your own machine or server with no per-execution fees and no data leaving your infrastructure. Unlike Conductor's managed SaaS offering, you own the topology definitions, agent state, and execution environment. Commercial use is unrestricted under Apache 2.0.
Coordinates Claude Code and Codex as peer specialists in the same teamMost multi-agent setups stay within a single execution environment. OpenRig connects Claude Code and Codex as peers in the same topology, letting each handle what it does best. The lead agent delegates across both runtimes, so teams can put Claude Code on contextual reasoning and long sessions while Codex handles targeted implementation tasks.
Local-first state with no cloud dependencyThe daemon stores topology state, context usage, and provider telemetry in SQLite under `~/.openrig`. No cloud account is required for the core tool. Snapshots and restores work entirely on disk. The only external calls are to the AI providers your agents already authenticate with, so data stays on your infrastructure.
Active project with documented versioningThe repository has 980 GitHub stars and 104 forks, with the last commit pushed on 2026-09-27. Issues receive acknowledgment within one day per the contributing guide. Releases include structured migration guides, such as the v0.5.9 layout boundary migration with its own scripted verifier, signaling a project that handles upgrades as a first-class concern.

Trade-offs

-Requires Node.js 20+, tmux, and authenticated AI sessionsRunning OpenRig requires Node.js 20, 22, or 24, tmux, and authenticated Claude Code and/or Codex sessions. Setup writes hooks and trust settings to `~/.claude.json`, `~/.codex/config.toml`, and workspace files. The README explicitly recommends backing up those files before first use. On a machine with existing Claude Code or Codex configuration, reviewing the 'What OpenRig changes on your machine' table before setup is essential.
-Automatic system-level writes at daemon startupDaemon startup writes Claude Code workspace trust, Codex hook configuration, and trust hashes for relay commands, and sets `permissions.defaultMode` to `acceptEdits` in Claude's settings. These changes happen on every daemon startup, not just during initial setup. Users on shared machines or with custom AI configurations should review the full change table in the README before first use.
-React web UI is in maintenance modeThe older React web UI is in maintenance mode with best-effort support only. Active development focuses on the TUI, CLI, and MCP server. Teams expecting a browser-based management interface will need to work with the terminal UI instead; the TUI does not have a web equivalent that receives new features.

versus alternatives

openrig vs alternatives#

OpenRig vs Conductor

OpenRig and Conductor both coordinate automated workflows, but they operate at different abstraction levels. Conductor (offered commercially as Orkes) is a general-purpose workflow engine: you define tasks as a directed graph, workers execute each node, and the engine tracks state across steps. OpenRig is specifically designed for coding-agent teams: it manages Claude Code and Codex sessions as persistent specialists with retained context, stable seat addresses, and work queues that survive reboots.

Feature	OpenRig	Conductor
License	Apache 2.0	Apache 2.0 (OSS) / Proprietary (Orkes SaaS)
Self-hosting	Yes (local daemon, SQLite)	Yes (OSS) or managed (Orkes cloud)
Agent types	Claude Code, Codex, Pi	Any worker via SDK
Topology definition	YAML RigSpec	JSON workflow DSL or code SDK
Persistent seat identity	Yes	No (stateless workers)
Cross-agent messaging	rig send, rig queue	Not native; requires workflow steps
Management UI	Terminal UI (TUI)	Web dashboard (Orkes)

OpenRig is the better choice for teams building coding-agent workflows where persistent context matters. A dev-app@factory seat that made an architectural decision last month retains that decision the next time it is asked about it; Conductor workers are stateless by design and hold no memory between executions.

Conductor is the better fit when you need a general-purpose workflow engine where any worker language or service participates. If your orchestration spans non-coding agents, microservices, external APIs, and human approval gates in a broader system, Conductor's worker model and retry infrastructure cover ground OpenRig does not target. The Orkes SaaS tier adds monitoring, access control, and enterprise support that a self-hosted OpenRig instance would need to build separately.

install · quick start

Quick start#

bash

Install OpenRig globally via npm (requires Node.js 20+ and tmux), then preview and apply setup before launching your first rig.
```bash
npm install -g @openrig/cli
rig setup --dry-run
rig setup
rig up first-project --cwd .
rig tui --shared
```

tech stack · detected from GitHub

What it's built on#

Languages: JavaScriptTypeScript

frequently asked

FAQ#

Does OpenRig support both Claude Code and Codex in the same team?

Yes. OpenRig defines seat types for Claude Code, Codex, terminal nodes, and a Pi adapter. A single rig topology can mix all of them in different pods. The conveyor starter demonstrates a four-seat mixed Claude Code and Codex topology. Each runtime keeps its own authentication; OpenRig manages them as one coordinated team.

Is OpenRig free to use?

Yes. OpenRig is Apache 2.0 licensed and fully self-hosted. There are no execution fees or usage limits beyond what your underlying AI providers charge for their API calls. The npm package and all starter rigs are included at no cost.

What happens to agent work after a machine reboot?

rig down --snapshot captures the full topology state to disk. rig up <name> restores from the latest snapshot and reports per-seat outcomes: resumed, fresh, or failed. Agent context and queue assignments are stored in the local SQLite database under ~/.openrig and survive restarts.

How is OpenRig different from running multiple Claude Code sessions manually?

Manual sessions share no addressing, messaging, or work queue. With OpenRig, each seat has a stable address, agents can message each other with rig send, task ownership is tracked in rig queue, and the TUI shows all seats in one view. Agent context and queue state persist across reboots; manual sessions start fresh every time.

What are the prerequisites before running rig setup?

You need Node.js 20, 22, or 24, tmux, and authenticated Claude Code and/or Codex sessions. Review the 'What OpenRig changes on your machine' section in the README before running rig setup, since the command writes trust settings and provider hooks to your home directory. rig setup --dry-run previews what will change without applying it.

also worth a look

Similar open-source tools#

paperclip

Featured

Alternative toGrok Bot

Self-hosted AI agent management with org charts and budgets

105,118 GitHub stars
Licence MIT

Threadlines

Alternative toConductor

Open-source ADE for Claude Code, Codex, and Cursor in one thread

20 GitHub stars
Licence MIT

Orgtree

Alternative toConductor

Desktop canvas for persistent multi-agent AI teams, Windows-only

168 GitHub stars
Licence MIT

Herdr

Alternative toConductor

Agent runtime that keeps terminals alive across machines

44,852 GitHub stars
Licence Apache-2.0

5dive

Alternative toConductor

Run a company of AI agents on a server you own.

73 GitHub stars
Licence MIT

Hypa

Alternative toConductor

Local-first terminal workspace for AI coding agents

212 GitHub stars
Licence FSL-1.1-ALv2

by category

Open source tools in these categories#

404

12,712 GitHub stars
Licence AGPL-3.0
#Email

rakazo

Alternative toGrok Bot

AI teammates you own: your keys, your model, your machine.

4,904 GitHub stars
Licence Apache-2.0
#AI Agents

Omnara

Alternative toClaude Managed Agents

Open-source agent deployment API. Self-host or use Omnara Cloud.

2,957 GitHub stars
Licence Apache-2.0
#AI Agents

Feature your project

The projects we add and every new guide. Free, unsubscribe any time.

Find open source alternatives to paid software

OpenRig vs Conductor

Feature	OpenRig	Conductor
License	Apache 2.0	Apache 2.0 (OSS) / Proprietary (Orkes SaaS)
Self-hosting	Yes (local daemon, SQLite)	Yes (OSS) or managed (Orkes cloud)
Agent types	Claude Code, Codex, Pi	Any worker via SDK
Topology definition	YAML RigSpec	JSON workflow DSL or code SDK
Persistent seat identity	Yes	No (stateless workers)
Cross-agent messaging	rig send, rig queue	Not native; requires workflow steps
Management UI	Terminal UI (TUI)	Web dashboard (Orkes)

Who openrig is for#

Developers running multi-week projects with specialized agents

Skip if:

Teams exploring cross-runtime agent coordination

Skip if:

Developers building agent-managed infrastructure rigs

Skip if:

The problem it solves#

How it solves it#

Declarative YAML topology definition

Lead-agent delegation with tracked work queues

Persistent seats with stable addresses and retained context

Terminal UI with topology graph and seat detail

MCP server for agent-managed topology

Strengths and trade-offs#

Strengths

Trade-offs

openrig vs alternatives#

OpenRig vs Conductor

Quick start#

What it's built on#

FAQ#

Similar open-source tools#

Open source tools in these categories#

AI & Machine Learning

Developer Tools

Product & Project Management

Find open source alternatives to paid software

Who openrig is for#

Developers running multi-week projects with specialized agents

Skip if:

Teams exploring cross-runtime agent coordination

Skip if:

Developers building agent-managed infrastructure rigs

Skip if:

The problem it solves#

How it solves it#

Declarative YAML topology definition

Lead-agent delegation with tracked work queues

Persistent seats with stable addresses and retained context

Terminal UI with topology graph and seat detail

MCP server for agent-managed topology

Strengths and trade-offs#

Strengths

Trade-offs

openrig vs alternatives#

OpenRig vs Conductor

Quick start#

What it's built on#

FAQ#

Similar open-source tools#

Open source tools in these categories#

AI & Machine Learning

Developer Tools

Product & Project Management

Find open source alternatives to paid software