Managing a fleet of AI coding agents from one pane of glass

One AI coding agent is easy to run. You open a terminal, start it, and watch. The trouble starts at *three* — three agents, across two repos, on a laptop and a cloud VM. Now you're juggling terminal tabs, SSH sessions, and the nagging feeling that one of them finished five minutes ago and has been sitting idle waiting for you. That sprawl is the real problem, and it's what AI agent fleet management is about: running many agents across many repos and machines without losing the thread.

dev-mux is mission control for your AI coding agents — one pane of glass over the whole fleet.

The moment one agent becomes a fleet

The jump from one agent to several isn't linear; it's a step change in overhead:

• Where is everything? Agents are scattered across machines and terminal tabs.

Which window was the API refactor, and which was the migration?

• Who needs me? An agent that hits a prompt or a permission gate just... waits.

If you're not staring at that exact tab, it's blocked and you don't know.

• Did that survive? You closed the laptop to move rooms and half your sessions

died with the SSH connection. Now you're restarting and re-orienting instead of working.

None of these are AI problems. They're *fleet* problems — coordination, visibility, and durability — and they're exactly what a control plane is for.

Hub and spoke: one coordinator, many machines

dev-mux uses a simple, honest shape. A small per-tenant coordinator VM — the hub — holds persistent terminal sessions to each of your machines (the spokes), where the agents actually run. The spokes are just your own boxes: a laptop, a workstation, a cloud VM you own, a Raspberry Pi.

Crucially, the hub is a relay, not a host. The agents run on your compute; the model calls run on your API keys. Your code never leaves your machines, and it's never stored on our servers — the hub persists no repositories and no transcripts. Fleet management doesn't cost you the trust model; the coordinator coordinates, it doesn't custody your code.

One pane of glass over every agent

Instead of hunting through tabs, you fly the fleet from a single live web cockpit. The whole roster is in front of you at once:

• Every machine, every session, in one view. See all your spokes and the sessions

running on each — not one repo at a time, the whole fleet.

• Per-repo sessions with a real IDE layout. Each repo gets its own named session

with the panes you'd set up by hand, so an agent and its context stay together instead of blurring across tabs.

• Isolated feature work with worktrees. Spin up a git worktree for a branch so an

agent can work in isolation without disturbing your main checkout — and see it in the same console as everything else.

• Jump straight to any session. Pick a machine and a session and you're driving

its terminal live, over the web.

The category difference is right there: competitors tend to be single-session or single-repo. dev-mux is built for the fleet.

The fleet tells you who needs attention

The hardest part of running many agents is knowing *which one to look at*. dev-mux surfaces that for you: it watches each session and flags the ones that need a human — an agent that's hit a prompt, asked a permission question, or gone quiet after doing work. Instead of polling tabs, you glance at the console and go to the session that's actually waiting. That's the difference between supervising a fleet and babysitting it.

Sessions that don't die when your network blips

A fleet you have to rebuild every time you change locations isn't a fleet you'll actually use. dev-mux gives you tmux-backed sessions with automatic reconnect: the sessions live in tmux on the hub, and every surface reconnects automatically when the network hiccups. Close the lid on the train, reopen at your desk, and the whole fleet is right where you left it — still running, nothing lost.

Fly it from anywhere

Today that pane of glass is a live web cockpit — real terminals over the web, dense and keyboard-first, built for operators who'd rather see everything at once than click through menus. A phone app and EvenRealities G2 HUD glasses are coming, which is where the aspiration gets literal: glance at the glasses, see a session needs a nudge, voice a command, and the fleet keeps grinding on your own machines back home. Your entire dev environment, anywhere — even on the beach.

The takeaway

Running a fleet of AI coding agents doesn't have to mean a wall of terminal tabs and dead SSH sessions. Put a thin coordinator in front of your own machines, get one console over every agent and repo, let the fleet tell you who needs you, and keep the sessions alive across every network blip — all with zero of your code on our servers. That's AI agent fleet management done the honest way: your machines, your keys, one pane of glass.

---

*New to the model and wondering where the agents run? See "Why your AI coding agents should run on your own machines." Not sure whether you need Tailscale? See "Do I need Tailscale to use dev-mux? The honest answer."*