Hermes Web Dashboard: The Agent Control Plane Has Arrived
The era of managing AI agents through terminal commands and YAML files is ending. With the release of its web dashboard, Hermes — the self-improving AI agent from Nous Research — has crossed a threshold that separates experimental tools from production infrastructure. Run hermes dashboard and your browser opens to a live operations console at http://127.0.0.1:9119. From there, every session, cron job, API key, skill, log line, and configuration field is within reach — without touching a single config file.
This is not a cosmetic feature. It is a signal about where AI agent tooling is heading: from developer-only CLIs to operator-grade control planes.
From CLI to Control Plane: What Changed
Hermes launched as a terminal-first agent: a self-improving loop that creates skills from experience, searches its own conversation history via FTS5, and runs cron-scheduled automations across Telegram, Discord, Slack, and WhatsApp from a single gateway process.
That architecture already separated it from one-shot coding assistants. But the gap between a capable CLI agent and a production-ready system is always the same: observability and operator access. When something goes wrong at 2 AM, you do not want to SSH into a server and grep log files. You want a status page.
The Hermes web dashboard closes that gap. Built on FastAPI (backend) and a Vite/React/TypeScript/Tailwind frontend, it runs entirely on localhost — no data leaves the machine unless you explicitly bind to 0.0.0.0 with the --insecure flag. The default posture is: operator visibility, zero network exposure.
What you get on port 9119:
- Status page — live overview of agent version, gateway state (running/stopped, PID), connected platform statuses, session count (active in the last 5 minutes), and the 20 most recent sessions with model, message count, token usage, and conversation previews. Auto-refreshes every 5 seconds.
- Chat tab — the full Hermes TUI (the same interface as
hermes --tui) embedded in the browser via xterm.js with WebGL rendering. Slash commands, tool-call cards, approval prompts — all work identically because the dashboard runs the real TUI binary and streams ANSI output over a WebSocket backed by a POSIX pseudo-terminal. - Config editor — a form-based interface for all 150+ config fields, auto-discovered from
DEFAULT_CONFIG. Model, terminal backend (local/docker/SSH/Modal/Daytona), approval modes (ask/yolo/deny), memory provider, delegation limits — organized into tabs with dropdowns for known-valid values. - API Keys manager — manage the
.envfile from the browser. Keys are grouped by category (LLM providers, tool APIs, messaging platform tokens, agent settings), with redacted previews, provider signup links, and a delete action per key. - Sessions browser — searchable (FTS5, full-text across all message content), expandable session history with role-color-coded messages, collapsible tool-call blocks, and a resume button that opens the session in the Chat tab with
--resume. - Logs viewer — filter by file (agent, errors, gateway), level (DEBUG/INFO/WARNING/ERROR), and component (gateway, agent, tools, cli, cron). Live tail every 5 seconds.
This is what a production agent control plane looks like. Not a chat widget — an operations dashboard.
Why CLIs Hit a Ceiling for Long-Running Agents
Single-session coding assistants like Claude Code and Codex are optimized for one context: a developer at a terminal solving a specific problem. They are excellent at that job. But Hermes is built for a different use case: an agent that runs unattended, executes scheduled work, manages cross-platform conversations, and self-improves between sessions.
That design forces a different set of requirements:
Cron visibility. When a scheduled task fails at midnight, you need to know. The dashboard's Cron page lists every scheduled job, its last-run time, output, and next trigger — without opening a cron file.
Credential governance. A long-running agent accumulates API keys: model providers, tool integrations, messaging tokens. The API Keys page surfaces all of them in one place, with redacted previews and per-key delete actions. No more hunting through .env files.
Session archaeology. An agent that converses across Telegram, Discord, and CLI generates session history that is practically unsearchable in a flat file. The Sessions browser makes that history queryable and resumable.
Approval-mode management. The Config page includes approval-mode settings (ask, yolo, deny) that govern whether the agent executes dangerous commands autonomously or requests human confirmation. That is a governance decision, not a developer preference — and it belongs in a UI that non-developers can audit.
The dashboard does not make Hermes safer or more capable by itself. It makes the agent's behavior visible and governable, which is the prerequisite for trusting long-running automation.
The Three Patterns for Agentic Operations
Hermes is not the only project thinking about this layer. In 2026, three distinct patterns have emerged for managing AI agents at scale:
1. Hosted control planes (Claude Code, Codex) Anthropic and OpenAI offer managed interfaces — Claude Code's desktop application, Codex's workspace UI — that abstract away infrastructure entirely. Sessions are managed server-side, billing is consumption-based, and you interact through the provider's UI or API. The tradeoff: zero operational overhead, but opaque governance and vendor dependency.
2. Spec-driven orchestration (OpenAI Symphony) OpenAI's Apache-licensed Symphony specification turns issue trackers into long-running Codex work queues. It defines the orchestration layer — state machines, approval gates, isolated workspaces, token accounting — but leaves the control plane to the implementer. The spec is powerful; the operations UI is your problem. The Peter Steinberger move to OpenAI hints at how seriously the company is taking this layer.
3. Self-hosted agent dashboards (Hermes) Hermes gives you the agent runtime and the operations UI in a single install. You own the infrastructure, the logs, the credentials, and the session history. The dashboard runs on localhost by default. You decide what runs, when, and with what permissions.
None of these is universally correct. But for teams handling sensitive data, operating in regulated environments, or running high-frequency background automations, self-hosted control is not optional — it is a compliance requirement.
Context Studios builds on self-hosted agentic infrastructure for exactly this reason: when agent actions touch production systems or client data, you need a complete audit trail that you own. If you are evaluating self-hosted agents for a team workflow, our AI agents practice is a starting point for governance and integration design.
Enterprise Checklist: Before You Let a Dashboard Steer Agents
A web dashboard for your agent is a new attack surface. Before deploying Hermes in any multi-user or production context, validate these controls:
| Control | Hermes Implementation | Your Action |
|---|---|---|
| Network exposure | Localhost-only by default (127.0.0.1:9119) | Confirm --host is never set to 0.0.0.0 in production |
| Path traversal protection | Path-traversal guard in backend | Review if you extend the API |
| Credential storage | .env file on disk, not in-memory secrets manager | Rotate API keys on personnel changes |
| Approval mode | ask/yolo/deny per-command | Set deny for dangerous commands in team environments |
| Session export | Available in UI | Establish retention and deletion policy |
| Audit logs | Gateway + agent + error log files, filterable | Route to centralized log management (e.g., Datadog, Loki) |
| TUI access control | Dashboard session token; no multi-user auth yet | Do not expose to untrusted networks |
The critical gap in the current release: the dashboard has no multi-user authentication. It is authenticated by a single session token, appropriate for a single operator on localhost. Teams sharing a server will need to add a reverse proxy with auth (nginx + htpasswd, Tailscale, or a VPN) before the dashboard is multi-user safe.
Evaluating Hermes Against Claude Code and Codex — Without Star Count Theater
GitHub stars are a developer attention metric, not a production readiness signal. The coding agent space has enough star inflation from viral launches to make raw counts meaningless as a selection criterion. What matters operationally:
Hermes:
- Self-hosted, multi-platform gateway (Telegram, Discord, Slack, WhatsApp, Signal)
- Built-in cron scheduling, skills system, FTS5 memory
- Web dashboard for operator visibility (no cloud dependency)
- Model-agnostic (OpenRouter, Anthropic, OpenAI, NVIDIA NIM, local endpoints)
- Best for: teams running unattended automations, sensitive data environments, multi-platform agent workflows
Claude Code:
- Deep Anthropic/Claude integration, strong code editing performance
- Managed by Anthropic's infrastructure
- Best for: individual developers, Claude-native workflows, teams comfortable with vendor management
Codex:
- OpenAI-native, strong PR generation via the Symphony orchestration spec
- Hosted workspace UI, no self-hosting
- Best for: GitHub-native teams, Linear integration workflows, teams testing Symphony
The right answer depends on your governance model. If your agents touch production data or execute scheduled work unattended, you need operator visibility. As of May 2026, Hermes is the only open-source agent in this tier that ships that visibility out of the box.
A 30-Day Adoption Playbook
If you are evaluating Hermes for production use, here is a staged path that avoids giving agents production autonomy before you have verified their behavior:
Week 1 — Local install, single user, ask mode
Install Hermes with curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash, then pip install 'hermes-agent[web,pty]'. Set approval mode to ask for all dangerous commands. Run hermes dashboard and explore the Status, Config, and Sessions pages. Do not connect any production API keys yet.
Week 2 — Gateway + cron, localhost dashboard Enable the messaging gateway for one platform (Telegram or Slack). Create 2-3 cron-scheduled automations for non-critical tasks (daily summaries, status reports). Monitor execution via the dashboard's Logs and Cron pages.
Week 3 — API key audit + session review Review all keys in the API Keys page. Delete anything not actively used. Read through session histories in the Sessions browser to verify the agent is making expected decisions. Check the Config page for approval mode settings.
Week 4 — Team access decision If multiple operators need dashboard access, add a reverse proxy with authentication before week 4 deployment. Document your approval-mode policy. Establish a log retention schedule.
This playbook keeps the risk surface manageable while giving you a real-world picture of the agent's behavior before it runs autonomously.
FAQ
What is the Hermes web dashboard?
The Hermes web dashboard is a browser-based control plane for the Hermes AI agent, launched with hermes dashboard. It runs on localhost (port 9119 by default) and provides a UI for monitoring sessions, managing API keys, editing configuration, viewing logs, managing scheduled tasks, and running the Hermes TUI in the browser — without touching the terminal or config files.
Is the Hermes dashboard secure by default?
Yes, with caveats. By default it binds to 127.0.0.1, so it is only accessible from the local machine — no data leaves localhost. The --insecure flag allows binding to 0.0.0.0, which exposes it on the network and should never be used without a firewall and reverse proxy with authentication. The current release has no multi-user auth system, so shared-server deployments need additional access controls.
How does Hermes compare to Claude Code for enterprise use?
Hermes and Claude Code serve different use cases. Claude Code is optimized for individual developers doing interactive coding with Anthropic's managed infrastructure. Hermes is designed for unattended, long-running automations across multiple messaging platforms, with a self-hosted web dashboard for operator visibility. Teams in regulated environments or handling sensitive data typically prefer self-hosted agents where they control the infrastructure, logs, and credentials.
Does the Hermes dashboard require separate installation?
Yes. The web dashboard is an optional extra — pip install 'hermes-agent[web,pty]' — not included in the default install. The web extra adds FastAPI and Uvicorn. The pty extra adds pseudo-terminal support for the in-browser Chat tab. pip install 'hermes-agent[all]' covers both along with messaging and voice dependencies.
Can the dashboard manage cron schedules?
Yes. The Hermes dashboard includes a Cron page for viewing scheduled tasks, their last-run output, timing, and next trigger. Cron jobs can be created and managed through the dashboard interface, and Hermes's built-in scheduler supports delivery of results to any connected messaging platform (Telegram, Discord, Slack, WhatsApp, Signal).
What is a "control plane" for AI agents?
An AI agent control plane is the operations layer that sits above the agent's core reasoning loop — it handles scheduling, observability, credential management, session history, approval workflows, and configuration governance. Without a control plane, operators must manage agents through terminal commands and log files, which does not scale to teams or production environments. The Hermes dashboard is one example of an emerging control plane pattern for self-hosted agents.