Agent-Manager: Orchestrating Claude Code, Codex, and OpenCode from a Tmux TUI

What Happened: The Tmux TUI That Puts Agents in Panes

A developer shipping under the handle YoanWai dropped a tool that feels like a natural endpoint for the current coding-agent explosion. Agent-Manager is a Tmux-based terminal UI that spawns three independent coding agents—Claude Code, OpenAI Codex, and OpenCode—in adjacent panes, letting you fire prompts at all of them simultaneously and watch the results stream in side-by-side.

The repo is dead simple. A single Bash script (agent-manager.sh) handles the Tmux session creation, pane splitting, and command routing. You type a prompt once, it lands in all three agent sessions at roughly the same time. Each agent operates in its own shell, with its own context, its own file system view, and its own quirks. There's no shared memory between them, no agent-to-agent communication, no voting mechanism. It's three isolated coding assistants running in parallel, and you're the human orchestrator watching the race.

This isn't a framework. It's 200 lines of Bash that exploit Tmux's send-keys to push text into panes. The "manager" part is you—the engineer staring at three streams of generated code, diffs, and reasoning traces, deciding which output to keep, combine, or throw away.

The project surfaced at a moment when the market is drowning in coding agents. GitHub Copilot's agent mode, Cursor's composer, Aider, Cline, Windsurf—everyone is shipping autonomous coding capabilities. Agent-Manager takes the opposite approach. Instead of picking one agent and trusting it, you run three and compare. It's an A/B testing rig for AI-generated code, wrapped in the most unix-pilled interface possible: Tmux.

Why This Matters for Forward Deployed Engineers

If you're an FDE—someone who parachutes into customer environments, debugs production issues, and ships working prototypes under absurd time pressure—this tool scratches a very specific itch.

The Multi-Model Reality

No single model wins every task. Claude 3.5 Sonnet writes cleaner Python but hallucinates API endpoints. GPT-4o understands legacy Java better but over-engineers simple functions. OpenCode (powered by open-weight models) is weaker on complex reasoning but costs nothing and runs locally. An FDE debugging a customer's broken authentication flow at 11 PM doesn't have time to run three sequential experiments. Agent-Manager collapses that into one prompt and one screen.

Context Is the Bottleneck

FDE work is context-heavy. You're reading a customer's Terraform, their bespoke auth middleware, their undocumented database schema. Feeding all of that into a single agent's context window is slow and risks hitting limits. With three agents running in parallel, you can be strategic: give Claude the infrastructure code, give Codex the application logic, give OpenCode the database queries. Each pane operates with a focused subset of the problem. You integrate the outputs manually, which is exactly what an FDE does anyway.

The pattern mirrors what we covered in our piece on building a codebase Q&A bot that indexes your repo—the insight that splitting context intelligently across models often beats cramming everything into one giant prompt.

The Demo-to-Production Gap

FDEs frequently build quick prototypes that later need to become production features. Running three agents on the same spec gives you three architectural approaches instantly. One might produce a clean FastAPI service, another a serverless function, the third a janky but working shell script. You pick the bones of the best approach and stitch them together. That's faster than iterating with a single agent through five rounds of "no, do it differently."

