NTM Wraps tmux in a Named Control Plane for Multiple Coding Agents

The gap NTM is trying to fill between tmux and a pile of agent terminals

The README states the problem plainly: plain tmux gives you panes, but it does not give you durable coordination, work selection, safety policy, approvals, history, replayable automation surfaces, or a shared control model that both humans and agents can use. That is a fair description of the situation after you have opened four panes and typed a prompt into each one. The panes exist, the work does not have an owner, and nothing records what was asked or which files an agent believes it controls.

NTM's answer is to make the tmux session the unit of management. A session has a name, a set of labelled agent panes, and a user pane. Commands such as ntm list, ntm status and ntm view operate on that unit rather than on a window index you have to remember. The intended user is a developer already running Claude Code, Codex or Grok Build locally and willing to keep tmux as the substrate. It is not a hosted orchestrator, and the README describes it as a local control plane, so the blast radius of a mistake is your own machine.

Named sessions, labels and the pane model behind ntm spawn

The mechanism is visible in the command surface. ntm spawn takes a session name plus counts per agent type: ntm spawn payments --cc=3 --cod=2 --agy=1 creates three Claude panes, two Codex panes and one Antigravity pane inside the session called payments. ntm add appends more panes later, and ntm zoom payments 3 focuses a single pane by index. Labels let two swarms share one project directory: the README shows ntm spawn payments --label backend --cc=2 --cod=1 followed by ntm spawn payments --label frontend --cc=2.

On top of the panes sit three coordination layers the README names separately. Agent Mail carries messages between a human overseer and the agents, with inbox views and file reservations. Worktrees give each agent its own Git checkout on a branch named ntm/<session>/<agent>. The work graph commands, ntm work triage and ntm work next, select what to do next when the repository uses br and bv. The README is explicit that worktrees do not replace reservations: reservations communicate intent, worktrees provide the separate checkout boundary. That distinction matters, because a reservation is a claim recorded in NTM's own state, while a worktree is enforced by Git.

Getting it running: install, dependency check and a first swarm

Installation is a piped shell script: curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/ntm/main/install.sh?$(date +%s)" | bash -s -- --easy-mode. The cache-busting query string is part of the documented command, not an accident. Shell integration comes next with eval "$(ntm shell zsh)", which is what makes the session commands usable from your current shell rather than a subshell.

The first real step is ntm deps -v, which the README calls the sanity check for tools and integrations. Required is tmux. Required for spawning agents is whichever CLI you intend to run, typically Claude Code, Codex, Antigravity CLI or Grok Build, with Gemini CLI supported as legacy. Optional but named as powerful are br, bv, Agent Mail, cass, dcg and pt. That list is the honest cost of the tool: the binary is pure Go, but the runtime experience is intentionally integration-heavy, in the README's own words.

A working sequence from the documentation: ntm quick api --template=go to scaffold, ntm spawn api --cc=2 --cod=1 --agy=1 to launch, ntm dashboard api and ntm palette api for the operator surfaces, ntm send api --cc "Map the auth layer and propose a refactor plan." to dispatch, ntm checkpoint save api -m "before auth refactor" to capture state, and ntm serve --port 7337 to expose the local API. For a machine-readable view without the server, ntm --robot-snapshot is the documented entry point.

Grok Build support is phase one, and the README says so

The Grok section is the most specific limitation in the material, and it is worth reading closely before assuming parity across agent types. NTM recognises the official xAI Grok Build CLI as the canonical grok agent type and launches it with the --always-approve flag. Model selection is delegated by default; a bare spec uses whatever the authenticated account has, and an exact override takes the form ntm spawn research --grok=1:MODEL_ID:EFFORT.

What phase one covers, per the README: configuration, model and effort arguments, launch, adopt, exact process discovery, status, count, schema and doctor projections, and topology-only saved-session restore. What it does not claim: authenticated fullscreen-TUI readiness, automated prompt delivery and assignment, interrupt-with-message, restart, and restore-time process relaunch. Those operations fail closed before pane mutation, and robot flags --spawn-wait and --spawn-assign-work also fail closed for Grok panes. The practical consequence is that a Grok pane is something you drive by hand. If your workflow depends on ntm send reaching every pane, a mixed swarm with Grok in it has a hole in it, and the documentation is unusually candid about where that hole is.

