Herdr vs cmux: which one should you use?

Someone asked me a simple question after I published my deep dive into Herdr:

Is it better than cmux?

The short answer is no.

It is a different layer.

cmux is a native macOS terminal application built on libghostty. It adds vertical workspaces, notification rings, split panes, a scriptable browser, and a local automation API.

Herdr is a terminal-native multiplexer. It runs inside the terminal I already use, keeps its panes in a background server, detects coding agents, and exposes their lifecycle state through a CLI and socket API.

There is a large overlap. The important differences appear when I ask who owns the terminal, what survives a disconnect, and what an automation script knows about an agent.

The one-line difference

cmux is a Mac terminal built for supervising coding agents.

Herdr is an agent-aware terminal multiplexer that runs where the work lives.

That distinction explains most of the tradeoffs.

What both tools do

Both tools give me real terminal processes rather than rebuilding an agent conversation as chat messages.

Both have:

• workspaces, tabs, and split panes
• support for Codex, Claude Code, OpenCode, and other terminal agents
• notifications when background work needs attention
• a CLI and local socket API
• session restoration for supported coding agents
• SSH workflows
• ways for an agent or script to control other terminals

I can use either one to keep several repositories open, run agents beside development servers and tests, and stop polling terminal tabs by hand.

The differences are in the implementation and the level of meaning exposed to automation.

Side-by-side comparison

Native Mac application or terminal multiplexer

cmux owns the desktop surface.

It is a native Swift and AppKit application. It renders terminals through libghostty and can combine terminal panes with a real browser. It also uses native macOS notifications and familiar shortcuts.

This gives cmux a much larger visual surface.

Herdr does not replace my terminal emulator. It runs inside Ghostty, iTerm2, Terminal, Kitty, WezTerm, or the terminal I open over SSH.

That makes Herdr less integrated with the Mac desktop, but more portable. The same workspace model and keyboard interface follow the process instead of the laptop.

If you need the command-line foundations behind either tool, my free Shell Commands course covers processes, pipes, jobs, and the terminal environment.

Persistence is the biggest difference

Herdr has a background server that owns the pseudo-terminals.

When I detach from Herdr, the shell, development server, test watcher, and coding agent keep running. I can close the terminal window, reconnect later, and return to the same live processes.

Stopping the Herdr server is different. A cold restart restores the workspace layout and can resume supported agent conversations, but arbitrary commands must start again.

cmux saves its windows, workspaces, pane layout, working directories, scrollback, and browser history. Its session restore can also run the native resume command for supported agents.

It does not checkpoint an arbitrary local process when the application quits. A development server or test watcher comes back as a normal terminal unless another persistent tool owns it.

This is not automatically a problem. If I keep cmux open all day, or run persistent remote processes inside tmux, I still get a durable workflow.

But Herdr makes live detach and reattach part of its core runtime model.

Attention versus agent lifecycle state

cmux has a strong attention system.

Agent hooks, standard terminal notification sequences, and cmux notify can light up a pane, mark a workspace unread, show a desktop notification, and let me jump to the latest event.

Scripts can also add status pills, progress bars, and logs to the sidebar through the cmux CLI and socket API.

Herdr models the agent lifecycle directly.

It distinguishes between an agent that is working, blocked, done in the background, idle after being viewed, or present but unknown. Those states roll up from the pane to the tab and workspace.

The distinction matters to automation.

A script can tell Herdr to wait until a named agent becomes blocked or done. It can then read that exact agent’s terminal and send the next prompt to the same process.

The Herdr agent automation API exposes meaning, not only terminal input and unread notifications.

This is the part I find most compelling when one agent coordinates another.

Multi-agent workflows

cmux goes beyond generic terminal control for supported team systems.

Claude Code teammates and oh-my-opencode subagents can appear as native splits instead of hidden background processes. The parent workflow still comes from the agent system, while cmux makes every participant visible and controllable.

Herdr takes a more general approach.

I create panes, start named agents from supported CLIs, send each one a bounded task, wait on its lifecycle state, and read the result. Codex can coordinate Claude Code, or one Codex agent can create another Codex reviewer.

Herdr does not decide the team structure. My script or coordinator agent owns that plan.

Neither tool prevents two agents from editing the same file. Workspaces and panes organize processes. They do not create safe ownership boundaries by themselves.

My free Git course covers the branches, diffs, commits, and working-tree model behind that boundary.

cmux includes a scriptable browser

This is the clearest cmux advantage for web development.

cmux can place a browser pane beside the terminal. An agent can navigate, inspect the DOM, click, type, run JavaScript, capture screenshots, and read console or network activity through the same socket API.

The agent can change an application, open the local development server, and verify the result without leaving cmux.

Herdr has no built-in browser. I run a browser automation tool as a separate process or let the coding agent use its own browser integration.

If browser verification is central to the workflow, cmux gives me a more complete desktop environment.

Remote work

Herdr runs on the remote machine.

I can SSH into a Linux server, start Herdr there, detach, disconnect, and reconnect later. I can also use herdr --remote to attach a local Herdr client to the remote server.

The processes belong to the remote Herdr server. The interface remains a terminal UI, so I can reach it from another laptop or a phone.

cmux approaches remote work from the Mac.

The cmux ssh workflow creates a managed remote workspace. A relay on the remote host preserves sessions across connection drops, routes remote localhost traffic into browser panes, forwards notifications, and supports remote agent teams.

cmux can also attach to remote tmux sessions when I want tmux to own persistence.

Both approaches are capable. The choice is whether I want the remote multiplexer itself to be Herdr, or a Mac application supervising a managed remote workspace.

My free SSH course covers host verification, keys, config, tunnels, automation, and recovery if this layer is new to you.

How I would choose

I would choose cmux when:

• I work primarily on a Mac
• I want a polished native terminal application
• browser verification belongs beside the agent
• notification rings and unread navigation solve my attention problem
• I use Claude Code Teams or oh-my-opencode

I would choose Herdr when:

• the multiplexer must run on the machine doing the work
• arbitrary terminal processes must survive detach
• I move between local and remote Linux systems
• scripts need semantic agent lifecycle states
• I want to coordinate different agent products through one interface
• I need the same workflow from a small terminal screen

If coding-agent workflows themselves are new to you, my free AI Fundamentals course explains the agent loop, tools, permissions, context, and verification.

You can use both

This does not have to be a permanent choice.

Herdr can run inside a normal cmux terminal pane.

cmux can own the native Mac interface, browser panes, notification center, and desktop shortcuts. Herdr can own the persistent terminals and semantic agent state on the local or remote machine.

That combination makes sense when I want cmux’s desktop experience without giving up Herdr’s server-owned sessions.

The shortest answer remains the useful one:

cmux is the better Mac desktop terminal.

Herdr is the better terminal-native agent multiplexer.