Tool
Hermes TUI: Terminal Dashboard for Agent Sessions, Memory, and Long-Running Work
Use Hermes TUI/terminal monitoring when you want a private SSH-friendly dashboard for sessions, memory, tasks, logs, and long-running agent health without exposing the Web UI.
Quick answer
Hermes TUI means the terminal-first control surface around Hermes Agent: the interactive CLI, terminal session views, and companion monitoring for sessions, memory, tasks, and long-running work. Use it when you are on SSH, a VPS, or a private server and do not want to expose a browser dashboard. Use the Hermes Web UI when you need a browser admin panel, and use FlyHermes when you want hosted browser/mobile chat, connected channels, and managed uptime instead of owning the server and provider stack.
Search and support demand around `hermes tui` is usually practical: people want to know how to watch a terminal-first Hermes session, keep long-running work alive, and decide whether they need the browser dashboard. Community support threads point to the same operator pains: copy/paste in terminal UIs, markdown readability, gateway diagnostics, provider failures, and server operation. This page answers one intent: what Hermes TUI is, when terminal visibility is better than Web UI, how to operate it safely, and when to choose FlyHermes instead.
Setup steps
- 1Start with a healthy CLI run: `hermes doctor` and one small `hermes chat -q` smoke test before blaming the terminal UI.
- 2Use the normal Hermes CLI/TUI for interactive work and keep tmux available when you run long agent sessions over SSH.
- 3Open a companion terminal monitor only after you know which Hermes profile, working directory, and session you are watching.
- 4For a stuck scheduled job, inspect terminal output, the dashboard logs, and `hermes cron list` before editing the cron prompt.
- 5For a silent Telegram or Discord bot, use terminal checks for provider credits, gateway process health, and logs, then prove one real reply in the target channel.
- 6If teammates need a browser surface instead of SSH, move to the self-hosted Web UI; if they need mobile/channel access without owning uptime, choose FlyHermes.
Command map
hermes doctor && hermes chat -q "reply ok"Baseline check before debugging any TUI, dashboard, gateway, or provider issue.
If this fails, the problem is provider/config/runtime health, not the terminal dashboard.
tmux new-session -d -s hermes "hermes"Run an interactive Hermes session that can survive SSH disconnects and be inspected later.
Keep session names project-specific so handoffs do not mix work across repos.
tmux capture-pane -t hermes -p | tail -80Review recent terminal output from a long-running agent before deciding whether it is stuck or still working.
Do not treat a captured pane as verification; still run tests, check files, or inspect the live URL.
hermes dashboard --no-open --port 9120Switch from terminal visibility to the browser Web UI when you need config, logs, cron, skills, memory, or gateway panels.
Keep the dashboard private behind localhost, SSH tunnel, VPN, or hardened auth.
hermes gateway status && tail -120 ~/.hermes/logs/agent.logUse terminal diagnostics when Telegram/Discord appears online but a real reply is missing.
The final proof is a message in the exact chat, topic, or thread, not only a healthy-looking status line.
Self-hosted Web UI or FlyHermes?
Use Hermes TUI / terminal monitoring
You operate Hermes over SSH, tmux, launchd, Docker, or a VPS and want private visibility into sessions, provider errors, memory growth, and long-running jobs without exposing a web port.
Avoid when: Non-technical teammates need browser/mobile access or channel reliability without logging into the server.
Use the self-hosted Web UI
You want a browser admin panel for profiles, memory, skills, tools, cron jobs, sessions, logs, gateway health, and local browser Chat boundaries.
Avoid when: You are not ready to secure an admin surface with localhost, VPN, SSH tunnel, HTTPS, auth, and firewall rules.
Use FlyHermes
The business outcome is hosted browser/mobile chat, connected channels, bundled provider operations, uptime, and less VPS/Docker/gateway maintenance.
Avoid when: You specifically need to own the runtime, secrets, network, and server surface yourself.
What you can verify
Features
- ✓Terminal-first visibility for Hermes sessions, active tasks, memory growth, and long-running work
- ✓SSH-friendly monitoring for VPS, Docker, launchd, tmux, or headless server operation
- ✓Clear boundary between Hermes CLI/TUI, community monitoring companions, self-hosted Web UI, and FlyHermes hosted cloud
- ✓Operational checklist for provider failures, stuck jobs, cron runs, and gateway health before changing tokens or permissions
- ✓Useful fallback when a browser dashboard should stay private or an SSH tunnel is not available
- ✓Pairs with `hermes dashboard` for browser admin and `hermes gateway status` for channel delivery checks
- ✓Supports multi-session operating patterns where separate agents, worktrees, or tmux panes need visible handoffs
- ✓Commercial decision path: self-host terminal/Web UI if you want control; use FlyHermes if uptime, mobile access, and channels matter more than server maintenance
- ✓Use the Hermes dashboard profile/provider view as a checkpoint before blaming Telegram, Discord, cron, or Docker for a provider/runtime problem.
Why this tool matters
Searchers typing `hermes tui` are usually trying to understand the terminal surface: how to watch Hermes, how to keep sessions alive, and whether they need a browser dashboard at all. The useful answer is not “TUI versus Web UI” as a feature fight. It is where the operator should look for evidence while an agent is doing real work.
Use the terminal-first path when you are already on the server. SSH plus tmux is often the safest surface for long-running sessions because it avoids exposing an admin web port, keeps logs close to the process, and makes it obvious which working directory and profile the agent is using.
Use the Web UI when the question is broader than one pane of terminal output: active profile, model/provider settings, enabled tools, memory, skills, cron jobs, logs, sessions, and gateway health. The Web UI is a self-hosted admin dashboard, so it still needs private access controls.
Use FlyHermes when the desired outcome is not “I want to babysit a server better.” If the team needs browser/mobile access, Telegram or Discord uptime, provider operations, and dashboards without owning Docker, VPS ports, launchd, cron, and gateway restarts, FlyHermes is the commercial path.
The practical operating rule is simple: terminal/TUI tells you what the local agent process is doing; Web UI shows the local control plane; FlyHermes removes the self-hosted control-plane burden. Pick the surface based on the job, not on which UI looks newest.
Best use cases
How this fits with Hermes Agent
Terminal-first server workflow
Run Hermes inside tmux, keep the active profile obvious, capture the pane for handoffs, and verify work with tests or live URLs before ending the session.
Gateway debugging workflow
Use terminal status and logs to separate bot delivery, provider health, rate limits, and permissions before rotating Discord or Telegram tokens.
TUI to Web UI escalation
If terminal output cannot answer a profile, cron, memory, skill, or gateway-state question, open the self-hosted Web UI privately and inspect the broader control plane.
Self-hosted to managed decision
When monitoring becomes the work — provider credits, restarts, uptime, mobile access, channels, and dashboard security — compare FlyHermes instead of adding more server tooling.
Related Hermes Agent guides
Hermes dashboard / Web UI
Use the browser admin panel when terminal output is not enough.
How to use Hermes Web UI safely
Commands, ports, SSH/VPS access, browser Chat boundary, and dashboard security.
AI agent session handoff checklist
Capture goal, changed files, verification, assumptions, blockers, and next action before a fresh session continues.
Hermes gateway troubleshooting
Diagnose silent Telegram/Discord bots, provider failures, and stale gateway state.
FlyHermes pricing
Use managed cloud when dashboard access and uptime matter more than owning the server.
FAQ
Hermes TUI refers to the terminal-first interface and terminal monitoring pattern around Hermes Agent: the interactive CLI, tmux/SSH sessions, and companion views for sessions, memory, tasks, and logs.
Use terminal/TUI when you are operating directly over SSH or want private process visibility. Use Web UI when you need a browser admin panel for profiles, memory, skills, cron jobs, sessions, logs, and gateway health.
No. Terminal monitoring is excellent for process visibility, but the dashboard is better for profile, config, cron, skills, memory, logs, and gateway panels. They complement each other.
Run Hermes inside tmux or another terminal multiplexer, name the session after the project, and capture recent output before handing off work or disconnecting.
Use FlyHermes when you want hosted browser/mobile access, connected Telegram or Discord channels, bundled provider operations, and managed uptime instead of maintaining a VPS, dashboard, terminal sessions, and gateway restarts.