Openrig: Build a 3-Agent Claude Code + Codex Network

Openrig is a build-it-yourself pattern for wiring three separate AI coding agents — Anthropic's Claude Code, OpenAI's Codex CLI, and a lightweight third node nicknamed Pi — into one coordinated network that hands work between them instead of leaning on a single tool. It matters right now because the single-agent era is quietly ending. Claude Code crossed 150,000 GitHub stars and Codex passed 129,000 this month, and plenty of us have hit the ceiling of what one agent, one vendor, and one context window can do on a real codebase.

There is no shipping product called "Openrig" with a landing page and a logo. It's a pattern. A named architecture for a cross-vendor rig, and the first piece of content anywhere that defines it. I'm writing it because the demand is obvious even if the term isn't indexed yet.

Key takeaways:

• Openrig is a cross-vendor orchestration pattern, not a product you install — you assemble it from Claude Code, Codex CLI, and a small coordinator node.
• "Pi" is the least-known piece: a lightweight, always-on router/state node, often run on a Raspberry Pi or cheap VPS with a small local model.
• The whole value is specialization plus an approval gate: one agent plans, another executes, and a human or policy sits in between.
• Running three agents means two billing relationships (Anthropic + OpenAI) and real token cost. It pays off past a certain project size, not for a weekend script.
• These steps reflect the Oct 2026 tool versions (Claude Code v2.1.300, Codex rust-v0.162.1) and will drift as both ship weekly.

One agent, one vendor, one context window is a single point of failure. A rig spreads the bet across models that fail differently.

What Is Openrig?

Openrig is a self-hosted pattern for building your own network of AI coding agents from tools that were never designed to talk to each other. The name is shorthand for an "open rig," an assembled setup, the same way audio or crypto people talk about a rig as a purpose-built stack of parts. In the Openrig build, those parts are three agent nodes with different strengths, connected by a shared workspace and a handoff protocol you control.

The problem it solves is concrete. Every coding agent today is a walled garden. Claude Code is excellent at reasoning over a large codebase and writing coherent multi-file changes, but it runs inside Anthropic's billing and its own context limits. Codex is fast, cheap to run locally, and great at tight edit-test loops, but it's a different vendor with different auth. Neither one knows the other exists. Openrig is the glue layer, plus the discipline, that lets them cooperate instead of competing for the same terminal.

Think of it as agent orchestration applied across vendors rather than within one framework. You're not picking the "best" agent. You're building a team where each member does what it's good at and passes the work along.

Why Build a Network of Agents Instead of Using One Tool

Because one model is one failure mode. When Claude Code gets stuck in a refactor loop, it tends to get stuck the same way every time. When Codex misreads a large repo's structure, it misreads it consistently. Put a second agent from a different lab in the loop and the blind spots stop overlapping.

I learned a version of this the boring way. I run a seven-agent pipeline that researches, writes, reviews, and publishes this blog — 261+ posts and counting — and the single biggest quality jump came from matching the model to the job shape. Sonnet handles the tool-loop agents. Opus handles prose. Using one model for everything was both more expensive and worse. The same logic drives Openrig: a planning agent and an execution agent want different things, and forcing one model to do both is how you get confident, wrong code.

There's also a market signal. OpenCode 2.0, a rival open-source agent runtime, reportedly hit #1 on Hacker News with 291 points the same week I'm writing this. The whole agentic AI ecosystem is sprinting toward multi-agent coordination. Based on the GSC data I track for this site, the "Claude Code + Codex multi-agent" query neighborhood already pulls roughly 30,000 searches a month across 505 related queries where this blog sits at #1. People want this. Nobody has named it.

The Three Nodes: Claude Code, Codex, and Pi Explained

Here's what each node brings, with the live numbers as of October 14, 2026:

The first two are easy. Claude Code was created February 22, 2025 and ships a Plugins system that extends it with "custom commands and agents," the subagent primitive any Claude node in a rig relies on. OpenAI's Codex CLI was created April 13, 2025, is Apache-2.0 licensed, and was rewritten in Rust for a lighter local footprint; the latest tag is rust-v0.162.1 from October 9.

Pi is the ambiguous one, and since no existing content defines it, I'll be blunt about my interpretation. In the Openrig pattern, Pi is the third node: a small, always-on orchestrator that routes tasks between the two heavy agents and holds shared state — the task queue, the current plan, the approval status. Many setups literally run it on a Raspberry Pi or a $5 VPS using a small local model, which is where the name comes from. It is not a code-writing genius. It's the dispatcher. If you already run a homelab AI coding server, that box is your Pi node. The point of making it cheap and local is that your coordinator should never be your most expensive component.

Prerequisites and Installation

You need three things working independently before you network anything. Trying to debug the rig before the nodes run alone is how people waste an afternoon.

1. Claude Code, installed and authenticated against an Anthropic subscription or API key. Confirm it runs and can edit a file in a throwaway repo.
2. Codex CLI, installed and signed in, either via a ChatGPT Plus/Pro/Business/Edu/Enterprise plan or a raw OpenAI API key. Codex also has IDE (VS Code, Cursor, Windsurf) and cloud ("Codex Web") variants, but the Openrig build uses the terminal CLI because that's the thing a coordinator can script.
3. A coordinator host for Pi: any always-on machine with a shell, a small model (local or API), and a shared folder the other two agents can read and write.

The real prerequisite friction is billing. You're standing up two separate commercial relationships: Anthropic for Claude Code, OpenAI for Codex. There is no unified bill, no shared quota, and the two meter tokens differently. Set hard spend caps on both before you let a loop run unattended. A rig that can call two paid APIs in a cycle is a rig that can run up two invoices at once. If you want to understand the math before you commit, I broke down LLM cost per task and break-even points separately. Read that first.

