Tool
Hermes Agent CLI — Terminal Interface, TUI & Slash Commands
Command-line interface for Hermes Agent with TUI, streaming, and slash commands.
Quick answer
The Hermes Agent CLI is the primary way to run Hermes: a full-screen terminal UI with streaming responses, multiline editing, and slash commands. You install it once, point it at a model provider in ~/.hermes/config.yaml, and every other surface (gateway, Web UI, desktop apps) talks to the same agent the CLI runs.
The CLI is the canonical Hermes surface. Everything else — the messaging gateway, Web UI, and community desktop apps — is a front-end over the same agent you drive from the terminal.
Features
- ✓Full TUI
- ✓Multiline editing
- ✓Slash commands
- ✓Streaming
- ✓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
The CLI is where Hermes config lives. Provider keys, the active model, skills, memory, and sessions all resolve from ~/.hermes (config.yaml, .env, auth.json, skills/), so a working CLI is the prerequisite for every gateway or dashboard you add later.
Slash commands run inside the TUI for model switching, session management, and verbosity. When something misbehaves on Telegram or the Web UI, reproduce it in the CLI first — the terminal shows the raw tool calls and errors that channel UIs hide.
Because the CLI streams tool progress and supports multiline editing, it stays the fastest place to write skills and debug provider setup. Once a workflow is stable in the terminal, expose it through the gateway so you can reach it from your phone.
Running the CLI continuously on your own machine means babysitting the terminal session. Teams that want the same agent online 24/7 without keeping a terminal open usually move the workload to a managed host so the CLI session never has to be the uptime guarantee.
Best use cases
FAQ
Yes. The CLI, messaging gateway, and Web UI are all front-ends over the same agent and the same ~/.hermes state. Config, memory, and skills are shared, so a change in one surface shows up in the others.
Yes. Configure a model provider and confirm the agent responds in the CLI first. The gateway reuses that same config, so channel problems are usually provider or config problems that are easier to see in the terminal.
Use the in-TUI slash commands to change the active model for the session. This is the quickest way to compare a cheap model against a premium one on the same prompt before committing in config.yaml.