Subtopic 2.4 is the Hermes web dashboard — the live browser UI that, in the channel's words, is the "biggest quality-of-life feature for everyday users." One video anchors this subtopic (GfQEdMZ9LlA, 13,814 views — the highest-viewed Dashboard video), and the source material is unusually dense: the dashboard is not just a viewer, it replaces the terminal for nearly every config, cron, and debug task the channel has been doing by hand on OpenClaw.

The framing the creator uses is sharp: "you can see everything that's going on inside your Hermes agent without ever having to go into terminal, without ever having to edit config files." The honest admission that follows is just as sharp: most of the creator's existing 183 sessions are literally hi yo, hi Loki, are you there — the creator had been drifting to "claw code" precisely because the terminal-only flow became a headache. The dashboard is what flips the workflow back.

The load-bearing detail — the §2.4 anchor — is the cron jobs tab, which the channel calls the single most-used surface. You give a job a name, a per-run prompt, a schedule (e.g. 09 = 9:00 a.m.), and a delivery channel (local, Discord, Telegram, or email). The creator explicitly says this is the feature that pulls them off Claude Code. If you take one thing from this article, take that.

What you'll learn

  • The dashboard is a live web UI on port 9119 that you launch with a single hermes dashboard command. On a local install you click the link; on a VPS you SSH-tunnel it with ssh -L 9119:localhost:9119 <vps-ip> or the page just returns site can't be reached.
  • The sessions tab merges chat history with system messages, so scheduled cron deliveries, command invocations, and notifications all stream into one searchable log — not three separate ones.
  • The cron jobs tab is the most-used surface in the dashboard. You give a job a name, a per-run prompt, a schedule, and a delivery channel (local, Discord, Telegram, email). The creator explicitly says this is the feature that pulls them off Claude Code. This is the §2.4 anchor.
  • analytics exposes API call count and token usage over 7 or 90 days, with a per-model breakdown that surfaces which mid-session model switch burned the most tokens. log session is where failed cron jobs (e.g. Discord API failures) live — you copy the failure text back into Hermes or Claude Code and ask for the fix.
  • config exposes fallback providers, the default 1,800-second gateway timeout, smart model routing (off by default), and a display field that functions as a mini SOUL.md (the creator's agent ships with a kawaii personality). skills shows categorised native tool sets — cloud code, codeex, dev ops, GitHub, MCP inference, and per-agent ones like Loki resource recovery for Stark's sub-agent work.

1. Setup in two commands — and why you tunnel the port on VPS

The full archive guide is 27-hermes-dashboard-setup.md; the channel's own walkthrough is in GfQEdMZ9LlA. Both agree on the launch and the SSH-tunnel pattern.

Hermes Agent Dashboard (Setup Guide and Overview) (13,814 views) opens with a one-line install. From the terminal:

hermes dashboard

The web UI builds in roughly a minute, and the dashboard exposes itself at http://localhost:9119. On a local install, clicking the link is enough. On a VPS, clicking the link returns site can't be reached because the port is bound to the VPS, not your laptop. The fix is the standard SSH-local-forward pattern:

ssh -L 9119:localhost:9119 <vps-ip>

The creator demonstrates this against Stark, the fleet-commander host. Once the tunnel is up, hitting the 9119 link from the laptop browser lands you on the dashboard.

The auth caveat. The source video is explicit: the dashboard has no auth in the local-only tunnel case, and exposing it without auth is risky. The creator's rule — "never show this to the public" — is the entire reason the SSH-tunnel is the right pattern, not an optional hardening. A raw http://<vps-ip>:9119 on the open internet is a bad idea. For multi-user / team use, the v0.16 release's "system tab" is the first place to look — it exposes the Hermes server, messaging channels, MCP catalogs, credentials, webhooks, and memory settings, and was described by the host as "a very big deal" because routine admin leaves the config files and lives in the browser.

NOTE: the 9119 port number is quoted from the source video. If you are following a current build, double-check the port in hermes dashboard output — the dashboard prints the actual URL on launch, so trust the live output over the static number in this article.

2. Sessions — one log for chat and system messages

The sessions tab is more useful than it sounds. The point is structural: in OpenClaw and most agent harnesses, your chat history and your system messages — scheduled cron deliveries, command invocations, agent-to-agent notifications — live in separate surfaces. The Hermes dashboard merges them.

The creator's instance shows 183 sessions. Most of them, the creator admits, are hi yo, hi Loki, are you there — a tell that the agent was being treated as a quick terminal check rather than a tool, which is exactly the workflow friction the dashboard is fixing.

Two practical wins:

  • Backtracking. When something went wrong two days ago, you scroll the session list, click in, and read the actual command invocation or cron delivery line. No more greping through ~/.hermes/logs/.
  • System messages surface as first-class entries. A running as a scheduled cron job line is right there in the session timeline, not buried in a separate log directory.

The creator's own framing: this is "a very nice interface for you to go through" — i.e. the reason to stop living in the terminal for daily use.

3. Cron jobs — the §2.4 anchor (the most-used tab)

The cron jobs tab is the single most-used surface in the dashboard, and the explicit reason the creator is migrating off Claude Code for daily use. The previous workflow was to chat with the agent about cron syntax and then "go directly in command line to set the cron." The dashboard collapses that into four fields:

  1. Name. Human-readable. Pick something you'll recognise in the sessions list a month from now.
  2. Per-run prompt. What the agent should do each run — the same prompt the parent would otherwise write inline.
  3. Schedule. Numeric hour (the source video shows 09 for 9:00 a.m.). Granularity is whatever the underlying cron supports; the dashboard does not replace cron, it wraps it. The archive guide example uses standard cron syntax: 0 9 * * * for 9:00 a.m. daily.
  4. Delivery channel. local, Discord, Telegram, or email. This is the field that closes the loop with the §2.5 Skill Bundles story and the §2.3 cron+Kanban pipeline.

The creator's framing on the email option is direct: "if you have newsletters and such, this is a really helpful feature that I would personally be using." That is the channel's typical use case — automated briefings delivered to a Discord channel or to email, with the prompt and schedule editable from the browser.

A worked example from the archive guide. Daily AI & Crypto Briefing:

  1. Go to Cron Jobs → New Cron Job.
  2. Name: "Daily AI & Crypto Briefing".
  3. Schedule: 0 8 * * * (8:00 a.m. daily).
  4. Delivery: Discord or Email.
  5. Task: "Research latest AI and crypto news, create summary with key takeaways".

That single job, with zero terminal interaction, is the entire on-ramp to the channel's daily-briefing workflow.

Cross-reference to §2.3. The dashboard's cron tab and the Kanban's cron-pairing video are different surfaces that often get conflated. The dashboard wraps the parent cron job; the Kanban wraps the child tasks that the parent dispatches. If you want a daily AI-news briefing delivered to Discord, set the cron in the dashboard. If you want that briefing to fan out into 9 parallel search workers, set the cron in the agent and let the Kanban dispatch — that is the §2.3 / §2.5 pattern, not the §2.4 one.

Cross-reference to §2.5. When a cron prompt needs the same three skills every time, the right move is a Skill Bundle (§2.5.1). The dashboard's cron tab and Skill Bundles are complementary: the cron decides when to fire, the bundle decides which skills to pin.

4. Analytics and log session — debug surfaces

Two tabs are pure ops utility, and they are what close the loop on the §2.3 cron+Kanban gotchas.

analytics shows API call count and token usage over 7 days or 90 days (the archive guide also lists a 30 days view). The feature that justifies the tab is the per-model breakdown — when you switch models mid-session, the per-model split surfaces which one burned the most tokens. The creator flags this as the move for "being resourceful with your tokens." If your bill jumped on a given day, the per-model view is the first place to look. The archive guide's framing: "Monitor costs and identify which days or models consume the most tokens."

log session is the debug surface for failed runs. The source video shows Discord API failures from cron jobs landing in log session — the agent's scheduled post didn't go out, and the reason (a Discord API error) is captured as a log entry. The workflow is: copy the failure text, paste it back into Hermes or Claude Code, ask "why is this happening and can you fix it?" That is the canonical loop the dashboard enables: an in-browser debug surface that hands off to a terminal-style fix-it conversation.

Why this matters for §2.3's task-accumulation problem. The §2.3 cron+Kanban video called out that the dashboard lets you block tasks but not delete them, and after a week the creator had 7 parents and 63 children. log session is the place to look first when one of those orphan children misbehaves — the per-task log is the audit trail that tells you whether a child is actually stuck or just slow.

5. Skills, config, and memory — config without the terminal

The remaining tabs are the config-and-observability layer. The source video walks them in this order:

The dashboard's per-model token breakdown, in detail. The §2.4 analytics tab's per-model breakdown is the load-bearing feature for cost control. The breakdown shows:

  • Total API calls per model. A bar chart of MiniMax M2.7 vs DeepSeek V4 Flash vs GLM 5.1 etc. The user sees at a glance which model is being used most heavily.
  • Total tokens per model. A stacked bar chart of input tokens + output tokens per model. The user sees which model is the biggest contributor to the bill.
  • Per-session model usage. A line chart of which model was used for each session. The user sees when a model switch happened and how much it cost.
  • Per-cron-job model usage. A stacked bar chart of which model was used for each cron delivery. The user sees which cron jobs are the most expensive.

The breakdown is the surface for the §2.9 model tier list. The user can verify that the orchestrator role is using GPT 5.4, the executor role is using GLM 5.1, and the cron deliveries are using MiniMax M2.7. If the breakdown shows a different model taking the lead, the user can adjust the routing.

The dashboard's gateway timeout, in detail. The §2.4 config tab's Gateway timeout field defaults to 1,800 seconds. The gateway timeout is the maximum time the gateway will wait for a tool call to return. If a tool call hits the timeout, the gateway cancels the call and reports a failure to the agent. The agent's LLM-loop then has to decide what to do with the failure (retry, fall back, give up). The default of 1,800 seconds is the right value for most workflows; bump it if the agent is silently failing on long-running tool calls (e.g. a Kanban parent task that takes 45 minutes). Bump it to 3,600 or higher for long-running cron jobs.

The dashboard's smart model routing, in detail. The §2.4 config tab's Smart model routing toggle is off by default. When enabled, the agent's gateway routes each request to the best model for the request type (e.g. a coding request goes to a coding-tuned model; a research request goes to a research-tuned model). The cost: the routing decision itself costs a small amount of tokens. The benefit: the user gets the right model for each request without manual switching. The source video flags this as a "much smarter output" toggle but does not quantify the cost. Test on a non-critical workload first.

The dashboard's display field, in detail. The §2.4 config tab's display field is a mini SOUL.md. The creator's agent ships with a kawaii personality — a leftover from the OpenClaw migration. The display field is what the agent uses for its chat surface's avatar, name, and tone. The full persona lives elsewhere (the source video does not name the path — verify in the docs). For users who do not need a persona, the display field can be left at the default. For users who want a custom persona, the display field is the first place to edit.

The dashboard's memory tab, in detail. The §2.4 memory tab shows a peer-card profile of the user. The peer-card is a structured representation of what the agent knows about the user: name, role, preferences, recent context. The dashboard's built-in memory overlaps with the standalone Honcho memory integration. The source video's framing: if the dashboard's built-in memory is already doing the peer-card work, the standalone Honcho integration may not be required for simple cases. Verify on the current build before removing Honcho from your stack.

skills is a categorised list of the native tool sets the agent has. The creator's instance shows cloud code, codeex, creative, data science, dev ops, email, gaming, GitHub, inference (MCP), note taking (Obsidian), plus per-agent entries — for Stark, that includes Loki resource recovery (Stark's job is to fix Loki when Loki misbehaves). The archive guide's full list: General, Autonomous AI Agents, Creative, Data Science, DevOps, Email, Gaming, GitHub, Inference, MCP, Note-taking (Obsidian). Tool sets under that — web search and scraping, browser automation, terminal and processes, text to speech, vision and image analysis, clarifying questions — are what show up in the agent's stream-of-action log.