The licence badge and the repository metadata disagree

The README badge reads MIT+OpenAI/Anthropic Rider. The repository metadata supplied here records the licence as NOASSERTION, which means the hosting platform could not classify it automatically. Those two signals point at different things, and the difference is not cosmetic: a rider attached to an MIT grant can add conditions that a plain MIT file does not have, and the text of that rider is not reproduced in the README.

This is not a reason to avoid the project, but it is a reason to read the licence file in the repository before shipping NTM inside a company image or a product. Nobody should treat a badge as the terms. If your legal review process requires an SPDX identifier, NOASSERTION means it will not be resolved automatically. That is the whole point: the classification gap is real, and the fix is to open the file.

Checkpoints, timelines and the audit trail as an alternative to scrollback

The durable-operations group is where NTM diverges most from simply leaving a tmux session open. ntm checkpoint save api -m "before auth refactor" records a recoverable point, and the README groups checkpoints with timelines, audit logs, saved sessions and pipelines under the same heading. The audit surface is a separate command, ntm audit, and the serve command exposes the same state over REST, SSE and WebSocket with an OpenAPI description generated by ntm openapi generate.

The comparison to make is with tmux's own facilities. tmux has a scrollback buffer and, with plugins, session saving. What it does not have is a record of which agent was asked to do what, or a policy decision attached to a destructive command. NTM puts those in its own state store rather than in the pane. The trade-off is that the state is NTM's: a checkpoint is only as useful as the version of NTM that wrote it, and the README lists no format or migration guarantee for saved sessions. Restore for Grok panes is described as topology-only, which is a concrete example of a checkpoint that brings back the layout but not the running process.

Where a simpler tool wins: plain tmux plus a shell script

The honest alternative is not another orchestrator. It is a shell script over tmux. If you run two agents, one repository and one terminal, then tmux new-session, split-window and send-keys cover the same ground with no Go binary, no dependency check and no licence question. The difference in approach is where the state lives. A script keeps the layout in the script and the coordination in your head. NTM keeps both in a session record that other commands, including robot JSON and the REST API, can read.

That difference only pays off past a certain size. With one agent, NTM's policy layer, mail system and work graph are overhead you configure and never use. With four or more agents across two labels, the same features are the reason the session is still comprehensible an hour later. The README's own framing supports this reading: it describes the problem as sustaining parallel agents, not starting them. Starting is the easy half.

Maintenance cost and what to verify before committing

NTM moves quickly. The supplied release list shows v1.32.0 on 2026-09-04, v1.33.0 on 2026-09-07 and v1.33.1 on 2026-09-09, three releases in six days, with the last push timestamp matching the newest release. A cadence like that means your pinned version matters if you script against ntm --robot-snapshot or the REST surface, because those are the interfaces most likely to shift. The install script fetches from main, so the default path gives you whatever is current rather than a tagged build.

The dependency surface is the other recurring cost. br, bv, Agent Mail, cass, dcg and pt are listed as optional, but the work triage and coordination features depend on them, so a machine without them gets a smaller NTM than the README describes. Before adopting, run ntm deps -v and read what it reports as missing against the workflows you actually intend to use. Then read the licence file, and decide whether a Grok pane that fails closed on prompt delivery is acceptable in your swarm. If either answer is no, the tool is not ready for that workflow yet.

Editorial conclusion

Adopt NTM if you already run several agent CLIs in tmux and want named sessions, labels, checkpoints and a robot-readable snapshot without writing your own glue. Do not adopt it if you need a stable multi-vendor abstraction: the README states that Grok Build support covers launch and status but fails closed on prompt delivery, interrupt, restart and restore-time relaunch, and Gemini CLI is described as legacy. Before installing, run ntm deps -v against your machine and read the licence file, because the badge says MIT plus OpenAI/Anthropic Rider and the repository metadata says NOASSERTION.

Official sources

1. Dicklesworthstone/ntm on GitHub
2. Issues
3. README
4. Releases