--- name: hub-brain-modelle-check-2026-07-23 description: "Worker G Ergebnis (302): Hub-Modelle/Hermes-Verfuegbarkeit geprueft, litellm-YAML-Bug gefunden+gefixt, Hermes-Router zeigt auf toten Host" metadata: node_type: memory date: 2026-07-23 author: worker-g-vm302 --- # Worker G: Hub-Modelle/Hermes-Verfuegbarkeits-Check (302) Geprueft von VM302 aus (Tailscale-Route zu hub.comet-bicolor.ts.net 100.87.20.94 direkt erreichbar) + ergaenzend per SSH direkt auf den Hub. ## Ausgangslage laut Auftrag - Hub-Brain: `http://100.87.20.94:3097` → **existiert nicht**, bestaetigt (Connection refused, kein Prozess/kein Listener). Deckt sich mit vorhandener Memory `hub-endpoints-aktuell.md` (verifiziert 2026-07-10: ":3097 und :3088 existieren NICHT"). Ein aelterer, widerspruechlicher Eintrag `reference_hub_service_map_live.md` ("3097 = brain/tts, active") ist **veraltet/falsch** — sollte korrigiert/geloescht werden. - Router: `http://100.87.20.94:3080` → antwortet, ist aber nur ein **nginx-Proxy** auf `jump.panel1.de:3080` (100.91.98.15, eigener uvicorn `router:app`, 3 Modelle: `auto`, `mammouth::auto`, `minimax::MiniMax-M2`). Kein vollstaendiger 17-Provider- Router. ## Gefundener Kern-Bug (BEHOBEN) Der eigentliche Modell-Gateway des Hubs ist **LiteLLM auf :4000** (`100.87.20.94:4000`, tailnet-only, `master_key: sk-litellm-koerner`, systemd `litellm.service`). Er war **crashgelooped** (`activating auto-restart`): ``` yaml.parser.ParserError: while parsing a block mapping in "/opt/litellm/config.yaml", line 1, column 1 expected , but found '-' in "/opt/litellm/config.yaml", line 556, column 1 ``` Ursache: ein `router_settings:` Block (2 Zeilen) war mitten in die `model_list:`-YAML-Liste eingefuegt worden (Zeile 554/555), was das Parsen der restlichen 17 Listeneintraege danach (bis Zeile 571) invalid machte. **Fix (reversibel, Backup vorhanden):** - Backup: `/opt/litellm/config.yaml.bak-fix-20260723-145857` - `router_settings:`-Block ans Dateiende verschoben (korrekte Position als eigener Top-Level-Key nach `model_list:`) - YAML validiert (`python3 -c "import yaml; yaml.safe_load(...)"` → OK, 4 Top-Level-Keys: general_settings, litellm_settings, model_list, router_settings) - `systemctl restart litellm.service` → **aktiv, stabil, kein Crash-Loop mehr** - `GET /v1/models` (mit Bearer `sk-litellm-koerner`) → **114 Modelle**, siehe unten ## Modell-Liste (114, Stand 2026-07-23 15:00, von :4000 via LiteLLM) Provider-Praefixe: `mammouth/*` (Chat: claude/claude-haiku/claude-sonnet/opus/gpt-4/ gpt-4o/gpt-5/gpt-5.4-nano/grok/grok-fast/gemini/gemini-2.5-pro/gemini-flash/kimi/ glm/llama/mistral/qwen/perplexity/sonar/deep-research/deepthink/expert/reasoning/ thinking + Medien: flux/nano-banana/sd/recraft/svg/image/gpt-image/veo/kling/sora/ grok-imagine/tts*/speech/elevenlabs/playht/azure-tts/google-tts/openai-tts), `deepseek/*` (chat, reasoner, v4-flash), `jump/deepseek-chat`, `gpu1/*` (qwen3-8b, codestral, gemma3-27b, dolphin3 via Ollama 100.108.128.107), `devmac/*` (devstral, gemma3, qwen3-32b), `ionos/*` (13 Modelle inkl. llama-3.1-405b, qwen3-coder, flux-schnell, ocr, embeddings/reranker), `free/*` (deepseek-r1/v3, gemini-flash, llama4-maverick, mistral-small, qwen3-235b), `image/*` (comfyui, lustify, pony, sd15, juggernaut, realvis, biglust, cyberpony), `qolaba/*`, `monster/*`, `openrouter/gemini-pro`, `code/*` (antigravity, gemini, gemini-2.5-flash), `hermes2/agi`, `gpushadow/*`. Vollstaendige Liste im Beleg-Log (Session-Output), auf Anfrage nachreichbar. ## "302"-Hinweis/Tag In keiner Hub-/Hermes-Config (litellm config.yaml, hermes-orchestrator.py, hermes-v2/*, hermes-index.json) existiert ein Tag/Label "302" fuer Modelle. Die einzigen "302"-Treffer sind unrelated Skill-IDs (`ln-302-task-replanner`, "302ai Api Integration Skill"). **Interpretiert als:** Kennzeichnung, dass diese Pruefung von VM302 aus erfolgte (Netzwerksicht) — kein technischer Modell-Tag. **[BÄR]**: falls ein echtes "302"-Tag/Label in Hermes fuer Modell-Sichtbarkeit gemeint war, bitte przisieren — wurde nirgends im Code/Config gefunden. ## Ungeloester Befund — [BÄR] noetig `hermes-orchestrator.py`, `/opt/hermes-v2/orchestrator.py`, `stategraph.py`, `supervisor.py` haben **hartkodiert** `ROUTER = 'http://100.92.201.88:3080'` (Host `tools.comet-bicolor.ts.net`). Dieser Host ist laut Tailscale seit **2026-06-12 offline** (`connectedToControl: false`, kein `lastSeen` seither) — **5+ Wochen tot**. D.h. Hermes' eigentliche LLM-Call-Funktion `router_chat()` zeigt seit Wochen auf einen toten Host und kann darueber vermutlich seit Wochen keine Modelle laden/nutzen (nicht als "trivial/reversibel" eingestuft, da mehrere Produktions-Dateien + Auth-Header (`master_key` vs. `dummy`) + Modellnamen-Mapping betroffen sind — braucht Bär-Entscheidung, welcher Router (neu: `:4000` LiteLLM mit 114 Modellen, oder `:3080` nginx-Proxy mit 3 Modellen) Hermes kuenftig verwenden soll). Separat: `t_brain_ask()` in hermes-orchestrator.py ruft weiterhin `http://localhost:3097/v1/brain` — bestaetigt totes Ziel (Eskalationsstufe 4 "Brain-Ask" laut Vier-Stufen-Eskalation in CLAUDE.md ist damit vermutlich nicht funktionsfaehig). ## Status brain-smoke-test.service Laeuft alle 6h, schlaegt seit mind. 3 Tagen durchgehend 5/5 fehl (erwartungs- gemaess, da Ziel `:3097/v1/brain` nicht existiert). Sollte deaktiviert oder auf einen echten Endpoint umgebogen werden — **[BÄR]**. ## Zusammenfassung | Item | Status | |---|---| | Hub-Brain :3097 | existiert nicht (bestaetigt, wie Memory 2026-07-10) | | Router :3080 (Tailscale, ueber nginx→jump) | laeuft, nur 3 Modelle | | LiteLLM Gateway :4000 (echter Hub-Modell-Gateway) | **war down (YAML-Bug) → gefixt, jetzt 114 Modelle live** | | "302"-Tag in Config | nicht gefunden, ungeklaert → [BÄR] | | Hermes ROUTER-Konstante | zeigt auf toten Host (100.92.201.88, seit 5+ Wochen offline) → [BÄR] | | brain-smoke-test.service | daueraft rot, erwartungsgemaess (totes Ziel) → [BÄR] |