HyperTeamsHyperTeams vs tmux
tmux is an open-source multiplexer that keeps terminal sessions alive so you can detach and reattach. It is also the most common way to keep an agent per window running. HyperTeams runs the same agents on your computer, but shows their status without flipping through windows, follows you to your phone, runs on a schedule, and lets colleagues assign work.
Why HyperTeams over tmux
tmux doesn't know about agents: it splits terminals and keeps them alive, so finding which window is done and which is waiting for an answer means flipping through them and reading. The HyperTeams control room gives every job a card with status, an answer summary and an unread marker in one list, notifies your phone when a job is done, and starts work on its own at set times. You check and instruct from your phone's home screen, no SSH app needed. When colleagues arrive, tmux can only share a socket so you use the same screen; HyperTeams Connect adds accounts and roles, policy and per-item pre-approval, an audit trail and cost per person. You don't have to drop tmux: keep the sessions you attach to by hand in tmux.
You see it without flipping windows
You find out where things are by flipping through windows and panes and reading them. There is no done marker.
Every job gets a card, with status, an answer summary and an unread marker together in one list.
It follows you to your phone
Away from your desk, you open an SSH app, log in to that computer and attach. Reaching it from outside means opening the network yourself.
Attach an address in the app and it's reachable from outside without router or firewall changes; check progress and add instructions from your phone's home screen. You're notified when it's done.
It starts on its own at a set time
No scheduling. You wire a script to cron and dig through logs to find failures.
Pick a time on screen and it runs then, every day. A failure notifies you.
Colleagues can assign work
People attached to the same socket share the screen. Who can do what comes down to OS accounts and file permissions.
Accounts and roles, policy per folder and command, pre-approval per item, and an audit trail of who approved what.
HyperTeams vs tmux
- tmuxInside a terminal on your computer or a server you SSH into. It knows nothing about agents; it splits and keeps terminals.
- HyperTeams SystemExecution stays on that machine — the control room sits on top rather than taking it over.
- HyperTeams ConnectIt does not touch execution; it receives what the control room reports.
- tmuxOne agent per window or pane. Separating folders and branches is up to you.
- HyperTeams SystemOne card per job — hand it five and five run side by side, in five folders.
- HyperTeams ConnectThe control room does this
- tmuxYou flip through windows and read the screens yourself. No status or summary.
- HyperTeams SystemStatus, a summary of the answer, and an unread marker, all in one list.
- HyperTeams ConnectThe control room does this
- tmuxKeeps running when you detach and picks up when you reattach. Gone after a reboot.
- HyperTeams SystemResident, and it records progress: it continues after you close the window, and a tunnel shows it on your phone.
- HyperTeams ConnectThe control room does this
- tmuxNone. You wire it to cron or similar yourself.
- HyperTeams SystemYou pick a time on screen, and a failure notifies you.
- HyperTeams ConnectThe control room does this
- tmuxThe sessions on that server. For more machines, SSH into each one.
- HyperTeams SystemIt stops at that one machine. It does not know what runs on the next one.
- HyperTeams ConnectA control room per machine, all of them in one list — including which machine is awake.
- tmuxPeople attached to the same socket share the screen. Permissions are OS accounts and file modes.
- HyperTeams SystemIt assumes the owner of the machine. The screen is behind one password.
- HyperTeams ConnectAccounts and roles, policy per folder and command, and pre-approval per item.
- tmuxOnly the scrollback buffer. Keep logs yourself.
- HyperTeams SystemIt keeps that machine's run history. There is no notion of an approval.
- HyperTeams ConnectWho approved what, and when, kept as a policy audit trail.
- tmuxUnknown to tmux; it lands on your agent accounts.
- HyperTeams SystemIt shows cost per job on that machine, with no owner attached.
- HyperTeams ConnectAttributed to a person and a team, with ceilings.
- tmuxOpen source under the ISC license. Free.
- HyperTeams SystemOne command to install, using the Claude or ChatGPT account you already have.
- HyperTeams ConnectOnly the features that cross into a team are metered in credits.
Checked against each product's official documentation as of 2026-09-26. Their products change, and when they do this table becomes wrong — tell us and we will fix it.
tmux docsWhat the control room does, and what Connect does
HyperTeams is two products. Which of them answers each row above is exactly where the boundary sits.
HyperTeams System
Runs the work on your machine
A program you install with one command. It assigns work per folder, runs jobs in parallel, and keeps going after you close the window. While you work alone, this is all you need.
- Where it runs
- Several jobs at once
- How far along it is
- If you close the window
- At a set time
HyperTeams Connect
Makes it something others rely on, unattended
It starts paying the moment there is a second machine and a second person: pooling machines into one list, filtering work others assign through approval, keeping an audit trail of what happened, and splitting cost per person.
- Several machines in one place
- When someone else assigns work
- Retracing it later
- What it cost
When do you move up a rung?
- L1 · Observe
You watch several machines. The moment there is a second one.
- L2 · Share
The team sees what was asked for. The moment you start sharing one password.
- L3 · Delegate
Others assign work and see the results. This is where approval, policy, and audit earn their place.
Running both
You don't remove or migrate what you use today. Here is how to layer HyperTeams on top of it.
- 1
Keep tmux
Don't uninstall it. Keep the sessions you attach to by hand and your server work in tmux.
- 2
Install the control room with one command
Install it on the same computer and register your working folders. Agents keep using the accounts signed in on that computer.
- 3
Split the work
Work you'll sit with stays in tmux windows; work you hand off and scheduled runs go to the control room.
Which one should you pick?
When to just use tmux
Any program, anywhere
Not just agents: editors, servers, logs, anything that runs in a terminal stays up, and it works the same on any server you SSH into.
When you want a light, long-lived tool
One line to install on nearly any Unix-like system, no server, account or browser, and over a decade of polish as free open source.
When you drive it with your keys and scripts
Lay out windows and bind keys however you like, and let scripts type into sessions with send-keys. HyperTeams does not split terminals.
When HyperTeams is the answer
When you hand off and leave
HyperTeams SystemIt keeps running on your computer after you close the window; check progress and add instructions from your phone, and get notified when it's done.
When people new to terminals need to see it
HyperTeams SystemEach job gets a card, with status, answer summary and unread marker in one list. Open results to edit them, with cost per job alongside.
When something runs at the same time daily
HyperTeams SystemNo cron or scripts: pick a time and the control room starts it on its own, and a failure notifies you.
When you bring in colleagues
HyperTeams ConnectThis is where Connect starts: a machine list, accounts and roles, policy and pre-approval, an audit trail, and cost and caps per person and team.
A layer, not a replacement
Put it on top of what you already run
One command to install. Nothing you use today gets removed or moved — you only add the command screen above it.
curl -fsSL https://hyperteams.net/install.sh | bashKeep reading
- HyperTeams vs Claude Code
- HyperTeams vs OpenAI Codex
- HyperTeams vs Gemini CLI
- HyperTeams vs Cline
- HyperTeams vs OpenHands
- HyperTeams vs Conductor
- HyperTeams vs Claude Squad
- HyperTeams vs Vibe Kanban
- HyperTeams vs Orca
- HyperTeams vs Paseo
- HyperTeams vs Cursor
- HyperTeams vs GitHub Copilot
- HyperTeams vs Devin
- HyperTeams vs OpenClaw
- HyperTeams vs Hermes Agent
- HyperTeams vs Manus
- HyperTeams vs Lindy
- HyperTeams vs NotebookLM
- HyperTeams vs n8n
- HyperTeams vs Zapier
- HyperTeams vs Make
Common questions
tmux is an open-source (ISC-licensed) terminal multiplexer that splits one terminal into windows and panes and keeps programs running after you detach. Work survives a dropped SSH connection, which is why it's a common way to keep agents running.
For keeping agents running, yes: the control room stays up, runs jobs and lists their status. But HyperTeams isn't a terminal multiplexer, so splitting out non-agent programs like editors and servers stays tmux's job.
Over SSH you read a raw terminal on a small screen and type keys, and you open the network yourself. HyperTeams is reachable through one address, shows the job list and answer summaries fitted to a phone, and notifies you when a job finishes or waits for an answer.
You can. But you write the scripts, dig through logs to find failures, and have no screen that collects the results. With HyperTeams you just pick a time, each run leaves its result and cost on a card, and failures notify you.
tmux sessions vanish with a reboot and, without plugins, must be started again. The HyperTeams control room records progress, so after restart the list still shows which job got how far.