Frank
d4024a9180
New runbook page serverAppConfigs-docs/LLM/frank-medium-rocmfpx.md records the hardware swap, the self-contained gfx1201 build, the measured layer-vs- tensor decision (llama-bench multi-device syntax gotcha included), the tensor-mode draft abort, served-path numbers, and the post-cleanup host ROCm posture. AGENTS.md, README, docs indexes, Dankserver System Specs, deployment/Hermes/OpenWebUI/Plex/Stack pages follow the rename; freetoken-frank-small is marked RETIRED and kingjones-q8agent SUPERSEDED. Work log entry added.
82 lines
4.5 KiB
Markdown
82 lines
4.5 KiB
Markdown
# Hermes
|
|
|
|
Hermes is the self-improving AI agent from Nous Research. It runs in a terminal, Telegram, Discord, Slack, WhatsApp, or Signal, and keeps a persistent learning loop: it creates skills from experience, searches past conversations, and builds a model of the user across sessions.
|
|
|
|
**Host:** Dankclaw — the gateway itself publishes **no port** (it runs in the
|
|
host network namespace and dials the Signal daemon at `127.0.0.1:8080`); the
|
|
user-facing web surface is [[Hermes-WebUI]] on `:8787`, reached via
|
|
`hermes.franksdank.cloud` — internal-only by DNS absence (no public Porkbun A
|
|
record) — **Docs:** https://hermes-agent.nousresearch.com/docs
|
|
|
|
**Persistent state:** `/home/dank/Containers/hermes/data` on Dankclaw, bind-mounted
|
|
at `/data` in all three Hermes containers (gateway, webui, dashboard). Each
|
|
container additionally gets an anonymous volume at `/opt/data`, which is
|
|
re-created empty on every container recreation — anything that lives only there
|
|
is not durable. The tracked, sanitized configuration baseline is
|
|
[`dankclaw/hermes/config.yaml.example`](../../dankclaw/hermes/config.yaml.example).
|
|
|
|
## Facts (from research, primary source)
|
|
|
|
| Item | Value |
|
|
|------|-------|
|
|
| Image | built from `NousResearch/hermes-agent` (official Dockerfile in repo) |
|
|
| License | MIT |
|
|
| Model backends | Nous Portal, OpenRouter, OpenAI, or any custom endpoint |
|
|
| Interfaces | TUI, Telegram, Discord, Slack, WhatsApp, Signal |
|
|
| Memory | FTS5 session search, Honcho user modeling |
|
|
| Skills | self-created, self-improving during use |
|
|
|
|
## Configuration
|
|
|
|
- Point Hermes at the local model endpoint or an external provider through its provider config.
|
|
- The gateway runs `hermes gateway run --force -v` in the **host** network
|
|
namespace (`Network=host` in its Quadlet unit) and reaches the Signal daemon at
|
|
`http://127.0.0.1:8080`. That loopback hop works only because the gateway is in
|
|
the host netns — see [[Container Network Namespaces]]. The daemon itself is a
|
|
**host** user unit (`signal-cli-daemon.service`), not a container, and binds
|
|
`0.0.0.0:8080`, so the Signal HTTP API is reachable from the whole LAN.
|
|
- The data volume persists skills, memory, and session history.
|
|
- Hermes has two named local providers: `dankclaw-large` reaches
|
|
`http://192.168.0.143:7770/v1` and exposes `frank-large`;
|
|
`dankserver-small` reaches `http://192.168.0.235:7770/v1` and exposes
|
|
`frank-medium` (renamed from `frank-small` on 2026-09-15).
|
|
- The live `config.yaml` contains secrets and user state and is not committed;
|
|
the tracked example is the sanitized backup of its non-secret settings.
|
|
|
|
## Volumes
|
|
|
|
| Container path | Host path (live) | Backing |
|
|
|----------------|------------------|---------|
|
|
| `/data` | `/home/dank/Containers/hermes/data` | bind mount (durable; shared by all three containers) |
|
|
| `/webui` | `/home/dank/Containers/hermes/webui` | bind mount (webui only — the `bootstrap.py` venv lives here) |
|
|
| `/opt/data` | anonymous volume | image `VOLUME`; fresh empty volume per recreation |
|
|
|
|
## Gotchas
|
|
|
|
- Hermes is under active development; pin the image tag for reproducibility.
|
|
- Model choice drives quality; the local `frank-large` (Dankclaw, 7770) is the intended backend.
|
|
- Do not expose the gateway without auth — put it behind [[Caddy]] with basic auth.
|
|
|
|
## Browser automation (Chrome DevTools Protocol daemon)
|
|
|
|
The agent's browser tool is an MCP client (`mcp_tool.py` in the image) that
|
|
spawns `npx -y chrome-devtools-mcp@latest --browserUrl=http://127.0.0.1:9222`
|
|
per session; the browser itself lives in a dedicated daemon container, the
|
|
digest-pinned headless-shell unit `chrome-devtools-protocol.container` (host
|
|
network, loopback-only bind on 127.0.0.1:9222). Both consumers — the Signal
|
|
gateway and the webui server — run in the host network namespace, so they can
|
|
dial the daemon on loopback; nothing on the LAN can reach the CDP endpoint.
|
|
The wiring lives in the live `/data/config.yaml` under `mcp_servers.chrome-devtools`
|
|
(command `npx`, args `-y chrome-devtools-mcp@latest --browserUrl=http://127.0.0.1:9222`).
|
|
The npx package cache lives in the container layer, so a recreation (not just a
|
|
restart) pays one first-call npm download; subsequent calls are cached.
|
|
|
|
## See Also
|
|
|
|
- [[Hermes-Dashboard]] — the LAN browser management UI
|
|
- [[Hermes-WebUI]] — the Hermex server (phone-facing API, SSH-tunneled)
|
|
- [[Dankclaw Stack]]
|
|
- [[OpenWebUI]] — the chat UI that pairs with Hermes
|
|
- Knowledge base: [[SearXNG]] (Hermes as the search agent)
|
|
- [[Container Network Namespaces]] — why the gateway and webui can dial loopback services and the dashboard cannot
|