What This Stack Does
This stack turns tmux into a controlled comparison bench for four terminal coding agents. Claude Code, Codex, Gemini CLI, and OpenCode receive the same scoped task, but each works in its own pane and its own Git worktree. The goal is not to make four agents edit one checkout at once. It is to produce four inspectable proposals that can be compared by tests, diff quality, risk, and cost before a human chooses what reaches the main branch.
The workflow is useful for migrations, difficult refactors, test generation, and ambiguous bugs where a single answer may hide tradeoffs. It is deliberately heavier than opening one agent. Use it when the expected value of independent approaches is higher than the model and review cost, and keep ordinary maintenance in a single lane. The stack provides an operating pattern, not evidence that any provider will always generate the best patch for every repository.
Architecture and Lane Boundaries
tmux owns the terminal layout and makes every lane visible without merging their filesystem state. Create one read-only briefing pane, four agent panes, one test pane, and one arbitration pane. Each agent gets a named worktree and branch derived from the same starting commit. Shared instructions belong in the repository AGENTS.md or equivalent project guidance; secrets, generated artifacts, build caches, and untracked scratch files should never be copied casually between lanes.
Give every agent the same acceptance criteria but a narrow role. Claude Code, Codex, and Gemini CLI can each attempt the implementation, while OpenCode can serve either as the fourth implementation lane or as a provider-flexible review lane. Do not let one lane silently rewrite another lane before comparison. Capture the prompt, starting commit, model or provider configuration, command transcript, test result, and final diff summary so the decision is reproducible.
Step-by-Step Parallel Workflow
Start by freezing the task definition: affected paths, prohibited files, expected tests, performance constraints, and the stop rule. Create four worktrees from the same commit, open them in separate tmux windows, and confirm that each agent can read only the intended repository and environment. Run the same prompt once per lane. When an agent asks for broader authority, either answer consistently across all lanes or record the deviation instead of letting one candidate receive an unfairly richer brief.
After implementation, run the same deterministic commands in every worktree. Compare test status, changed files, dependency churn, error handling, and how directly each patch satisfies the acceptance criteria. The arbitration lane should cherry-pick nothing until the comparison is complete. Prefer the smallest candidate that passes the contract, or manually compose a new patch from understood ideas. Never merge four generated diffs simply because each contains a useful fragment.
Quality, Security, and Repository Safety
Parallel agents multiply both useful exploration and failure modes. Keep production credentials out of the panes, use least-privilege tokens, and disable network or write access when a task does not require it. Treat tool calls, generated shell commands, and dependency installation as untrusted until reviewed. Worktrees prevent many accidental collisions, but they do not isolate shared services, databases, package caches, containers, or external APIs; those resources need separate names and explicit teardown rules.
A practical gate has three layers: automated checks, diff review, and intent review. Tests catch regressions, a human-readable diff catches unnecessary churn, and intent review confirms that the patch solves the requested problem rather than an easier neighboring problem. Scan for secrets, generated binaries, lockfile surprises, disabled tests, and new telemetry. If a candidate cannot explain a destructive command or schema change, reject it instead of spending more tokens defending it.
Cost and Model Strategy
The client tools in this stack have different access and pricing paths, and provider usage can dominate the real cost. Record elapsed time, token or credit consumption where exposed, retry count, and review minutes for each lane. A cheap patch that needs an hour of cleanup may cost more than a stronger first pass. OpenCode can connect to multiple providers, but that flexibility should not be confused with a free inference layer; the selected model and hosting route still determine cost and data handling.
Use smaller or lower-cost models for repository mapping, test discovery, and documentation drafts, then reserve stronger models for the uncertain implementation or final review. Stop a lane when it violates scope twice, repeats the same failing approach, or exceeds the budget set before the run. The most valuable output is often a clear rejected hypothesis. Keep that note so future sessions do not pay to rediscover the same dead end.
When to Use It and the Bottom Line
Choose this stack for high-impact changes with several plausible implementations, for evaluating a new CLI against tools your team already knows, or for generating independent review perspectives. Skip it for a one-line fix, an urgent incident with one accountable operator, or a repository that lacks deterministic checks. Parallelism without a stable test and review contract only produces more text and more branches, not more confidence.
The durable pattern is simple: tmux coordinates visibility, isolated worktrees protect candidate state, the four CLIs generate independent evidence, and one human-owned arbitration step decides the outcome. Preserve the same start commit, prompt, test suite, and stop rules across lanes. With those controls, the stack becomes a repeatable engineering experiment; without them, it becomes an expensive race between tools that were never asked the same question.