voice_metrics.py: neben den rollenden Stats jetzt ein echter Per-Turn-Trace
(TurnTrace + Ringpuffer der letzten 60 Turns). Balken-Stufen zeitlich disjunkt
(stt · vision · hirn · gen); hirn misst ab mark_brain_start() VOR dem Hermes-
Request, damit die Vision-Zeit nicht doppelt gezaehlt wird. STT (davor) und
Mem0-Retrieve (Rueckruf waehrend) werden per park()/_take_* best-effort dem Turn
zugeordnet (Ein-Nutzer-Geraet, kein Turn-ID noetig). Mem0 = Unter-Detail INNERHALB
hirn (nicht addieren) -> ehrlich, kein Doppelzaehlen.
voice.py: TurnTrace in voice_chat's gen() (commit garantiert 1x via finally, auch
bei Fehler/Abbruch). STT-Endpoint parkt seine Dauer. NEU: GET /api/voice/metrics
(schliesst die Luecke - selbstkritik-feed.sh curlte das, existierte nie -> 404) +
GET /api/voice/trace?limit=N.
memory.py: GET /api/memory?q=... (= Hermes' Mem0-Prefetch) misst + parkt die
Retrieve-Zeit.
Frontend: LatencyCard (gestapelte Balken je Turn, "Taeter" = groesste Stufe,
Fehler-Turns rot, Tooltip mit "davon Mem0 X s"), Query useVoiceTrace, in der
Zentrale unter "Stack & Telemetrie". Lokal gegen Seed-Server verifiziert: 30,3-s-
Haenger -> Hirn-Balken 94% + "davon Mem0 26,1 s".
Grenzen (ehrlich, als Fussnote in der Karte): Tool-Runden im Hermes-LLM-Loop haben
keinen Callback an MC2 -> stecken in "Antwort". Reine Telegram-Text-Turns laufen an
MC2 vorbei und erscheinen hier nicht.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
set_group() setzte persistent:true (Verdraengungsschutz), aber NICHT ttl:0. persistent
schuetzt nur gegen Verdraengung durch andere Modelle, nicht gegen ttl-Selbstentladen →
ein Mitglied mit ttl>0 faellt trotz brains-Mitgliedschaft nach Leerlauf aus dem Warm-Set
(live: VL-30B mit ttl 300 entlud sich alle 5 Min). Jetzt erzwingt set_group bei persist=True
ttl:0 fuer jedes Mitglied → der Fehler kann beim Warm-Set-Umbau nie wieder passieren.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
c) System-Logs ausgebaut: neue LogConsole-Komponente färbt Fehler (rot) und
Warnungen (amber) ein, "Nur Probleme"-Filter mit Zähler, Zeilen-Suche;
voice-service in die Dienst-Liste aufgenommen (war nur backend-seitig).
e) Mem0-Dubletten automatisch: deterministischer Auto-Dedupe-Loop (täglich,
apply=True, Schwelle 0.9 > manueller 0.85 da ohne Review) als Backend-
Hintergrund-Task — kein Memory-Bloat mehr ohne Zutun. Knopf bleibt on-demand.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Auto-Rewarm (Nudge + Idle-Tick) lädt jetzt das GANZE Warm-Set über
deploy/warmup.sh nach (fast+vision via chat, embed via /v1/embeddings,
Agent-Prompt-Prefill) statt nur einen Brain-Ping. Erkennt TEIL-Kälte
(Mitglied fehlt in /running), nicht nur den komplett leeren Zustand —
genau der Fall nach einem watch-config-Reload/Deploy (Augen+Gedächtnis
fielen raus, Hirn blieb warm). deploy.sh ruft am Ende warmup.sh.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
a) Update-Meldungen: generischer Release-Summarizer in Lucys Stimme mit
strukturiertem Aktions-Verdikt ("Musst du etwas tun? NEIN/JA") für
Hermes, Engine (llama.cpp) und llama-swap; Fangnetz-Hinweis verheiratet
Breaking-Change-Sorge mit dem Postcheck.
b) OS ehrlich: zurückgestellte Pakete (Phasen-Rollout / kept back) werden
ausgewiesen statt scheinbar zu hängen.
d) Ehrliche Speicher-Zahlen: KV-Cache aus echten GGUF-Architektur-Daten
(Layer × KV-Köpfe × head_dim) + KV-Quant aus dem cmd statt params-blinder
Schätzung — footprint_gb als eine Zahlensprache (Zentrale, Modell-Manager,
fits-Check auf warmset+largest). Auto-Rewarm-Nudge nach Config-Reload.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
_summarize_hermes_commits nutzt jetzt finish_reason: bei "length" (Token-Limit
erreicht) wird der unvollstaendige letzte Stichpunkt entfernt, bei "stop" bleibt
die Antwort unveraendert. max_tokens 380 -> 550 als Puffer.
Erster echter Werkstatt-Kreislauf (Gesellenpruefung), Runde 2 nach Review.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- services/announce.py: persistenter Briefkasten (/srv/models/mc2-announce.json),
POST /api/voice/announce + GET /api/voice/announcements (Cursor-Polling)
- services/sentry.py: Health-Wächter (Engine/Hirn/Hermes/Mem0/Voice/Platte),
flankenerkannt (Alarm nach 3 Fehl-Ticks, Entwarnung, 6h-Erinnerung),
meldet in Briefkasten + Telegram; Hirn-Verdrängung durch IDE-Last = kein Alarm
- notify.sh spiegelt jede Telegram-Meldung in den Briefkasten (Updates/Radar
erreichen damit auch die Desktop-Lucy)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Live gefunden (Zed-Start warf Lucys Hirn raus): llama-swap ignoriert
unbekannte Group-Keys stillschweigend — der Verdrängungsschutz der
brains-Gruppe war seit jeher wirkungslos. set_group() schreibt jetzt
beide Keys (persistent für llama-swap, persist für MC2-API/UI),
budget.py rechnet die echte Ko-Residenz (on-demand reserviert das
Warm-Set statt 0), Warn-Texte beschreiben Überlauf statt Verdrängung.
Box-Config live gefixt + verifiziert: Coder und Qwen3.6 gleichzeitig ready.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Roo Code wurde April 2026 eingestellt (Repo archiviert) — Kilo Code ist der aktive
Nachfolger der Roo/Cline-Linie (Orchestrator-Modus, Modell-pro-Modus, JetBrains+CLI).
Cursor/Zed/Continue raus (cloud-first bzw. von Kilo abgedeckt). Kilo-Note enthaelt die
Modus-Zuordnung: Code->coding, Architect/Orchestrator->heavy, Ask/Debug->chat.
Das Evolution-Radar (AUTONOMIE_PLAN E4) ueberwacht die Tool-Kategorie kuenftig selbst.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Update-Job: nach 'hermes update' laeuft 'hermes doctor' (Job rot bei Fehlern)
- hermes-postcheck.sh: Journal-Scan auf Unknown/deprecated/defaulting (Lehre aus v0.18:
approvals.mode 'auto' wurde still ungueltig -> alle Tools in pending_approval),
Tool-Smoke (echo via Agent, erkennt pending_approval), Voice-Smoke (/api/voice/chat)
- Update-Modal: die Box fasst anstehende Hermes-Commits selbst zusammen (fast-Modell,
no-think, gecacht auf neuesten Hash) — Breaking Changes zuerst
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Backend:
- MTP-Drafter-Support (Multi-Token-Prediction): erkennt MTP-Köpfe neben dem Modell
(mtp-*.gguf / *-assistant, arch gemma4-assistant), schreibt
--model-draft … --spec-type draft-mtp --spec-draft-n-max statt draft-simple.
_parse_model erkennt --model-draft/-md; drafts_for/set_spec_draft/find_compatible_draft
MTP-bewusst. Backward-kompatibel (klassische Drafts unverändert). (config.SPEC_DRAFT_N_MAX)
- register_model: cache-reuse/-cram als Default (Drift-Fix — neue Installs wie der
hand-getunte Box-Stand), --parallel 2 nur noch für coder (kein ctx-Halbierungs-Footgun),
Spec-Auto-Attach für alle Rollen self-guarding.
- budget.reserved_gb auf die VERIFIZIERTE llama-swap-Gruppen-Swap-Semantik angeglichen:
on-demand-Modelle verdrängen die brains-Gruppe und laufen allein (reservieren 0, voller
GTT); brains-Member reservieren nur die übrigen Member. Tote _persist_members entfernt.
Frontend:
- SpecDraftModal zeigt MTP-Drafter mit MTP-Badge (DraftInfo.mtp).
Docs:
- docs/OPTIMIZATION_PLAN.md: vollständiges Audit + Umsetzungs-Log (W1/W2 Warm-Set,
gemma ctx/fa/cache-reuse/MTP 52→70,8 t/s, fast --parallel 1, scout=GLM-4.6V-Flash),
alles live gegen die Box verifiziert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- ROLE_IDS (llamaswap, sources) + UI-Rollenlisten (ModelBadges, Discover,
ModelBrowse, Cockpit-Slot-Grid) um `hermes` erweitert: gemma erscheint als
„Hirn", nicht mehr als scout.
- Neuer set_ttl-Helper; set_agent_brain erzwingt ttl:0 (neu + idempotent beim
Re-Setzen) und liefert eine weiche Budget-Warnung (kein Hard-Block) bei OOM.
- brain_status/brain_model_name: zeigen das echte Hirn (Rolle hermes / Hermes
model.default) statt hart `fast` (Bugfix Health-/Ready-Check).
- POST /api/models/{id}/role delegiert die Rolle `hermes` an den warm-bewussten
Flow (Alias + brains-Gruppe + ttl 0 + Hermes-Config + Gateway-Restart).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Beseitigt Redundanzen/Mismatches, die sich mit den Lanes angesammelt hatten:
- Modell-Manager: großen animierten SVG-Gateway-Graph (~310 Z.) entfernt —
Rolle→Modell deckt das Slot-Grid ab, Lanes der Lane-Editor, IDE-Config die
"Verbinden"-Seite. Cockpit-Brain-Switch raus → Verweis auf Hermes-Tab.
- Hermes: zweiten SVG-Graph + 4 Status-Kacheln durch einen ruhigen Box→Pfeil-
Fluss ersetzt (Terminal → Gateway → Hirn/Verdrahtung/PC), Stil wie "Verbinden".
- Hirn-Wechsel vereinheitlicht: nur noch im Hermes-Tab. Installiert = warm-bewusst
(/api/agent/brain/set), Alias = /api/agent/brain; Lane-Aliase chat/coding/fast/heavy.
- Terminologie auf Lane-Sprache: ConnectView "model auto" → chat/coding;
connect.py-Snippets defaulten auf 'coding' (GATEWAY_MODELS mit Lanes vorn).
- Zentrale: ActiveModelsCard + RolesCard zu einer ModelsCard verschmolzen
(Rollen + warm + Inferenz + Größe); Layout entdoppelt.
~600 Zeilen SVG-Graph-Code raus, 2 tote Karten gelöscht. Verifiziert:
npm run build (tsc strict) clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Teil 1: VoiceLatencyCard auf dem Dashboard (GET /api/voice/metrics, C2) —
zeigt STT/Vision/Chat-TTFB/TTS mit p50/p95/last + count.
Teil 2: UI-editierbare Routing-Policy. Neuer routing_policy.py (hot-reload JSON
unter MODELS_DIR/mc2-routing.json, Env=Defaults, atomarer Write, Validierung).
router_logic, gateway_proxy und gateway.routing_summary lesen jetzt live via
load_policy(); routing_summary ist lane-bewusst (chat/coding statt altem auto).
Neue Endpoints GET/PUT /api/routing/policy.
Teil 3: LaneEditor.tsx als ZONE im Cockpit (chat/coding-Aliase + Schwellen +
fast_no_think, Speichern/Default-je-Feld); Gateway-Node zeigt die Lanes.
Verifiziert: npm run build (tsc strict) clean, FastAPI TestClient (GET/PUT,
Validierung, Persistenz, Hot-reload durch die API), venv-Smoke (Routing).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Neues services/voice_metrics.py (rollend, thread-safe, in-memory): misst STT,
Vision-Beschreibung, Chat-TTFB (Hermes-Stream) und TTS server-seitig. voice.py
instrumentiert die vier Stufen; GET /api/voice/metrics liefert avg/p50/p95/last
je Stufe. Macht aus Latenz-Vermutungen Messdaten — Anzeige folgt im Frontend (E).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Agentisches Coden (OpenCode/RooCode/…) hat immer großen Repo-Kontext; die alte
Regel routete >24k Zeichen auf heavy (Allzweck-122B) statt auf einen Coder =
Downgrade der Coding-Fähigkeit. Jetzt: coding -> CODER immer. Optionaler leichter
schneller Coder via MC_ROUTE_CODER_LITE (Phase 2b: Qwen3-Coder-30B), Eskalation
auf den starken Coder bei Architektur-Keywords / sehr großem Kontext.
Reason-Strings header-safe gemacht (kein U+2192 → Latin-1-Crash im x-mc-Header).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der :9001/v1-Gateway bietet zwei virtuelle Modelle an, die der Router auf echte
Modelle abbildet:
- coding → coder (Standard) · heavy (riesiger/architektonischer Kontext) ·
fast (triviale Nicht-Code-Kurzfrage)
- chat → fast/heavy (= bisheriges model:auto, weiter als Alias unterstützt)
router_logic.choose_for_lane() kapselt die Lane-Logik (Code-Indikatoren DE+EN,
damit echte Coding-Anfragen nie auf fast abrutschen). gateway_proxy routet die
Lane-Namen und listet sie in /v1/models, sodass IDEs einfach "coding" wählen.
Lucy/Hermes (:8642) bleibt unberührt — andere Ebene.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
/api/health liefert jetzt brain:{role,model,ready} (echter /running-Check —
ein abgestuerztes/nicht geladenes Agent-Hirn 'fast' erscheint dort nicht).
Frontend zeigt 'Hirn offline (model)' + Amber-Punkt, statt dass der Ausfall
nur als App-Fehler ('Provider returned an empty stream') auftaucht.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bisher kein Schutz: Doppelklick/zwei Tabs konnten zwei update-engine.sh parallel
starten → racende .bak-Sicherung + parallele llama-swap-Restarts + sich gegenseitig
als kaputt sehende Postchecks.
Backend: jobengine.start_job bekommt group-Tag + active_in_group(); os/engine/swap/
hermes-update sind group="maintenance" und lehnen einen Start ab, solange eines laeuft
({ok:false, status:"busy", running:<label>}). Schuetzt auch gegen parallele Sessions.
Frontend: laeuft ein Wartungs-Job, zeigt der Drawer ein Banner "Update laeuft: <label>"
und sperrt "Jetzt aktualisieren" + "Nach Updates suchen". Logs/Job-Fortschritt/Dienste
bleiben voll nutzbar (Dashboard nicht hart gesperrt). Busy-Antwort wird als Hinweis gezeigt.
Modell-Upgrades bleiben erlaubt (parallel unkritisch).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
update-engine.sh / update-swap.sh sichern jetzt den alten Build/die alte Binary
VOR dem Ueberschreiben (.bak), verifizieren nach dem Restart per stack-postcheck.sh
und rollen bei Fehler automatisch zurueck (Binary/Dir wiederherstellen + restart +
erneut pruefen). Exit-Codes: 0 = neuer Build verifiziert, 1 = fehlgeschlagen aber
Rollback ok (alter Stand laeuft wieder), 2 = Update UND Rollback kaputt.
Da die Skripte den Postcheck nun selbst fahren (um reagieren zu koennen), entfaellt
das `&& stack-postcheck` in engine/swap-update-job. OS-Update behaelt den reinen
Detect-Check (apt-Downgrade waere unsicher). Backups sind winzig (Engine 86M,
Swap 14M) bei 1.6TB frei.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bisher hatte nur das Hermes-Update einen echten Post-Check; OS/Engine/Router
liefen mit Exit 0 durch, auch wenn der neue Build den Stack zerschoss (gruener
Job trotz totem Stack). Neu: deploy/stack-postcheck.sh prueft nach jedem Update
funktional — llama-swap aktiv, /v1/models 200, ECHTE 1-Token-Inferenz auf dem
Hirn-Modell (beweist Laden+Generieren), MC2 /api/health engine_reachable, Mem0
erreichbar. Eingehaengt als `<update> && bash stack-postcheck.sh` in os/engine/
swap-update-job → Exit 1 macht den jobengine-Job ROT. Pendant zu hermes-postcheck.sh.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
_os_upgradable zaehlte mit `grep -c upgradable`, os_update_details parste
`[upgradable from:]` — beides englisch. Auf der deutschsprachigen Box gibt apt
aber `[aktualisierbar von:]` aus → Zaehler 0 und leere Detailliste, obwohl
`apt list --upgradable` 7 Pakete zeigt. Fix: apt mit LC_ALL=C aufrufen, dann
ist die Ausgabe immer englisch und beide greifen wieder.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- _installed_engine_build matchte nur 'build: <hash> (N)' / 'bNNNN', aber der
aktuelle llama-server meldet 'version: 9821 (hash)'. Dadurch war installed_build
immer None → Engine-Badge fiel auf ungenauen mtime-Vergleich zurueck. Jetzt
praeziser Build-Nummer-Vergleich (latest > installed).
- .gitattributes erzwingt LF fuer *.sh/*.service/*.timer: die Box hatte
core.autocrlf aktiv und checkte deploy.sh mit CRLF aus -> 'set -euo pipefail'
wurde zu 'pipefail\r' (invalid option name), Deploy brach ab.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- engine_update_job leert jetzt _engine_cache nach Abschluss (on_done),
sonst zeigte das Dashboard bis zu 1h "Update verfuegbar" trotz erfolgter
Aktualisierung (1h-Cache wurde nie invalidiert wie bei den anderen Jobs).
- check_updates_job leert zusaetzlich _comp_cache, damit "Nach Updates suchen"
auch den Hermes-Status frisch prueft.
- Neu: GET /api/maintenance/update-details (os|engine|hermes) liefert, was
genau aktualisiert wird (apt-Paketliste, Engine Build X->Y + Release-Notes,
Hermes-Commits HEAD..origin/branch).
- Frontend: "Aktualisieren"-Buttons -> "Anzeigen"; oeffnen ein Detail-Fenster
mit den konkreten Aenderungen, erst "Jetzt aktualisieren" startet das Update.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Wartungs-Tab im SystemDrawer neu strukturiert:
- UPDATES: eine einheitliche Liste (OS, Engine, Hermes-Agent, Modell-Upgrades) mit
Status + Aktion-Button, der nur aktiv ist wenn ein Update ansteht (statt Klick-Karten,
die sofort updaten). Konsistent mit der Dashboard-UpdatesCard.
- DIENSTE: neue Sektion, alle systemd-Units mit Status-Punkt (aus /api/system/services,
jetzt inkl. mem0-service) + Restart + Logs-Sprung.
- BACKUP: kompakt (letztes Backup + Snapshot-Button + Restore-Hinweis).
- GEFAHRENZONE: Reboot abgetrennt. Jobs nur wenn vorhanden.
Hermes-Update-Button: POST /api/maintenance/hermes-update -> Job (Backup -> `hermes update
--yes` (git pull + deps) -> hermes-gateway restart). Backend: hermes_update_job + USER_SERVICES
um mem0-service/hermes-terminal ergaenzt (Restart ging vorher nicht), mem0 in services-API.
Live verifiziert: Button hat Hermes d470ed0 -> 3b44a3c aktualisiert, Integration intakt
(memory.provider, Plugin laedt), Pre-Update-Backup angelegt, Drawer rendert fehlerfrei.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bug: UI zeigte nie ein Hermes-Update, obwohl die CLI eins anzeigte. Ursache: MC2 verglich
das neueste GitHub-RELEASE (frozen v2026.6.19) gegen das installierte Commit — Hermes wird
aber aus git main aktualisiert (`hermes update` = git pull origin <branch>), und main laeuft
den Releases voraus. Darum war update immer false.
Fix: _hermes_agent_update() macht jetzt git fetch + zaehlt Commits HEAD..origin/<branch>
(genau wie `hermes update --check`). update=true wenn behind>0; latest = origin-Kurzhash +
behind-Count. Tote Release-Helfer (_gh_latest, _commit_ts) + HERMES_AGENT_REPO-Import entfernt.
Verifiziert: MC2 == CLI (beide "Update verfuegbar, 1 Commit hinter origin/main").
Frontend (UpdatesCard) rendert components bereits korrekt — nur das Backend-Signal war falsch.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Behebt 3 von 4 Backup-Luecken (Schicht 1, lokal):
- backup.sh sichert jetzt den ECHTEN Zustand als ein Tarball mc2-state-<ts>.tar.gz:
mem0 (Chroma+history.db), ~/.hermes (config.yaml, .env, plugins/), llama-swap config.
Vorher wurde nur die alte/leere mc2-memory.db gesichert. chmod 600 (enthaelt .env).
- restore.sh: --list / --dry-run / [--yes] <datei|latest>; macht VOR dem Zurueckspielen
ein Sicherheits-Backup, stoppt/startet Dienste, Health-Check. Live round-trip verifiziert.
- mc2-backup.timer/.service: taegliches Backup ~03:30 (vorher gab es KEINE Automatik).
- backend/services/backup.py delegiert an backup.sh (eine Quelle der Wahrheit); UI-Button
+ /api/system/backups zeigen die Tarballs.
- docs/BACKUP.md: Backup/Restore-Anleitung.
Offen (Schicht 2): Off-Box-Spiegel (Box ist Bare Metal -> PBS-Client oder rsync in LXC).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Saubere Neuordnung der Gedaechtnis-Kategorien an der etablierten Memory-Taxonomie
(semantisch/prozedural/episodisch), bewusst knapp (Best Practice: 3-5, klar beschrieben):
identity (Identitaet & Vorlieben) · knowledge (Wissen & Fakten) ·
rules (Regeln & Konventionen) · events (Ereignisse & Entscheidungen)
Loest die alten gemischten 5 (user/instruction/stable/versioned/ephemeral) ab.
Auto-Einordnung: OSS-mem0 kann nicht nativ kategorisieren (Cloud-Feature) -> nach der
Fakt-Extraktion ordnet dasselbe (Thinking-freie) Hirn jeden neuen Fakt per JSON-Call
genau einer Kategorie zu (classify_facts im Sidecar /learn). Behebt den "alles ist stable"-
Bug. Manuelle Eintraege: Kategorie weiter waehlbar (Default knowledge).
Umgesetzt in mem0_service, backend (services/routers), mcp_memory (Tool-Docs) und Frontend
(MemoryView + GraphView: Labels/Farben/Filter). Kein Migrationsbedarf (leerer Start).
Live verifiziert: gemischter Absatz -> identity/rules/knowledge/events korrekt zugeordnet.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
hermes_brain_info() suchte das role==hermes-Modell + verglich gegen NousResearch-Hermes-
Releases. Da das Hirn jetzt ein beliebiges Modell ist (fast = Qwen3.6 via Alias), war das
irrefuehrend. Neu: _active_brain_name() liest Hermes' model.default und loest den Alias/Namen
auf das installierte Modell auf; recommended/update_available entfallen; Budget-Check bleibt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Nach dem Hirn-Wechsel auf fast (Qwen3.6) zeigte der Wächter noch auf "hermes"
(Hermes-4-14B) -> er haette das aus dem Warm-Set entfernte Modell wieder geladen.
warmer._brain_model() liest jetzt Hermes' model.default (Fallback fast); Startup-Warmup
BRAINS default "fast". Passt sich kuenftigen Hirn-Wechseln automatisch an.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
update_brain_model setzte nur model.model, aber Hermes nutzt model.default als aktives
Modell (model.model = Provider-Param) -> die Hirn-Umschaltung via MC2-UI griff nicht.
Jetzt werden beide Keys gesetzt; agent_status liest default (Fallback model).
Kontext: Hirn von Hermes-4-14B auf fast (Qwen3.6-35B-A3B) umgestellt - Hermes-Modelle
sind laut hermes-agent nicht agentic; Qwen3.6-35B-A3B ist tool-faehig/agentic (verifiziert),
warm und MoE. Terminal-Agentic-Warnung danach weg.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Paket B des Plans. AnythingLLM war nur ein Fallback-Chat zu Hermes; ersetzt durch das
echte interaktive Agent-Terminal (`hermes chat`, mit Tools/PC) als eingebettetes
Web-Terminal.
Box: ttyd (apt) wrappt `hermes chat`; systemd-User-Unit deploy/hermes-terminal.service
(LAN-Bind eno1:7681, apt-Default-ttyd-Dienst deaktiviert). In deploy.sh verankert.
Backend: config HERMES_TERMINAL_URL statt ANYTHINGLLM_URL/_REPO; agent_status liefert
terminal_url/terminal_reachable; maintenance ohne _anythingllm_update; system.py Dienst-Liste
zeigt "Hermes-Terminal".
Frontend: neue Terminal-Seite (iframe auf ttyd) + Nav-Tab; AgentView/AgentStatusCard/nav/api
auf Terminal umgestellt; SystemDrawer toter hermes-dashboard raus, hermes-webui -> hermes-terminal;
Guide-Texte aktualisiert.
Cleanup: deploy/hermes-webui.service + deploy/lobechat/ entfernt (LobeChat-Migration hinfaellig),
HERMES_WEBUI_URL-Env raus.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Punkt 1 - Hirn warm: brains-Gruppe wird bei on-demand-Last ausserhalb der Gruppe
verdraengt; persist verhindert nur Idle-Unload, nicht Gruppen-Swap -> Hirn blieb bis zum
naechsten llama-swap-Neustart kalt. Neu: services/warmer.py als Hintergrund-Task (FastAPI
lifespan) prueft periodisch llama-swap /running; ist die Box idle, pingt es das Hirn
(Rolle hermes) vor. Waehrend aktiver Last (irgendwas geladen) haelt es sich raus.
Justierbar via MC_REWARM_* (ENABLED/INTERVAL/MODEL). Kein sudo, im Repo, deployt normal.
Punkt 2 - Updates-Doppelung: Aktionen gab es auf der Karte UND im Pflege-Drawer.
UpdatesCard zeigt jetzt nur noch die Status-Ampel + 'Updates verwalten & Pflege'-Button
(oeffnet den Drawer). Alle Aktionen (OS/Engine/Reboot/Modell-Upgrade) leben im Drawer mit
Job-Fortschritt -> keine Dublette, kuerzere Karte, Sudo-Modal raus.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Analog zum Auto-ctx-Button: das Rollen-Zuweisungs-Modal empfiehlt jetzt, welches
INSTALLIERTE Modell am besten auf die Rolle passt - capability-getrieben (Vision/Coder/
Tools/MoE aus services.caps) + setup-bewusster Fit (services.budget, gleiche Mathematik
wie Install-Automatik & Auto-ctx).
- services/roles.py: recommend_for_role() rankt installierte Modelle (Eignung + Fit + Tempo
+ Wissen); harte Anforderungen (Vision braucht Vision, Hirn braucht Tools) schliessen aus.
- GET /api/roles/{role}/recommend
- Cockpit-Modal: »Auto: <Modell>«-Button im Header, »Empfohlen«-Badge, Sortierung nach Score,
pro Zeile Fit + Begruendung (~t/s); ungeeignete gedimmt mit Klartext-Grund.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Beim manuellen ctx-Eintrag (Modellkarte »Ctx«) gab es nur ein leeres Eingabefeld.
Jetzt:
- Backend: GET /api/models/{id}/ctx/auto liefert den setup-bewussten Optimal-ctx fuer
ein bestehendes Modell (Rolle/Params/Quant + aktuelles Setup) inkl. Budget-Herleitung.
budget.py: params_of_model() + setup_aware_ctx_for_model() (DRY mit footprint_gb).
- Dialog (CustomDialog/useDialog): optionaler Auto-Button im Prompt, der den Wert eintraegt.
- Cockpit: »Ctx« holt den Optimalwert, zeigt ihn + Budget (GTT/reserviert/frei) in der
Meldung und bietet »Auto (Nk)« zum direkten Uebernehmen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
max_ctx_in_budget schaetzte den KV-Cache LINEAR mit den Params, waehrend Footprint/Fit
sqrt rechnen (kalibriert an Hermes-14B@128K~19GB). Folge: fuer grosse Modelle viel zu
konservativ -> setup_aware_ctx schlug z.B. fuer heavy-122B 8192 vor, obwohl 32768 real
passt. Jetzt exakte Inverse der Footprint-Formel (sqrt*0.84) -> heavy bekommt ~49k statt
8k, keine faelschlichen Reduktionen mehr.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bisher rechnete nur der Hirn-Wechsel setup-bewusst; die allgemeine ctx-Auto-Groesse
nahm den Gesamt-RAM in ISOLATION (ignorierte Hirn/warmes Set/Ko-Residenz) -> ctx
konnte zu gross gewaehlt werden.
Neu: services/budget.py buendelt GTT-Budget, Modell-Footprint und reservierten Speicher
gemaess VERIFIZIERTER Box-Residenz (Hirn immer resident; fast/vision duerfen weichen,
wenn grosses on-demand-Modell laedt). setup_aware_ctx() bemisst den groessten ctx, der
NEBEN dem bestehenden Setup passt - rollen-/gruppen-bewusst aus der echten Config.
- fit.py: max_ctx_in_budget() als budget-basierter Kern; max_ctx_for() delegiert
- models.py: install nutzt setup_aware_ctx; /api/fit liefert assigned_ctx + Budget-Herleitung
- agent.py: nutzt die gemeinsamen Helfer (entfernt Duplikate _gtt_budget_gb/_foot)
- AddModel: Ampel zeigt den setup-bewussten ctx ('ctx -> Nk') inkl. Budget-Tooltip;
Rollen-Wechsel laedt die Vorschau neu (Rolle bestimmt das Budget)
Effekt: heavy-122B bekommt z.B. 16k statt 131072 (passt neben dem Hirn), waehrend
warme Kleinmodelle weiter grossen Kontext erhalten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Inspiriert von Odysseus' Cookbook: backend/models_catalog.json mit echten Metadaten
(total/active params, moe, generation) je Rolle. services/catalog.py: Laden, Name-Match,
MoE-bewusstes Scoring (Wissen + Tempo via tps -> MoE-first auf der bandbreiten-Box), Fit.
- discover.py: Empfehlung jetzt KATALOG-FIRST (kuratiert, korrekt), HF-Dynamik als Ergaenzung/Fallback.
- maintenance.model_upgrades: Metadaten aus Katalog -> praezise Familie/Generation/Groesse + MoE-first
(dense ersetzt MoE nur bei grossem Wissens-Sprung). Behebt Coder-Next=7B-Fehlschaetzung,
Qwen2.5-VL-Generations-Downgrade, falsches dense-scout-Upgrade.
- fit.py: MXFP4/FP8/AWQ in der Quant-Tabelle.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
model_upgrades verletzte das Prinzip: schlug Generations-Downgrades (Qwen2.5-VL ueber
Qwen3-VL), Groessen-Downgrades (Qwen3-Coder-Next ~84B -> 30B; Params aus Name als 7B
fehlgeschaetzt) und Fremd-Familien-Swaps (gpt-oss als Qwen-"Upgrade") vor.
- _params_of: groessen-bewusste Params (max aus Name + Dateigroesse).
- _gen_key: Familie+Subtyp+Generation aus dem Namen (qwen-vl 3.0 vs 2.5 etc.).
- Guard: Upgrade nur bei gleicher erkennbarer Familie UND (neuere Generation ODER
deutlich groesser in gleicher Gen). Sonst keine "Bessere Version"-Anzeige.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hitonabi
Hitonabi