The full skills taxonomy, in detail. Each skill category is a logical grouping; the agent's invocation can span categories. The channel's recommended category-to-skill mapping:

  • General — utility skills that don't fit a category: clarifying questions, markdown-format, summarize-text, translate-text. These are the most-used skills on a typical day.
  • Autonomous AI Agents — multi-agent primitives: kanban-dispatch, kanban-monitor, sub-agent-spawn, verifier. Cross-reference §2.3.
  • Creative — content creation: image-generation, video-generation (Hailuo via Mavis), presentation-maker, thumbnail-generator. Cross-reference §2.5.2's YouTube pipeline.
  • Data Science — data manipulation: data-pivot, csv-export, chart-render, pandas-wrapper.
  • DevOps — infrastructure: cron-create, service-restart, log-tail, docker-exec.
  • Email — Gmail / Outlook integration: email-send, email-read, email-summarize.
  • Gaming — game-specific: chess-engine, sudoku-solver, game-screenshot-analysis.
  • GitHub — repository operations: github-pr-review, github-pr-workflow, github-issue-create, tdd.
  • Inference — MCP inference primitives: model-route, fallback-provider, rate-limit-check.
  • MCP — MCP tool registration: mcp-server-register, mcp-tool-call, mcp-catalog-browse.
  • Note-taking (Obsidian) — Obsidian vault integration: obsidian-write, obsidian-search, obsidian-link.

