# Hermes-Schicht — Box-Runbook > Diese Schritte laufen **auf der Bosgame** (`192.168.178.151`, User `hitonabi`). > MC betreibt Hermes nicht — es zeigt nur Status + verlinkt das WebUI. Hier wird die > eigentliche **volle Verdrahtung** gemacht (das war in v1 der „Hermes ist dumm"-Grund). ## Reihenfolge der Dienste `llama-swap (:8080)` → **builtin Gateway (`:9001/v1`, Teil von MC2)** → `hermes-gateway (:8642)` → `hermes-webui (:8787, nesquena)` ## 1. Gateway = builtin (kein LiteLLM) LiteLLM scheitert auf Python 3.14 (uvloop/orjson). MC2 bringt einen **eingebauten** OpenAI-kompatiblen Gateway auf `:9001/v1` mit: `model: auto` (kurz→`fast`, komplex→`heavy`) + explizite Aliase (`fast`/`heavy`/`coder`/`vision`/`hermes`). Verifizieren: ```bash curl -s http://127.0.0.1:9001/v1/models ``` ## 2. Engine: Rollen (llama-swap) Aliase sauber: `fast` (Qwen3.6-35B-A3B), `heavy` (Qwen3.5-122B-A10B), `coder`, `vision`, `scout`, `hermes` (Hermes-4-14B, `ttl 99999` = immer warm). Verwaltung im Cockpit (Modelle & Routing). **Ko-Residenz** (optional): Gruppe `swap:false` für `hermes`+`fast` → beide warm; `heavy`/`vision` on-demand. GTT beobachten (~124 GB Limit). ## 3. hermes-webui installieren (nesquena, standalone) ```bash cd ~ && git clone https://github.com/nesquena/hermes-webui && cd hermes-webui python3 bootstrap.py # erkennt hermes-agent, baut venv, installiert Deps mkdir -p ~/.config/environment.d echo 'HERMES_WEBUI_PASSWORD=' > ~/.config/environment.d/hermes-webui.conf # Unit deploy/hermes-webui.service → ~/.config/systemd/user/ (HOST=0.0.0.0, PORT=8787) systemctl --user enable --now hermes-webui loginctl enable-linger hitonabi ``` Zugriff vom Windows-PC: `http://192.168.178.151:8787` (mit Passwort). MC2-Unit `HERMES_WEBUI_URL=http://192.168.178.151:8787` setzen → „Hermes öffnen" zeigt darauf. **Danach das alte offizielle Dashboard stilllegen** (eine WebUI): `systemctl --user disable --now hermes-dashboard` (:9119). ## 4. Hermes-Hirn = dediziertes Hermes-4-14B + Delegation (NICHT model:auto) In `~/.hermes/config.yaml`: ```yaml model: default: Hermes-4-14B provider: custom base_url: http://127.0.0.1:9001/v1 api_key: local model: hermes # Hermes' eigenes Hirn (Alias→Hermes-4-14B), NICHT 'auto' delegation: model: heavy # harte Teilaufgaben → Qwen3.5-122B provider: custom base_url: http://127.0.0.1:9001/v1 api_key: local orchestrator_enabled: true subagent_auto_approve: true ``` `model:auto` bleibt ausschließlich Gateway-Funktion für Vibe Coding/IDEs. ## 5. Tools/MCP verdrahten — UND kaputte Tools abschalten (Thrash-Fix!) - **Kaputte/Cloud-Tools global abschalten** (sonst Endlos-Loops, siehe Memory `hermes-thrash-rootcause-fix`): ```yaml agent: disabled_toolsets: [browser, vision, computer_use, image_gen, tts, video, video_gen, memory] memory: memory_enabled: false user_profile_enabled: false ``` ⚠️ `hermes tools disable ` wirkt nur für die cli-Plattform, **nicht den api_server** — nutze `agent.disabled_toolsets` (gilt für ALLE Plattformen). - **Behalten:** terminal/shell, file, code_execution, skills, todo, session_search, clarify, delegation, cronjob, web. `approvals: auto` (rein lokal). - **MCP-Server** (`mcp_servers` in config) — laufen über die v2-venv (hat das `mcp`-Modul nach pip install): - geteiltes Gedächtnis: `~/mission-control-v2/backend/.venv/bin/python ~/mission-control-v2/mcp/mcp_memory.py` (Env `MC_URL=http://127.0.0.1:9001`) - Stack-Management: `~/mission-control-v2/backend/.venv/bin/python ~/mission-control-v2/mcp/mcp_mc.py` (Env `MC_URL=http://127.0.0.1:9001`) - **SSH→Windows-PC** (voller Zugriff): OpenSSH-Server auf Windows aktiv + Key `~/.ssh/id_ed25519_hermes_agent` autorisiert; Hermes nutzt sein terminal-Tool für `ssh TobisPC@`. ## 6. Verifikation - `curl :8642/v1/chat/completions` „bist du da?" → kurze Antwort in wenigen Sekunden, **kein** Tool-Loop im `journalctl --user -u hermes-gateway`; llama-swap `/running` zeigt `Hermes-4-14B`. - WebUI öffnet vom Windows-PC, Chat antwortet. - Hermes kann via `mcp_mc` Modelle listen/Routing ändern; erreicht (nach §5-SSH) den Windows-PC.