Give your main agent a roadmap, ideas and feedback. It coordinates the work and brings back results and decisions. You don’t have to personally supervise every terminal or even talk to every team.
Get started → See a team in action →
Start with five agents. Scale to fifty or a hundred as the work grows, with teams that manage other teams. Agents keep working overnight or while you’re away, and reach out when they need a decision.
Your agent organization is programmable.
OpenRig gives coding agents tools to run the organization building your software. Define roles and team structure in files. OpenRig starts the agents in separate Claude Code and Codex sessions with stable addresses. The agents can inspect that structure, find the right specialist and route tracked work themselves.
Leave specialists running to accumulate context and expertise in their part of the project. They talk directly across harnesses, and each can use its own sub-agents. Shared project workspaces give their decisions and knowledge somewhere durable to live.
Your main agent can delegate through team leads and consult specialists without holding the entire project in one context window. Shared plans and workflows turn that structure into coordinated work that can run for weeks or months.
Open source and built by its own network of agent teams since March 2026.
Keep reading: how the organization works
From one conversation to many teams
Imagine working with a product agent on the next release. You agree on the outcome; it breaks the roadmap into work for a build team and a research team. The build lead coordinates several development pods, each with its own implementation and review work. Specialists resolve questions directly. Your product agent brings back progress and the decisions that need you.
You can talk to any of those agents, but you don’t have to carry messages between them. The organization has an explicit shape: a rig is a team, a pod groups related work, and a seat gives a specialist a durable role and address. Teams can coordinate with other teams. That structure is the topology, and the agents can inspect it too.
This is how the coordination work scales beyond your own attention. A lead needs to know where expertise lives and who owns the work; it doesn’t need every specialist’s knowledge loaded into its own context. Tasks retain their owners in the queue, while project workspaces preserve the reasoning and plans the team needs to keep going.
How OpenRig works
OpenRig is a program that runs on your machine and turns AI coding agents from a pile of individual terminal sessions into a persistent, organized team.
Mechanically, it's a small local daemon with a SQLite database, a CLI called rig, and a terminal UI. The agents themselves are ordinary Claude Code and Codex sessions running in tmux, the same thing you get when you open a terminal yourself. OpenRig is the management layer on top: it boots them, names them, connects them, watches them, and keeps the truth about all of it in one database. It is not a cloud service and not an agent framework. It doesn't replace Claude Code or Codex; it launches and coordinates them. It doesn't need API keys of its own; it drives the Claude Code and Codex logins you already have. It's self-hosted coordination for your existing coding agents: the control plane runs on your machine, the agents talk to their configured providers, and integrations can connect to outside services when you turn them on.
What about sub-agents and agent teams?
If you're good with Claude Code, you already do multi-agent: skills, sub-agents, workflows, maybe agent teams. Keep all of it. OpenRig assumes you will max out your harness and leans on those features constantly. But everything the harness gives you lives inside one session. The sub-agents work for the one agent you're talking to; when the job is done they're retired, and when you close the terminal, the whole team goes with it.
A rig is the team that doesn't go away: separate Claude Code and Codex sessions, each with a name and a role, talking to each other directly, still working after you have closed every window, because tmux keeps the sessions alive while the machine is on, and brought back by name after a reboot, with each seat's outcome reported rather than assumed: restoration can resume or rebuild a seat, start it fresh, require a decision or attention, or fail. It's the thing the product is named for and the thing the rig command boots.
The word for one of those named positions is a seat. A session is what occupies a seat for a while. Sessions end; the seat keeps its name, its role and what it has learned, and the next session sits down in it. A sub-agent is a function call; a seat in a rig is a colleague. A rig's shape, who is in it and who hands work to whom, is its topology: durable like a network, so you can swap a seat's occupant and everybody else keeps working. If you have ever had forty tabs of agents you were afraid to close, imagine if they had actually been working together.
What it looks like
You run one command, rig up first-project, and a real team boots. The big starter, rig up product-team, brings up seven seats in named tmux sessions: Two orchestrators that back each other up, an implementer, a QA seat, a designer, and two independent reviewers, a mix of Claude and Codex so different models catch different mistakes. Smaller starters ship too, down to a two-seat first-project.
From there you live on two screens. The terminal UI, rig tui, shows the shape: which rigs exist, the pods and seats in each, what is running, and the projects, missions and slices the team is working through. The terminals are just terminals: every seat is a live tmux session you can watch or type into directly. If you run Herdr or cmux, a tiling terminal, rig terminal open brings the seats up as tiles on one screen. You can check on any seat this way, though mostly you talk to one, the orchestrator, and the team works. To the coordination layer you're just another member, one whose inbox happens to be a feed built for human attention.
What you're actually doing
If you have ever managed people, you already know the real job here. A manager's head is full of context bookkeeping: who knows this codebase, who lived through that outage, whose judgment to trust where, who needs what briefing before taking a task. Running agents is the same job, except your team members are context windows with tools wrapped around them: workers that build up knowledge, form opinions, talk back in English, and happen to be the best command-line users you have ever seen. With one or two, you hold the bookkeeping in your head. Past that, you become the bottleneck, deciding who gets which task, remembering who knows what, relaying messages between tabs. OpenRig exists so the agents do that bookkeeping themselves, and your job shrinks to the part that actually needs a human: deciding what is worth building, and stepping in when something drifts.
The primitives
A handful of pieces carry all of it, each learned the hard way.
Agents talk through their terminals. rig send types a message into another seat's session, with a from-line so it can reply; rig capture reads any seat's screen; rig transcript searches what a seat has said, across every session that has occupied it, from the terminal output OpenRig captures; the capture is a record of what was said, not a guarantee that nothing was missed. No separate channel between agents and no API to integrate with. The terminal is the wire.
Work keeps its owner. Work moves through rig queue. Each piece of work is a tracked item with one owner and a state you can ask about. A seat can't close work without saying where it went, and handing work to another seat closes yours and opens theirs in one step, so nothing strands between seats. Durable does not mean automatic; a task can still need someone to notice it. What the queue removes is the silent loss.
Workflows end the babysitting. Without one, you know the drill even if you have never named it: the planner finishes a plan and tells you it's ready, you go tell the reviewer, later you remind the builder what comes next. You're the team's nervous system, and it's exhausting. A workflow is a declared spec the daemon runs step by step instead: when the plan step completes, the review item appears in the reviewer's queue on its own, and work keeps moving through whatever shape you declared, without you carrying it. Agents can author these too. The result is strange the first time: you stop thinking about whether the team is coordinating, because it just is.
State lives on disk. Agents do their best work when their working state lives outside their heads, because a context window can degrade without warning. The workspace is a standard filesystem layout for the work itself: projects broken into missions, missions into slices, the durable record of what exists, why, and where it stands, organized so a brand-new agent can land cold and find its footing without a briefing. It also settles a question most people never have: where all this should live and what structure it takes. There's one answer, it ships with the product, and every agent already knows its shape.
The team survives. Stopping a running rig attempts a snapshot before teardown; a failure is reported and doesn't stop the teardown. rig up product-team brings it back by name and reports each seat honestly: resumed or rebuilt where it could be, started fresh, waiting on a decision or attention, or failed. No hunting through a resume picker trying to recognize an agent by the first thing you ever typed to it, no remembering which directory each one started in: the team comes back as a team. An agent that fills its context window is a handled event, not a quiet loss.
Where this goes
The first week, the win is mundane: you stop being the router between three or four agents. Then trust starts to accumulate. The team proves it ships good work, and you stop tracking agents and start tracking the team. Eventually your ambition flips: the question stops being "how do I keep four agents productive" and becomes "how many rigs can I run": a coding rig, a research rig, a PM rig, a lifecycle rig. Many rigs on one machine, or across machines, is a fleet. You start thinking in rigs where you used to think in agents.
None of this is a concept page. OpenRig is developed daily by a standing fleet of agents running on OpenRig, on ordinary consumer subscriptions. Could it run hands-off? It has been demonstrated. In practice it's operated like a self-driving car with a hand near the wheel, because that gets better results. The constraint that matters day to day is not the agents; it's how fast one person can review what they shipped.
Coordinating agent teams since March 2026.
Since March 2026, OpenRig has let you talk to one agent and have it coordinate a durable team of Claude Code and Codex agents communicating directly and working together on long-running projects.
Since then, we’ve focused on helping those teams handle larger, more complex work with less supervision: shared project workspaces, planning, workflow orchestration, and organizing and retrieving large libraries of project context. The goal is to keep work moving over weeks and months while you provide direction, ideas and feedback.
Try it
npm install -g @openrig/cli
rig setup
rig up first-project
rig tui
Install the CLI, run setup once, boot the smallest starter, open the terminal UI. You need Node 20 or newer, tmux, and a Codex login for first-project; rig setup --dry-run shows what setup will change before you let it. first-project is one pod with two seats; product-team is the full seven-seat starter, and the library in between is one rig specs ls away. If you have never run enough agents to feel the group problem, you might not need this yet. If you have: it's open source, it's local, and you're four commands away.