The full list of bundled skills is much longer — the channel's documentation references "the 19,000-entry skills catalog" in the v0.15 source video, restored by the v0.15 hot fix. The categories above are the top-level groupings.

The dog food skill — leave it alone. The source video flags a dog food entry under general and notes it is part of the native skill set. The name is a placeholder for the channel's internal QA / test skill; the agent may invoke it for self-testing. Leave it alone. Don't delete it, don't disable it. It is part of the native skill set, and the Curator does not touch native skills.

The clarifying questions entry is the underrated one. The creator flags that the equivalent of Claude Code's plan mode — where the model asks you clarifying questions before acting — is something they have not seen Hermes do by default, and they want it. If the dashboard exposes it as a first-class tool set, the next step is wiring it into the chat surface.

config is the in-browser replacement for editing the YAML. The fields worth knowing:

  • Fallback providers. A second API key the agent swaps in when the primary hits a limit. The source video shows MiniMax 2.7 configured as a fallback for a cloud plan that has hit its cap. This is the answer to the "Anthropic didn't tell me I was out of credits" problem from §2.1.
  • Gateway timeout. Default is 1,800 seconds (the creator notes they may have configured this; the dashboard makes it visible). Bump it if the agent is silently failing on long-running tool calls.
  • Smart model routing. Off by default. Enable for "a much smarter output" — but the creator does not quantify the cost, so treat it as a feature flag to test, not a free win.
  • Display. A mini SOUL.md. The creator's agent ships with a kawaii personality — a leftover from the OpenClaw migration.