Architecture: How the Panes Talk (and Don't Talk)

Agent-Manager's architecture is aggressively simple. No message broker, no shared state, no agent protocol. Just Tmux and Bash.

The script does exactly four things:

1. Creates a named Tmux session (agent-manager) so you can detach and reattach without killing the agents.
2. Splits the window into three panes—one horizontal split, then a vertical split on the bottom half. You get a top pane (Claude Code by default) and two side-by-side bottom panes (Codex and OpenCode).
3. Launches each agent's CLI in its respective pane. For Claude Code, that's claude in interactive mode. For Codex, it's codex pointed at your OpenAI API key. For OpenCode, it's opencode with whatever model backend you've configured.
4. Routes your prompts using tmux send-keys to push the same text into all three panes simultaneously.

There's no API layer. The script literally types into each pane's shell as if you were doing it manually. This means each agent sees the prompt as standard input and responds in its own terminal UI. You watch three TUI applications running side-by-side, each rendering its own streaming output, syntax highlighting, and diff views.

The absence of inter-agent communication is a feature, not a bug. These agents have different context windows, different tool-calling conventions, and different safety guardrails. Trying to make them "collaborate" would introduce a protocol problem that's harder than the coding problem you're trying to solve. Instead, you're the protocol. You read three outputs, you decide what works.

Getting Started: Pull, Configure, and Run

You need three things installed and authenticated before Agent-Manager does anything useful:

Prerequisites:

• Tmux (3.0+ recommended, but anything modern works)
• Claude Code CLI (npm install -g @anthropic-ai/claude-code)
• OpenAI Codex CLI (available through OpenAI's platform, requires an API key)
• OpenCode CLI (open-source, model-agnostic—point it at Ollama, Groq, or any OpenAI-compatible endpoint)

Installation:

git clone https://github.com/YoanWai/agent-manager.git
cd agent-manager
chmod +x agent-manager.sh

Configuration:

The script reads from environment variables or a .env file in the repo root. Minimum viable config:

# .env
export ANTHROPIC_API_KEY="sk-ant-..."
export OPENAI_API_KEY="sk-..."
export OPENCODE_MODEL="claude-3-5-sonnet-20241022"  # or any model your backend supports

If you're running OpenCode against a local Ollama instance, set OPENCODE_API_BASE="http://localhost:11434/v1" and pick a model you've pulled.

Running:

./agent-manager.sh

This drops you into a Tmux session with three panes. The top pane runs Claude Code, bottom-left runs Codex, bottom-right runs OpenCode. Each pane shows the agent's startup sequence—Claude loading context, Codex initializing, OpenCode connecting to its backend.

Sending prompts:

The script binds a key combination (default Ctrl-b p) that reads a prompt from a temporary buffer and broadcasts it to all three panes. Alternatively, you can type directly into any pane to give agent-specific instructions. The broadcast is for the "compare three approaches" workflow; the per-pane typing is for "Claude, fix this specific function while Codex handles the tests."

Practical first test:

"Write a Python function that parses a Kubernetes pod YAML and returns a list of container images with their pull policies. Include error handling for missing fields."

Watch Claude produce a clean dataclass-based solution with Pydantic validation, Codex generate a more procedural approach with manual dict traversal, and OpenCode output something that might work but needs cleanup. You'll have three working implementations in under 60 seconds. Pick the bones of the best one and ship.

The Engineer's Trade-Offs

Agent-Manager is brilliant in its simplicity, but simplicity has sharp edges. Here's the honest assessment.

What Works

Zero abstraction overhead. There's no framework to learn, no new configuration format, no agent protocol to debug. If you know Tmux and you have the three CLIs installed, you're done. This is the unix philosophy applied to AI tooling—small, composable pieces that do one thing.

True parallel execution. Unlike sequential agent chaining (run Claude, feed output to Codex, feed that to OpenCode), all three agents process your prompt simultaneously. For an FDE debugging a customer issue, those saved minutes compound.

Model diversity as a debugging tool. When all three agents produce the same bug, you probably described the problem poorly. When two agree and one diverges, the divergent one is either brilliantly creative or confidently wrong. Either way, the comparison surfaces assumptions you didn't know you were making.

Cost visibility. Each agent's token usage is visible in its own pane. You see Claude burning through your Anthropic budget, Codex hitting the OpenAI meter, and OpenCode chugging along on local compute. No blended pricing, no surprises.

What's Missing

No diff merging. You get three outputs in three panes. Integrating them is manual. For small functions, that's fine. For a 200-line refactor across five files, you'll wish for a merge tool that understands which agent produced the best version of each chunk.

No shared file system awareness. If Claude creates auth.py and Codex creates authentication.py, they'll happily overwrite each other or produce conflicting imports. You need to manage the working directory carefully—ideally, run each agent in a separate Git worktree or at least separate branches.

Tmux is a power-user interface. If you're comfortable with Tmux, this feels natural. If you've never used a terminal multiplexer, the learning curve is real. There's no GUI, no web dashboard, no pretty buttons. This is a tool for engineers who live in the terminal.

Agent startup latency. Each agent initializes independently. Claude Code might load in 3 seconds while OpenCode takes 15 to pull model weights or connect to a remote endpoint. The "simultaneous" prompt delivery is simultaneous, but the agents aren't ready at the same moment unless you wait for all three.

Where This Fits in an FDE Workflow

This isn't a replacement for your primary coding agent. It's a second-opinion machine. When you're about to write something consequential—a database migration, an auth middleware, a customer-facing API endpoint—firing the same spec at three agents catches edge cases your primary agent missed.

It's also a phenomenal learning tool. Watching three models reason through the same problem in real-time teaches you more about their strengths and failure modes than any benchmark table. For FDEs who need to make fast, informed decisions about which model to use for which customer problem, this is direct experiential data.

The pattern aligns with what we've seen in deploying LLM features at regulated enterprises—the insight that no single model satisfies every constraint, and the skill is in orchestrating multiple models against different parts of the problem.

FAQ

Q: Can I add a fourth agent, like Aider or Cline?

Yes. The script is Bash. Find the section that creates panes and adds a send-keys call for your fourth agent. You'll need to adjust the Tmux layout (the default is three panes, but Tmux can split recursively). The pattern is tmux split-window -h followed by tmux send-keys "your-agent-cli" C-m.

Q: Does this work over SSH?

Yes, and that's one of its best features. You can SSH into a dev server, start an Agent-Manager session, detach (Ctrl-b d), and reattach later (tmux attach -t agent-manager). The agents keep running. This is perfect for long-running refactors or batch processing tasks.

Q: What happens if one agent crashes?

The other two keep running. Tmux panes are independent processes. You can restart the crashed agent in its pane without affecting the others. The script doesn't monitor agent health—that's on you.

Q: Can I give different prompts to different agents?

Yes. The broadcast key sends the same prompt to all three, but you can click into any pane (Ctrl-b + arrow keys or mouse if enabled) and type directly. This is how you'd do the "Claude handles infrastructure, Codex handles app code" workflow.

Q: Is this better than just using Cursor or Copilot's agent mode?

Different category. Cursor and Copilot are integrated development environments with agent features. Agent-Manager is a comparison tool. Use Cursor for your daily coding, fire up Agent-Manager when you need a second (and third) opinion on a critical piece of code. They're complementary.

Q: How do I handle API costs across three agents?

Set budget alerts in your Anthropic and OpenAI consoles. OpenCode pointed at a local Ollama instance costs nothing beyond electricity. The cost of running three agents on a single prompt is roughly 3x the cost of running one—but if it saves you an hour of debugging, the math works out.

Q: Can I use this for non-coding tasks?

Any task that works in a CLI-based agent works here. You could run three agents analyzing the same log file, generating the same report, or answering the same customer question. The Tmux TUI doesn't care what the agents do—it just routes text to panes.

Q: What's the closest alternative?

There are multi-model chat interfaces (OpenRouter, ChatHub) that let you query multiple models simultaneously, but they're chat-focused, not agent-focused. Agent-Manager is unique in running full coding agents with file system access, tool use, and terminal integration in parallel. For a deeper dive into the multi-model orchestration mindset, check out our piece on why we deprecated our LLM router—sometimes the simplest multiplexing approach wins.