initech vs tmux for AI Coding Agents

tmux is the default terminal multiplexer. It is excellent at what it was designed for in 2007. Running a fleet of AI coding agents was not on that list.

Short answer. tmux gives you panes that each run a shell. initech gives you panes that each run an AI coding agent, plus the glue to coordinate them: activity detection, synchronous messaging, role-scoped commands, and cross-machine addressing. If you only need panes, tmux is the right tool. If you need panes that talk to each other and to you, initech fits better.

What tmux Does Well

tmux is the product of nearly two decades of hard-fought stability. It is a reasonable default for any terminal workflow:

Rock-solid session persistence across SSH disconnects
Vast keybinding vocabulary that power users have deeply internalized
Predictable pane and window primitives that compose well with shell scripts
Works everywhere: every distro, every BSD, every container
A massive plugin ecosystem (tpm, resurrect, continuum) and thousands of dotfile repos to learn from

If you are running three shells and a log tail, tmux is fine. You do not need anything else.

The Gap: tmux Is Shell-Aware, Not Agent-Aware

An AI coding agent running inside a pane is not a shell. It is a long-lived process that enters and exits several states: reading output, thinking, streaming tokens, waiting on tool approval, finished, stuck. tmux cannot tell these states apart because tmux does not read pane contents in a structured way.

Some specific places this friction shows up:

No activity detection. tmux's monitor-activity flags any byte of output. An agent streaming a token looks identical to an agent that finished. You end up peeking every pane manually.
Fire-and-forget messaging. send-keys writes bytes to the PTY and returns. If the target process is frozen or quit, the keystrokes vanish and tmux will not tell you.
No addressable agent names. Panes are addressed by %{id} or session:window.pane. Scripts that send work to "eng1" need to translate role names to pane coordinates every time.
No role-scoped config. Every pane runs the same shell with the same environment. Launching Claude Code in one pane and Codex in another means hand-editing startup commands per pane.
Single machine. A tmux session is scoped to one host. Running agents across a laptop and a workbench requires a bespoke SSH + socket setup you build yourself.

Feature Comparison

Capability	tmux	initech
Split panes	Yes	Yes
Session persistence	Yes	Yes
Keybinding customization	Extensive	Growing
Agent activity detection	No	Yes, state machine per pane
Synchronous messaging with delivery guarantee	No (send-keys is fire-and-forget)	Yes (`initech send`)
Read-only peek without interrupting	capture-pane, awkward	`initech peek`
Role-named panes (eng1, qa, super)	Pane coordinates only	Yes
Per-role startup command	Scriptable, manual	Declared in `initech.yaml`
Cross-machine agent addressing	No	`host:agent` format
Live Mode (auto-rotate to the interesting pane)	No	Yes
Scheduled messages (timers)	No	`initech at`
Web viewer / browser monitoring	No	Yes
MCP server for external tool access	No	Yes
Plugin ecosystem	Huge (tpm, dozens of plugins)	None yet
Runs anywhere (BSD, Linux, macOS)	Yes	macOS + Linux

Concrete Scenarios

You want to run three Claude Code sessions side by side

Both work. tmux needs a startup script that launches claude in each pane. initech declares it in initech.yaml:

# initech.yaml
agents:
  eng1: {{ role: engineer }}
  eng2: {{ role: engineer }}
  eng3: {{ role: engineer }}

$ initech

The equivalent in tmux is a shell script you write and maintain per project. Fine for one project. Less fine across five.

You want to dispatch work to a specific agent from your editor

tmux: tmux send-keys -t initech:0.1 "fix the auth bug" Enter. Requires knowing the pane coordinate. If the pane is currently running a different command, the keys append to it. No error.

initech: initech send eng1 "fix the auth bug". The CLI resolves the role name, delivers synchronously, and exits non-zero if the agent does not exist or the TUI is not running. See the communication docs.

You want to notice when an agent finishes without staring at the screen

tmux: you bind a key to cycle panes, or you install the tmux-resurrect-adjacent activity plugins and hope they distinguish token-streaming from idle. They do not.

initech: Live Mode watches every pane, scores activity, and rotates the focused pane to whichever agent most recently changed state. You glance at the TUI once in a while and the interesting pane is already in front.

You want agents on two machines to coordinate

tmux: you SSH into each host, run tmux there, and write scripts that SSH back and forth. Manageable. Not pleasant.

initech: both machines run initech with matching peer_name config. Any agent can initech send workbench:eng1 "..." or initech peek laptop:qa. See cross-machine coordination.

When to Pick Which

Pick tmux if...

You are running shells, editors, and log tails. Not agents.
You have a tmux muscle memory investment you do not want to retrain.
You need to run on a platform initech does not support yet (BSD, old enterprise Linux).
You depend on specific tmux plugins (resurrect, continuum, a custom statusline mod).

Pick initech if...

You run two or more AI coding agents at the same time.
You want the TUI to tell you who finished without peeking.
You send work between agents and care whether it got delivered.
You have agents on more than one machine.
You mix tools (Claude Code in one pane, Codex in another, OpenCode in a third) and want per-role startup commands.

Install initech

macOS via Homebrew:

$ brew install nmelo/tap/initech

Or curl:

$ curl -fsSL https://initech.sh/install.sh | sh

Then initech init && initech. Full walkthrough in getting started.

Disclosure: this page is written by the initech team. We tried to describe tmux's strengths accurately. Corrections and counterexamples are welcome at github.com/nmelo/initech/issues.