memory shows a peer-card profile of the user. The creator notes that this overlaps with what Honcho memory does separately — and flags that if the dashboard's built-in memory is already doing the peer-card work, the standalone Honcho integration may not be required for simple cases. Worth re-verifying on the current build before removing Honcho from your stack.

auxiliary is the sub-agent spawn config. Repeated fields for provider, model, base_url, api_key, and timeout let you wire each spawned sub-agent to a different model and key. This is the place to customise sub-agent routing without editing the YAML by hand.

6. The v0.16 system tab — admin moves into the browser

The v0.16 "Surface Release" expanded the dashboard with a dedicated system tab that the host called "a very big deal." The full list of what the system tab surfaces (from the v0.16 source video's summary_content):

  • Hermes server status and settings.
  • Messaging channels (Discord, Telegram, Slack, Microsoft Teams).
  • MCP catalogs (the tool registry Hermes exposes to other clients; cross-reference §2.8 MCP server mode).
  • Credentials (the v0.070 credential pool — see §2.8).
  • Webhooks.
  • Memory settings (the dashboard's built-in memory, Honcho integration).

The framing the source video uses: routine admin leaves the config files and lives in the browser. That is the right mental model — the dashboard is no longer just a viewer, it is the admin surface. Combined with the v0.16 undo command (rollback the last several user turns) and the model picker with fuzzy search (V4 FL finds Deepseek V4 Flash), the dashboard is the place where the platform's day-to-day control surfaces converge.

7. The v0.15 velocity improvements visible in the dashboard

Three velocity improvements from the v0.15 Velocity Release (cross-reference §2.8 Part D) are visible in the dashboard's day-to-day use. None of them is the headline "kanban swarm" feature, but they are the reason the dashboard feels faster in v0.15+ than it did in v0.14 and earlier.

  • hermes --version from 700ms to 258ms — visible every time you launch the dashboard. The CLI startup that used to take most of a second is now under 300ms. For users who cycle between the dashboard and the TUI multiple times a day, this is a real quality-of-life improvement.
  • Per-turn framework overhead from 399,000 to 213,000 function calls — invisible to most users, but the dashboard's chat surface feels snappier as a result. The "fewer hangs on simple tasks" framing from the source video is the user-visible effect.
  • Session search from ~90s to 20ms (~4,500× faster) — visible in the dashboard's sessions tab. The session list was previously computed by an auxiliary LLM, and that LLM round-trip made session search the slowest operation in the dashboard. v0.15 removed the LLM and made session search effectively free. For users with hundreds of sessions, this is the single biggest quality-of-life improvement in the v0.15 cycle.

Why this matters in §2.4. The dashboard is the surface where the velocity work shows up. If you are on v0.14 or earlier, the sessions tab is slow enough that you may avoid it. v0.15 makes it the first tab you open every morning.

8. The Dashboard's place in the day-to-day workflow

The §2.4 subtopic closes with the workflow question. The dashboard is not a viewer — it is the place where the day-to-day admin happens. The channel's recommended daily flow (from the §2.2.3 "Desktop App vs TUI" framing, applied to the Dashboard):

  1. Open the Dashboard first thing in the morning. Scan the sessions tab for the overnight state. Note any failed cron deliveries in log session. Read the LLM final summary from the previous Curator run (§2.7).
  2. Open the cron jobs tab. Verify the day's cron jobs are scheduled. If a job's per-run prompt has drifted, edit it in the browser. If a delivery channel needs to be changed (e.g. a Discord channel moved), update it here.
  3. Open the analytics tab. Check the 7-day or 90-day token usage. If a day spiked, drill into the per-model breakdown to see which model switch burned the most tokens. Adjust the orchestrator/executor split (§2.9) for the next run.
  4. Open the skills tab. Verify the active skill set matches what the day's workflows need. Cross-reference §2.5 — if a workflow's skill set is fixed, convert it to a Skill Bundle and pin it.
  5. Open the config tab only when something is wrong. The config tab is not a daily surface; it is the "smart model routing toggle is wrong" surface. Most days, you do not need to touch it.
  6. Open the memory tab only when a profile drift is suspected. Most days, the agent's memory is doing its job in the background.

That six-step flow is the dashboard's day-to-day value. The cron tab is the most-used surface (§2.4 anchor); the sessions tab is the audit surface; the analytics tab is the cost-control surface. The other tabs are situational.

9. The Dashboard's relationship to the Kanban (§2.3) and the Curator (§2.7)

The Dashboard, the Kanban, and the Curator are three surfaces of the same operational layer. They are not independent — they are the dashboard-cron-kanban-curator stack. The relationships:

  • Dashboard cron → Kanban parent task. The §2.4 cron tab sets a parent schedule. The §2.3 Kanban dispatches the child workers. The dashboard's log session shows the parent's deliveries; the Kanban's Worker Logs shows the children's runs.
  • Kanban retry → Dashboard analytics. The 6-run and 81-run retries (§2.3 anchor) are visible in the dashboard's analytics per-model breakdown. The model that burned the most tokens is the one the retries hit.
  • Curator run → Dashboard sessions. The Curator's LLM final summary (§2.7) is delivered to the same sessions tab as the chat history. The curator run is a scheduled event, just like a cron delivery.
  • Dashboard config → Kanban profile config. The Dashboard's config tab is the global surface; the Kanban's per-profile config is the per-worker surface. Changes in one are not automatically reflected in the other — verify both after any routing change.

The default configuration. If you take only one piece of advice from this section: wire one cron job in the Dashboard's cron tab that fires a parent task on the Kanban, where the parent dispatches a verifier-approved worker, and schedule the Curator (§2.7) to run weekly on the same cron. That three-component stack — Dashboard cron + Kanban + Curator — is the channel's recommended baseline.

10. Dashboard troubleshooting — the five most common failure modes

The archive guide 27-hermes-dashboard-setup.md and the source video name five dashboard failure modes the channel has hit:

  1. Dashboard won't load (local install). Ensure hermes dashboard is still running in the terminal. Try a different browser. Clear browser cache. The dashboard is a local web app; it is bound to localhost:9119; the terminal must be alive.
  2. Dashboard won't load (VPS install). Verify the SSH tunnel is active. Check that port 9119 isn't blocked by firewall. Restart the SSH tunnel if connection drops. The site can't be reached error is the giveaway that the SSH tunnel is down.
  3. Can't see recent changes. Refresh the browser page. Restart the dashboard: stop hermes dashboard and run it again. The dashboard caches aggressively; a hard refresh is sometimes needed.
  4. Cron jobs not firing. Check Logs for error messages. Verify the cron schedule syntax is correct. Ensure the delivery platform (Discord/Telegram) is properly configured. The Discord/Telegram API failures show up in Logs with the actual error message; copy it back into the agent for diagnosis.
  5. Token budget running hot. Go to Analytics and check the 7-day or 90-day token usage. Identify high-consumption days. Adjust the model usage or task frequency. The per-model breakdown surfaces which model switch burned the most tokens.

The dashboard's interaction with the agent. The dashboard is the admin surface; the agent is the runtime. Changes in the dashboard are persisted to ~/.hermes/config.yaml (or the equivalent path on the current build). Changes in the agent's runtime — model switches, skill toggles, profile changes — are persisted to the same file. The two are in sync, but the dashboard's UI is the easier surface for day-to-day admin. For emergency changes, the terminal is faster.

The dashboard's auth caveat. The source video is explicit: the dashboard has no auth in the local-only tunnel case. The username/password route is the only free path; OAuth is gated behind the Nuki plus tier. The implication: the dashboard's 0.0.0.0 bind is dangerous. The Tailscale bind to a 100.x.x.x tailnet IP is the right answer; the 0.0.0.0 bind is a security incident waiting to happen. The §2.2.2 Tailscale setup is the load-bearing security layer.

The dashboard's logs vs the agent's logs. The dashboard's Logs tab shows the agent's runtime logs: cron deliveries, command invocations, error messages. The agent's ~/.hermes/logs/ directory shows the same logs in a different format (raw text files vs the dashboard's structured UI). The two are in sync; the dashboard is the easier surface for humans, the raw logs are the easier surface for scripts. The Curator's ~/.hermes/logs/curator/[timestamp]/report.md lives in the same directory.

The dashboard's analytics vs the per-model breakdown. The analytics tab shows API call count and token usage over 7, 30, or 90 days. The per-model breakdown surfaces which model switch burned the most tokens. The use case: a day spiked, the user wants to know why. The per-model breakdown shows the model that was used most heavily that day. If the spike is a single model, the user can switch to a cheaper model for that workload. If the spike is a mid-session model switch, the user can pin the session to a single model and avoid the switch cost.

Try it yourself

The dashboard is a hands-on subtopic — but the install is two commands. Pick the path that matches your hosting.

Path A — Local install.

  1. From the terminal, run hermes dashboard. Wait ~1 minute for the UI to build.
  2. Click the http://localhost:9119 link the command prints.
  3. Confirm the sessions tab loads and shows at least one entry.
  4. Open the config tab and confirm your model provider is listed and the gateway timeout is at the default (the source video shows 1,800 seconds).
  5. Do not bind the dashboard to 0.0.0.0. There is no auth.

Path B — VPS install (the channel's default).

  1. From your laptop terminal, run ssh -L 9119:localhost:9119 <vps-ip>. Substitute your VPS IP. Keep the SSH credentials off any public surface.
  2. From the VPS terminal, run hermes dashboard. Wait ~1 minute.
  3. On the laptop, click http://localhost:9119. The dashboard loads via the tunnel.
  4. Set one cron job as a smoke test — this is the §2.4 anchor exercise. Pick a name, write a per-run prompt, set a schedule, and route delivery to local or Discord. Verify the run fires and the entry shows up in log session.
  5. Open analytics and confirm the smoke test produced a token-usage entry. If the count is zero, the cron is configured but not running.

Path C — Hardening for 24/7 use.

  1. Don't use a bare hermes dashboard for production. The source video notes that a tmux-wrapped session survives logout ~50% of the time — and the §2.3 cron+Kanban story already requires a persistent gateway.
  2. Wrap the dashboard in a systemd service that restarts on failure, just like the §2.3 gateway.
  3. If you must expose the dashboard beyond your laptop, use Tailscale and bind to a tailnet IP — the §2.2.2 pattern. Do not bind to 0.0.0.0 and rely on the username/password alone.

Common pitfalls

  • Don't click the raw 9119 link on VPS. It returns site can't be reached for a reason — the port is bound to the VPS. Use the SSH-tunnel pattern (ssh -L 9119:localhost:9119 <vps-ip>) every time.
  • Don't bind the dashboard to 0.0.0.0 and ship it. There is no auth on the in-tunnel case; an open 0.0.0.0:9119 is an API-key leak waiting to happen.
  • Don't share the VPS IP publicly. The source video's own warning. The SSH password is the only barrier between the dashboard and your config.
  • Don't assume the dashboard's cron replaces the Kanban's cron. The dashboard wraps the parent schedule; the Kanban handles child dispatch. They are different surfaces.
  • Don't ignore log session when a cron job silently fails. A Discord API failure shows up there, not in sessions. The fix loop is: copy the failure text, paste it back into Hermes or Claude Code, ask for the cause.
  • Don't enable smart model routing blindly. It is off by default; the source video flags it as a "much smarter output" toggle but does not quantify the cost. Test on a non-critical workload first.
  • Don't bump the gateway timeout without checking the cause. 1,800 seconds is the default. If a tool call is hitting it, the issue is usually the model or the tool, not the timeout.
  • Don't treat the display field as the full SOUL.md. It is a mini one. The full persona lives elsewhere (the source video does not name the path — verify in the docs).
  • Don't conflate the dashboard's memory with Honcho memory. They overlap, but the source video is not certain they are equivalent. Test before removing Honcho.
  • Don't trust a bare hermes dashboard for unattended use. Use systemd (or a Docker restart policy) on VPS. The tmux wrapper from §2.2 is not 24/7-reliable.
  • Don't skip the per-model breakdown in analytics. When a token bill jumps, the per-model view is the first place to look. A mid-session model switch can hide spend under a model you didn't expect.
  • Don't click on the dog food skill in the skills tab and assume it's a UI bug. The source video flags a dog food entry under general and notes it is part of the native skill set. Leave it alone.
  • Don't run the §2.4 cron in isolation. Wire it to a Skill Bundle (§2.5) and a Kanban dispatch (§2.3) once the smoke test works. The cron is the when, the bundle is the what, the Kanban is the who.

Sources