If you run more than one AI coding agent, you already know the actual bottleneck isn't the model. It's the terminal tabs. You've got a Claude Code session waiting on a permission prompt in tab 3, a Codex run that finished ten minutes ago in tab 7, and no way to know either fact without switching to look. agent-manager, a solo-built, open-source terminal UI that launched on Product Hunt this month and picked up a parallel Hacker News Show HN run, a Trendshift trending slot, and syndication through TLDR's dev-tools newsletter, is built entirely around that one problem: fleet visibility for the coding-agent CLIs you already run.
It's a good, tightly-scoped tool. It's also a useful case study in something the launch copy doesn't advertise: "runs every AI coding agent" and "knows what every agent is doing" turn out to be two different claims, and only one of them is actually true for every agent it supports.
What agent-manager actually is
agent-manager is a single Go binary that wraps tmux. It doesn't run a daemon, doesn't need a config file to start, and doesn't touch the network unless you tell it to check for updates. You install it with Homebrew, an install script, the AUR, mise, or go install, and it drops you into a terminal session list: a foldable tree of projects, with every agent session you've spawned nested under them by path.
The core interaction is one key. Hit space on a project row, type a sentence, hit enter — an agent is now running in that project's directory with your prompt already sent. The prompt bar doesn't close; type the next task and it goes to the next agent, in a different project if you want, without you ever navigating away from the list. tab cycles which CLI the next spawn uses — claude, opencode, codex, grok, or anything else you've configured. On an existing session row, that same space key does the opposite job: it sends a reply straight into a blocked agent's pane, so answering a permission prompt or a clarifying question never costs you a full attach.
Out of the box it has live status support for six tools: Claude Code, OpenCode, Codex, Grok Build, Gemini CLI, Pi, and, as of the most recent release, Hermes Agent. Any other CLI can run as a session too — it just won't get a status color until you write a regex rule for it in the TOML config.
Sessions report one of six states: working, waiting (blocked on you), finished, errored, idle, or dead. A folded group still shows a per-status count, so a collapsed subtree of twenty sessions can tell you at a glance whether three of them need you right now.
Sessions aren't flat, either. Groups are paths, not folders — backend/api/auth nests as deep as the actual work does, sessions can live at any node in that tree, and the arrangement survives a restart of the manager itself. A folded group still carries a per-status count on its row, so a collapsed subtree of a dozen sessions can tell you at a glance whether anything underneath is blocked on you, without expanding it. F folds or unfolds everything at once; K/J reorder siblings; a archives a finished session or an entire subtree out of the active view, and u brings it back. Plain terminal tabs live in the same tree too — T opens one in the selected group for builds, git commands, or anything that isn't an agent — so a project's shells and its agents end up in one list instead of split across two mental models.
Session lifecycle is deliberately decoupled from the agent's conversation. x kills a session to free the RAM it's holding without discarding anything; v revives it later on the exact same conversation thread, by session ID, not a fresh context. R goes the other direction — restart on an empty context, same name, group, directory, and tool, when you want a clean slate without re-typing the setup. Recent releases added portable notifications (macOS, Linux, Ghostty, or a terminal-bell fallback under WSL2) that fire on state transitions — waiting, finished, failed — so you don't have to keep the list on screen to know when something needs you, and a header strip of resource gauges (CPU, RAM, swap, disk, network) gives a rough read on whether the fleet you just spawned is actually within what the machine can handle.
The second headline feature is review mode. ctrl+r takes over the screen for the selected session's repo: changed files with line-count deltas on the left, the full file with changed lines tinted on the right, syntax highlighted, four scopes (uncommitted, versus the merge target, last commit, staged), and a split or unified layout. You leave comments on specific lines, and pressing C compiles every comment into a single review prompt sent back into the agent's pane — no copy-pasting diff context by hand.
The part worth paying attention to: how it resolves which repo to review
Here's the detail that separates agent-manager from being just "Claude Squad with extra UI": it ships its own Model Context Protocol server, embedded in the same binary, and registers it into every session it spawns. That MCP server exposes four tools back to the agent: rename, review_repo, review_base, and review_mode.
In practice, this means the agent is expected to tell the manager where it is. A session's working directory is often a monorepo umbrella folder holding a dozen repos — cd-ing there tells you nothing about which repo an agent actually touched. Instead of guessing from the filesystem, agent-manager lets the agent call review_repo and review_base once it knows what it did, and those declarations — validated against git — win over any heuristic. If nothing is declared, it falls back to ranking dirty working trees first, then the most recent commit. The same protocol is why sessions rename themselves: a screen of claude-a1b2, claude-c3d4, claude-e5f6 becomes a screen of fix-auth-redirect, add-webhook-retry, refactor-pagination once each agent knows its own task, without you typing a single label.
This is a genuinely well-chosen architectural bet. Most session managers in this category infer state from outside the agent — parsing pane text, matching on cwd. agent-manager instead gives the agent a channel to self-report, and only trusts the inference when self-reporting is unavailable. It's a small design choice, but it's the kind that tends to compound: the more of the agent's own state becomes queryable rather than inferred, the less brittle the whole system gets.
Which makes the other half of the design more interesting by contrast.
Only one agent gets to self-report its status. The rest get guessed.
The docs are explicit about this, if you read past the feature list: for Claude Code, session status "arrive[s] from its own hook events rather than from guessing at the pane." Claude Code ships native lifecycle hooks — a real signal the manager subscribes to. Working, waiting, finished: these are events Claude Code itself fires, not text agent-manager infers.
Every other supported tool — Codex, OpenCode, Grok Build, Gemini CLI, Pi, Hermes Agent — doesn't have that hook surface available to a third-party wrapper, so agent-manager falls back to what the config file calls [tools.] blocks: regex rules matched against the pane's rendered text. That's the same technique Claude Squad, ccmanager, and most of the category use, and it's inherently probabilistic — you're pattern-matching a CLI's output formatting, which is not a stable API and which those tools' authors did not design for external consumption.
The project's own changelog is the evidence this isn't theoretical. A recent release note reads: "Codex no longer stays falsely marked as working when an answer merely quotes its activity text." That's a real bug, in production, caused by exactly the failure mode you'd expect from regex-based detection: Codex's response happened to contain the string pattern the rule was watching for, and the manager read it as still-running when it had already finished.
None of this makes agent-manager unusually fragile — it makes it honest about a limitation the entire category shares, and it happens to be the one project whose docs and changelog let you see the seam. If your fleet is mixed, the practical takeaway is: trust the "waiting" badge without checking, always, for Claude Code sessions. For everything else, treat the badge as a strong hint that's worth a glance at the pane before you act on it, especially right after the agent's response contains text that looks like the tool's own status words.
What changed versus the rest of the category
This space is crowded and has been churning hard in 2026. A rough map of where agent-manager sits:
| Tool | Interface | Worktree isolation | Review flow | Status detection | Platform | License |
|---|---|---|---|---|---|---|
| agent-manager | Terminal (tmux) | Optional, alt+w
|
Full-file diff, line comments → agent prompt | Hooks (Claude Code only) + regex | macOS, Linux, WSL2 | Apache-2.0 |
| Claude Squad | Terminal (tmux) | Yes, per session | None built in | Regex/pane | macOS, Linux | AGPL-3.0 |
| ccmanager | Terminal (no tmux) | Yes, per session | None built in | Regex/pane | macOS, Linux, Windows | MIT |
| Conductor | Native macOS app | Yes, per session | GUI diff view | App-level | macOS only | Closed, free |
| Nimbalyst (formerly Crystal) | Desktop + iOS | Yes, per session | GUI diff view | App-level | macOS, Windows, Linux + iOS | MIT |
| vibe-kanban | Local web board | Yes, per workspace | Inline PR-style comments | App-level | Cross-platform, browser | Apache-2.0 |
A few things stand out. First, agent-manager is the only tool in this set built around a single sentence-in, agent-out loop rather than a form or a card — spawning is designed to be faster than typing a task name would be on its own. Second, the review mode is a real differentiator against the terminal-native competitors: Claude Squad and ccmanager manage sessions but hand you off to your own git diff or editor for review; agent-manager keeps you in the TUI with syntax-highlighted, line-commentable diffs that compile into a review prompt automatically.
Third, and worth knowing if you're evaluating the category rather than just this one tool: vibe-kanban, currently the most-starred project here at nearly 28,000 stars, is sunsetting — its own README says so directly, pointing to a shutdown announcement, which contradicts some secondary coverage still describing it as an actively community-maintained project. And Crystal, the open-source desktop option several older comparisons still cite, was deprecated in February 2026 and replaced by the commercial-adjacent Nimbalyst. If you're choosing a tool in this space today, verify current status directly against the project's own repo before you commit — the write-ups lag the reality by months in a category moving this fast.
Against that backdrop, agent-manager's positioning is: stay terminal-native like Claude Squad, but add the review loop and the self-declaring MCP layer that neither Claude Squad nor ccmanager has, without becoming a GUI app like Conductor or Nimbalyst, and without asking you to model your work as kanban cards like vibe-kanban did.
Why this actually matters for how you work
Cost. Free and open source under Apache-2.0. There's no subscription layer — you pay for the underlying agent CLIs' own subscriptions or API keys exactly as you would running them standalone. agent-manager adds zero inference cost of its own.
Latency and footprint. Because it's a thin process wrapping tmux with no daemon and no server, there's effectively no overhead beyond what tmux itself costs, which is negligible. Sessions live on tmux, not inside agent-manager's own process, so quitting the TUI — or the laptop lid closing — doesn't touch anything running. That's a meaningfully different reliability model than a GUI app whose own process needs to stay alive for the agent sessions to keep going.
DX. The install story is about as low-friction as it gets for a systems tool: one binary, no Node/npm toolchain to manage, works the moment you run it with sane config defaults already populated. The keyboard-only interaction model is fast once you internalize six or seven bindings, and the ? overlay is searchable, which matters more than it sounds like for a tool with this much surface area.
Lock-in. Effectively none. agent-manager launches the CLI tools you already have installed, using your existing login, subscription, config files, and MCP servers, unmodified. Uninstalling agent-manager doesn't touch your Claude Code or Codex setup at all — you just lose the fleet view. That's a real advantage over anything that wants to own your workflow (a hosted board, a proprietary agent runtime).
Security. The one thing worth understanding rather than assuming: agent-manager auto-registers an MCP server into every session it spawns, meaning every agent you run through it gains tool-calling access back into the manager (rename, declare-repo, declare-branch, declare-review-mode) by default. That's a reasonable, scoped surface — those four tools can't execute arbitrary commands — but it is a capability the agent didn't have when you ran it standalone, and it's worth knowing it's there if you're running an agent against an untrusted prompt or repo. Sessions do run isolated on a private tmux server namespace (agentmgr), separate from any tmux you run yourself, which at least contains the blast radius of a kill-server mistake.
Maintainability. This is genuinely early software: the GitHub repo was created July 15, 2026, and as of this writing sits at roughly 306 stars, 21 forks, and 22 open issues, versioned sub-1.0. Contribution history is almost entirely one author (over 380 commits from the maintainer against single-digit counts from anyone else), which is normal for a project this young but is a real bus-factor risk if you're building team process around it. The pace of shipping has been fast — resource gauges, notifications, Hermes Agent support, and MCP-driven terminal control all landed within weeks of launch — which is a good sign for momentum and a mixed one for API stability.
Where it actually earns its keep
-
Parallel feature work across a monorepo. Spawn one agent per API endpoint or one per failing test file, each in its own group, each in its own worktree via
alt+w, and watch six status badges instead of six terminal tabs. -
Review-heavy days. If your actual bottleneck is reading diffs and writing feedback, not writing prompts, the
ctrl+r→ comment →Cloop removes almost all the copy-paste tax of doing that over a chat interface. - Long-running background work. Kick off a "write missing tests for this module" agent, close the laptop, come back — the session is still there because it never depended on the manager staying open.
- Exploring an idea without breaking the main thread. Conversation forking lets you split off a named sibling session to try an alternative implementation, without disturbing the agent that's still making progress on the main approach.
What the launch page leaves out
- Windows is WSL2 or nothing. There's no native Windows binary; the whole design depends on tmux, which doesn't run outside a Linux environment. If your team is Windows-native and not already living in WSL2, this isn't a fit.
- No cost or token tracking. Several competitors in this space (and adjacent "coordinated hive" tools) surface spend across sessions. agent-manager doesn't — you're tracking usage the same way you would running each CLI standalone, per-provider.
- No shared memory or inter-agent messaging. Every session is fully isolated. If two agents are working on overlapping code, nothing here prevents them from colliding — you're still the coordination layer, same as Claude Squad or ccmanager. If you need agents that share context or hand work to each other, this category of tool isn't solving that problem at all; you'd be looking at a different class of system entirely.
- No programmatic API. Everything routes through the TUI. If you wanted to script fleet management — kick off agents from CI, query status from another tool — there's no exposed interface for that today.
- Status detection quality varies by tool, as covered above, and that variance isn't visually distinguished in the UI. A "waiting" badge on a Claude Code row and a "waiting" badge on a Codex row carry different confidence levels, but they render identically.
An independent read
The MCP self-declaration mechanism is the smartest thing in this product, and it's the part I'd point to if someone asked what a well-designed integration between a wrapper tool and the agents it wraps looks like: instead of the manager trying to out-guess the agent about its own state, it gives the agent a narrow, validated channel to just say. That's the right direction for this whole category to move in, and it's more thought-through here than in the terminal-native competitors that predate it.
The gap is that the pitch — "the fastest workflow for every AI coding agent" — implies parity across the six tools it lists, and there isn't parity. Claude Code gets a first-class integration; everyone else gets the same pattern-matching every other tool in this space already does, with the same failure modes. That's not a knock on the engineering — hooks are a Claude Code feature other agent CLIs simply don't expose yet, and agent-manager can't build an integration that doesn't have an API to build against. But it does mean the honest framing is narrower than the marketing: this is a very good Claude Code fleet manager that also happens to run five other CLIs adequately, not a tool that treats all six identically well. Worth knowing going in, especially if your actual daily driver is one of the five.
One more thing worth flagging for anyone searching around this space: Kilo Code, a separate open-source coding-agent product, ships an unrelated feature it also calls "Agent Manager" (a worktree-based multi-session panel inside its VS Code extension). Different codebase, different company, same generic name — don't confuse the two when you're comparing notes with a teammate.
Should you use it
Adopt it now if you already live in tmux, run two or more coding-agent CLIs regularly, and want a free, local-only, no-cloud-dependency fleet view. The install cost is minutes and the downside is close to zero since it wraps tools you already run.
Wait if you need native Windows support without WSL2, cost/token tracking across your fleet, or a GUI you can hand to less terminal-fluent teammates — Conductor or Nimbalyst are the better fit for that last one today.
Skip it if you run a single agent inside one IDE and have no fleet to manage — there's nothing here for you yet — or if what you actually need is agents that share memory and hand off work to each other, which is a fundamentally different tool category than session management.
Given that Claude Code is the only agent here with a real, hook-based status API and every other CLI vendor still leaves third-party tools guessing from terminal output: should agent CLI vendors treat a stable, documented lifecycle-event API as a baseline feature for their tools, the way LSPs became table stakes for editors — or is that expecting too much coordination from a market where every vendor currently benefits from keeping its own tool as the deepest integration available?
Sources:
Top comments (0)