Agent Orchestrator vs T3 Code vs OpenAI Symphony vs Cmux: Hands-On Comparison
Four tools shipped recently that keep getting compared as if they’re competitors. They’re not — they sit at different layers:
- Orchestration layer (full lifecycle): AO, Symphony
- Interaction layer (human-in-the-loop): T3 Code
- Terminal layer (agent-aware environment): Cmux
AO and Symphony compete most directly. T3 Code and Cmux solve different problems entirely.
I ran all four on real codebases. Here’s what I found.
What Each Tool Actually Is
Agent Orchestrator (AO) — Give it a GitHub/Linear/Jira issue. It spawns an agent in an isolated worktree, opens a PR, auto-fixes CI failures, routes review comments back. You intervene when it’s done, stuck, or needs approval.
T3 Code — Desktop app by Theo Browne. Chat with a coding agent, see visual diffs, stay close to every change before it lands. Currently wraps Codex, Claude Code adapter in progress.
OpenAI Symphony — Its reference Elixir implementation polls your Linear board, auto-claims tickets, spawns Codex agents, delivers PRs with proof-of-work. Elixir/OTP for fault tolerance. Linear-only. Still an engineering preview.
Cmux — Native macOS terminal built for AI agents. Split panes, notification rings, scriptable in-app browser, Unix socket automation. Not an orchestrator — it’s where you run your agents. macOS only.
Quick Pick
| Use Case | Tool |
|---|---|
| Fire-and-forget: issue in, PR out, CI fixes handled | AO or Symphony |
| Review every change before it lands | T3 Code |
| Autonomous agents + GitHub Issues or Jira | AO |
| Autonomous agents + Linear | Symphony (or AO — it has a Linear plugin too) |
| A better terminal for running any AI agent | Cmux |
| The easiest first experience | T3 Code (npx t3) or Cmux (brew install) |
| Run 10+ agents on a backlog in parallel | AO or Symphony |
| Maximum fault tolerance (restart recovery on crash) | Symphony |
| Swap agents, runtimes, trackers, SCM via config | AO |
Feature Matrix
| Feature | AO | T3 Code | Symphony | Cmux |
|---|---|---|---|---|
| Type | Orchestrator + dashboard | GUI for coding agents | Autonomous pipeline | Agent-aware terminal |
| Spawns agents on issues | Yes (manual + auto-poller) | No | Yes (polls Linear) | No |
| CI failure → auto-fix | Yes (retries, then escalates) | No | Yes (verifies before landing) | No |
| Review comment handling | Forwards to agent incrementally | No | Restarts from scratch | No |
| Auto-merge | Configurable | No | Yes (ref. workflow) | No |
| Agents supported | Claude Code, Codex, Aider, others | Codex (Claude soon) | Codex (community Claude port) | Any CLI agent |
| Issue trackers | GitHub, Linear, Jira | None | Linear only | None |
| Extensibility | 8 plugin slots, swappable via config | Provider adapters (early) | Agent runtime swappable, rest fixed | Unix socket API |
| Dashboard / UI | Web (Next.js) | Electron desktop app | No UI | Native macOS terminal |
| Platform | Cross-platform | Mac, Win, Linux | Cross-platform | macOS only |
| License | MIT | MIT | Apache 2.0 | AGPL-3.0 |
Where the Real Differences Show Up
The differences surface when things go wrong.
When an agent crashes
AO: Lifecycle manager detects the dead session via polling (~30s). Recovery system classifies it, attempts automatic recovery, then escalates to human notification.
Symphony (reference impl): OTP supervisor handles restart recovery with error context — designed to be transparent to the user.
T3 Code: The thread shows an error. You restart manually.
When CI fails
AO: Lifecycle manager detects the failure, fetches CI logs, sends them to the agent, agent fixes and pushes. Configurable retries, then escalates.
Symphony (reference workflow): Agent must provide proof-of-work — checks must pass before the PR is considered complete. If CI fails, the agent retries within its implementation run.
T3 Code: No CI handling. That’s on you.
When a reviewer requests changes
AO: Forwards the review comments to the agent on the existing branch. Agent addresses them incrementally and pushes.
Symphony (reference workflow): Closes the PR, creates a new branch, re-implements from scratch.
T3 Code: No automated handling — you manage reviews manually.
Cross-examined: When to Use What
Use AO when...
You want full lifecycle automation — issue in, PR out, CI fixes handled, review comments routed.
But can’t Symphony do this too? Yes. Both go from ticket to PR autonomously. Both handle CI verification. The differences: AO works with GitHub Issues, Linear, and Jira — Symphony is Linear-only. AO’s plugin slots let you swap agent, runtime, tracker, SCM, and notifier independently. Symphony’s reference implementation is more tightly integrated.
But can’t T3 Code also run autonomously? T3 Code has a mode where the agent writes files without asking. But there’s no CI failure handling, review routing, or auto-merge. T3 Code automates coding. AO and Symphony automate the entire PR lifecycle.
Use T3 Code when...
You want to stay close to every change before it lands — visual diffs, structured chat.
But can’t AO also do human-in-the-loop? AO has task-level approval gates and escalation notifications. But AO delegates code review to GitHub. T3 Code lets you stay close to individual changes before they touch the filesystem. Different granularity: AO is human-on-the-loop (oversight at milestones), T3 Code is human-in-the-loop (oversight at every edit).
Use Symphony when...
You want fault-tolerant autonomous agents with strong concurrency guarantees, and you use Linear.
But AO also has a Linear plugin? Yes. If you use Linear, both work. The concurrency architecture differs: Symphony runs on Erlang/OTP with supervision trees — designed for stronger restart recovery. Per-state concurrency limits bound concurrent agents. AO detects dead agents via polling and recovers, but doesn’t transparently restart mid-execution.
What if I don’t use Linear? Symphony won’t work for you today. AO supports GitHub Issues, Linear, and Jira.
Use Cmux when...
You want a better terminal experience for running AI agents — any agent, any orchestrator.
But AO already has a web dashboard with a terminal? Yes. AO’s dashboard has an xterm.js terminal via WebSocket. Cmux adds: native GPU rendering, lower latency, notification rings, drag-and-drop panes, scriptable browser. AO’s dashboard adds: PR lifecycle cards, CI status, review comments, fleet overview. Different layers — Cmux is a terminal, AO’s dashboard is a management plane.
Key Architectural Differences
AO — 8 plugin slots (runtime, agent, workspace, tracker, SCM, notifier, terminal, lifecycle). Reaction engine auto-handles CI failures, review comments, merge readiness — each with configurable retries and escalation. Session state is file-based. Polling-based detection (30s intervals).
Symphony — Erlang/OTP supervision trees for process-level fault tolerance. Agent behavior defined in WORKFLOW.md versioned with your code. Per-state concurrency limits. Review rework is destructive (full reset) in the reference workflow. Linear + Codex only (officially). Still an engineering preview.
T3 Code — Wraps coding agents with a conversational UI and visual diffs. Designed for focused 1-on-1 work where you want to see every change.
Cmux — Unix socket IPC. Agents can programmatically create panes, send notifications, control browsers. GPU-rendered via libghostry. Notification rings, in-app browser, socket/CLI automation. No higher-level orchestration logic.
Trust Model
Execution happens locally for all four tools. Code and metadata go to GitHub/Linear and LLM providers (Anthropic, OpenAI) depending on your agent and tracker config.
All tools work via git branches. Agents push to feature branches and open PRs — your main branch is never touched until you merge.
Getting Started
| Tool | Prerequisites | Install | Time to first run | Cost |
|---|---|---|---|---|
| AO | Node 20+, pnpm, tmux, git 2.25+ | pnpm install && pnpm build | ~10 min | Free + LLM API costs |
| T3 Code | Node, OpenAI API key | npx t3 | ~2 min | Free + API costs |
| Symphony | Elixir, Linear workspace, OpenAI key | mix setup && mix build | ~30–60 min | Free + OpenAI costs |
| Cmux | macOS 14+ | brew install --cask manaflow-ai/cmux/cmux | ~1 min | Free |
Combos (Honest Assessment)
| Combo | Reality |
|---|---|
| AO + Cmux | Complementary layers (orchestration + terminal), but no native integration yet. Manual tmux-attach inside Cmux panes. |
| AO + T3 Code | Aspirational. T3 Code has no “review existing PR” workflow today. |
| Symphony + Cmux | Same as AO + Cmux. Manual terminal attachment. |
FAQ
How many agents can run in parallel? AO: no hard limit, defaults to 5 concurrent (configurable). Symphony: defaults to 10 with per-state limits. T3 Code: no hard limit but designed for focused work.
Which one will still exist in 6 months? AO: backed by Composio, actively maintained. Symphony: backed by OpenAI, “engineering preview” — production commitment unclear. T3 Code: backed by Theo/Ping, active development. Cmux: backed by Manaflow (YC S24), actively maintained.
Solo dev or team? Solo: T3 Code or AO (manual spawn). Small team: AO with dashboard. Platform/infra team: AO (plugin arch) or Symphony (if on Linear). Enterprise: evaluate carefully — none are enterprise-hardened yet.
The Bottom Line
AO and Symphony compete at the orchestration layer. T3 Code and Cmux sit at different layers entirely.
The question isn’t “which is best.” It’s “which layer are you missing?”
Looking for Volunteers
We want hands-on, honest comparisons — not marketing, just data:
- AO vs Symphony — Same backlog, same codebase. Time-to-PR, fix rate, human time spent, cost.
- AO vs T3 Code — Same issue. Autonomous vs human-in-the-loop when the agent gets something wrong.
- AO + Cmux — Does Cmux actually improve the AO supervision experience?
Interested? Drop a comment on the GitHub Discussion.
Compiled March 2026. This space moves fast — comments welcome if anything’s outdated.