Environment
- Hermes One: latest (installed 2026-07-28)
- OS: Windows 10
- GPU: RTX 3090 24GB
- Model: local llama.cpp, Qwen3.6-27B (IQ4_XS, MTP), single slot (
-np 1)
- Connection mode: local
Symptoms
- Chat normally for 3–5 turns
- "Hermes dashboard request timed out: model.options" appears
- All subsequent messages freeze — no response from any session
- Only fix: close and reopen Hermes One entirely
Reproduction
Always reproducible. Any multi-turn conversation triggers it. Time between turns (idle waiting) does NOT prevent it — suggesting it's not related to model slot contention.
Evidence collected
- hermes-agent.exe renderer process leaks memory: starts at ~200MB, exceeds 465MB after a few turns
- Python agent backend is NOT the cause: the
hermes serve API server remains responsive throughout (sessions endpoint returns 200 in <10ms even when Dashboard shows timed out)
- All backend optimizations were applied and verified with no improvement:
- Compression moved to separate 4B auxiliary model (port 8090) — confirmed working
- Background self-improvement review moved to auxiliary model
- Title generation disabled
- Memory/skill flush intervals extended
- Proxy layer removed (direct connection to llama-server)
- state.db VACUUMed
- web_server.py compat injection blocked (read-only)
- Official Hermes Desktop does NOT exhibit this issue with identical backend config
Likely root cause
Memory leak in the Electron renderer process (Dashboard UI). The Dashboard's model picker or WebSocket connection management appears to accumulate state across conversation turns, eventually causing the renderer to become unresponsive. The "model.options" timeout is the first visible symptom because the model picker refresh is one of the earliest requests to stall when the renderer's event loop blocks.
Workaround
Close and reopen Hermes One every 4–5 conversation turns. CLI (hermes) and official Dashboard (hermes dashboard) are unaffected.
Environment
-np 1)Symptoms
Reproduction
Always reproducible. Any multi-turn conversation triggers it. Time between turns (idle waiting) does NOT prevent it — suggesting it's not related to model slot contention.
Evidence collected
hermes serveAPI server remains responsive throughout (sessions endpoint returns 200 in <10ms even when Dashboard shows timed out)Likely root cause
Memory leak in the Electron renderer process (Dashboard UI). The Dashboard's model picker or WebSocket connection management appears to accumulate state across conversation turns, eventually causing the renderer to become unresponsive. The "model.options" timeout is the first visible symptom because the model picker refresh is one of the earliest requests to stall when the renderer's event loop blocks.
Workaround
Close and reopen Hermes One every 4–5 conversation turns. CLI (
hermes) and official Dashboard (hermes dashboard) are unaffected.