Architecture: How the Agents Hand Off Work to Each Other

The handoff is the whole game. Agents don't speak a shared protocol, so you invent one, and the simplest reliable one is a shared filesystem plus structured task files.

Pi owns a tasks/ directory. Each task is a plain markdown or JSON file with a state field: planned, approved, executing, done, failed. Claude Code, acting as the planner, reads a goal and writes a plan file. Pi marks it planned. Nothing executes yet. Only after an approval step flips the state to approved does Pi hand the file to Codex, which does the tight edit-and-test work and writes results back. Pi watches for completion and either closes the task or re-queues it.

This is message-passing through artifacts, not direct API calls, and that's deliberate. Every handoff leaves a file you can inspect after the fact. When I built order-cancellation microservices at Swiggy handling millions of deliveries, the lesson that stuck was that workflow systems need explicit compensation paths, not retries. A step that fails has to leave a clean, recoverable state, not just get hammered again. The same rule applies here. A failed task with a readable error file beats an agent silently looping.

Here's a visual walkthrough of building agents on top of Claude Code, which maps closely to the planner node in an Openrig setup:

That Krish Naik walkthrough covers the subagent mechanics on the Claude side; the Codex side follows the same shape through its own CLI.

Step-by-Step: Building Your Own Agent Network

1. Create the shared workspace. A single git repo the rig operates on, plus a tasks/ and logs/ directory Pi controls. Everything the agents say to each other lives here.
2. Wire Pi as the dispatcher. A small script on your coordinator host that polls tasks/, reads state fields, and shells out to the right agent. Keep it dumb. The coordinator should route, not reason.
3. Register Claude Code as the planner. Give it a system instruction to produce a plan file and stop, never to execute. Its job ends at planned.
4. Register Codex as the executor. It only ever picks up approved tasks, makes the change, runs the tests, and writes a result file.
5. Insert the approval gate between planned and approved. Manual for solo use, policy-based once you trust it.
6. Test with one trivial task end to end before you scale up. Watch the files change state. If the handoff works for a one-line fix, it'll work for a real feature.

For the agent-definition details on each tool, the terminal CLI tooling guide covers the install and config specifics that change too often to pin down here.

Example Workflows Where Three Agents Beat One

A 3-agent network earns its keep on tasks where specialization and parallelism matter:

• Large refactors with verification. Claude Code plans the refactor across 40 files; Codex executes file-by-file and runs the test suite after each; Pi tracks which files are done and re-queues failures. One agent doing all three loses track of state halfway through.
• Cross-vendor code review. Have Codex implement a feature, then route the diff to Claude Code for review. Two different models catch different bugs, the same reason I pair different tools in my own agentic AI workflows.
• Overnight backlog grinding. Pi feeds a queue of small, well-scoped tickets to whichever executor is cheaper that hour, with each result gated before merge.

The pattern holds up against the single-tool comparisons I've run. The 4.7x token-overhead gap between OpenCode and Claude Code I measured — part of the benchmark data I keep at /llm-benchmarks — is proof that which agent runs a task meaningfully changes the bill. A rig that routes by cost and strength is exploiting exactly that gap.

Safety and Permission Guardrails Between Agents

This is where most people will get burned, so I'll say it plainly: an agent's plan is not permission to execute it. If Claude Code writes a plan and Pi auto-hands it to Codex to run without a gate, you've built a machine that can delete your database because two agents agreed it was a good idea and nobody checked.

The guardrail is the approval step in the handoff, and it should be deterministic, not another LLM judgment call. Running my own pipeline taught me that a deterministic gate before any LLM review catches more than doubling the size of the review model. Cheap, fixed rules outperform expensive fuzzy ones at the point where mistakes get expensive. In Openrig terms: Pi should enforce hard rules (no rm, no force-push, no prod credentials, diff size under N lines) as code, and only escalate to a human for the gray areas.

Two more non-negotiables. Give each agent the narrowest filesystem and network scope it needs: the executor doesn't need your API keys, the planner doesn't need shell access. And log every handoff to the logs/ directory so a bad decision is traceable. These are the same principles that sit under the AI security work on this site, and they matter more, not less, when agents from two vendors are acting on the same repo.

Limitations, Costs, and What to Watch Out For

The honest downsides. First, cost: you're paying for two commercial agents plus whatever Pi spends. For a solo dev on a small project, a single tool like Aider or Claude Code is almost certainly the right call. The rig only starts paying off once you have more well-scoped tasks than one agent can grind through in a session, where parallelism and specialization outrun the coordination overhead.

Second, failure modes you don't see with one agent. Two models can ping-pong a change. Claude "fixes" what Codex wrote, Codex reverts it. Read the tasks/ state history: if a file bounces between executing and failed more than twice, Pi should halt it and flag a human, not retry forever. End-to-end evals matter more than unit-level prompt tests here, because the bug lives in the handoff, the same place your AI security exposure concentrates when two vendors' agents touch one repo.

Third, version drift. Claude Code shipped v2.1.300 and Codex shipped rust-v0.162.1 within the same week of October 2026, and both labs ship constantly. Codex itself was killed and resurrected once already. Any rig you build is pinned to today's CLIs. Expect flags, auth flows, and the Plugins surface to move under you.

Following Thorsten Ball's "How to Build an Agent" walkthrough and Simon Willison as he documents each Codex and Claude Code release is the fastest way to keep your build current. The pattern is stable. The parts are not.

The next twelve months belong to whoever makes cross-vendor handoff boring. Right now Openrig is duct tape and shared files, a pattern you assemble by hand. The moment one of these labs ships a real inter-agent protocol, the rig stops being a weekend project and becomes the default way serious teams ship code. Build one now, while it still teaches you something, so you're not learning the architecture the week everyone else does.

Photo by Glen Carrie on Unsplash.