custom_instructions als zwingende Sprach-Direktive — mem0s englischer Extraktions-Prompt
zog sonst Richtung Englisch. Eigennamen/Befehle/Modellnamen (PowerShell-Push, Qwen3.6, …)
bleiben unveraendert. Live verifiziert: gemischter DE/EN-Input -> Fakten auf Deutsch.
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>
Empty State der Gedaechtnis-Seite fragt nicht mehr nach kanned Facts (war zu sehr
auf eine Person zugeschnitten), sondern leitet ein Onboarding-GESPRAECH mit Hermes
an: das UI zeigt einen fertigen, generischen Onboarding-Prompt (Hermes interviewt
den Nutzer in 5 Schritten). Buttons: "Im Terminal starten" (kopiert Prompt + springt
zum Terminal-Tab via mc-navigate-Event) und "Prompt kopieren"; Hinweis auf Telegram +
manuelles Anlegen. Das Gespraech fuellt das Gedaechtnis dann ueber den Auto-Lern-Hook.
App.tsx: mc-navigate CustomEvent -> setView (Tab-Wechsel aus Views heraus).
Live verifiziert (Onboarding-State, Prompt, Terminal-Navigation, kein Fehler).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kompletter Umbau des Memory-Tabs: Graph ist jetzt Standard/Held statt sekundaerer
Toggle. Kompakte Werkzeugleiste (semantische Suche, "+ Eintrag" als Button statt
Riesenbox, Liste/Graph-Umschalter, Dedup). Statuszeile mit Zaehlern (Fakten, auto
gelernt, manuell, Kategorien). Suche filtert auch den Graphen (clientseitig).
Empty State mit "Starter-Vorlage" (Beginner Template): auf Knopfdruck fuegt der
Nutzer 6 kuratierte Beispiel-Fakten ueber den Stack ein (source=template, einzeln
editier-/loeschbar) - nichts wird automatisch injiziert. Vorschau der Vorlage sichtbar.
Live gegen die Box verifiziert (Empty State, Template-Flow, Graph-Render, Stats).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
shutdown() + on_session_end() schreiben verbliebene Queue-Eintraege synchron raus
(_flush), damit kurzlebige Prozesse den Hintergrund-Worker nicht mitten im /learn-POST
killen. Live verifiziert: hands-off Auto-Lernen via Gateway (source=hermes) + Recall.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hängt Hermes ans geteilte Mem0-Gedächtnis ohne Tool-Loop-Risiko:
- sync_turn (nach jedem Turn) → /api/memory/learn (infer=True, Hintergrund-Worker,
nicht-blockierend) → Mem0 extrahiert dauerhafte Fakten automatisch.
- prefetch (vor dem Turn) → semantische Suche → relevante Fakten als Kontext.
- get_tool_schemas()=[] → context-only, keine Agent-Tools (memory bleibt in
disabled_toolsets). Single Source of Truth bleibt der MC2-Sidecar.
Installation nach ~/.hermes/plugins/mc2-memory/ via deploy.sh; Aktivierung box-lokal
in ~/.hermes/config.yaml (memory.memory_enabled: true + memory.provider: mc2-memory).
Provider-Ebene verifiziert (Auto-Lernen + semantischer Recall gegen Box).
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>
Seit die Karten im Hero nur noch 1/3 breit sind:
- System-Status-Legende brach um (DISK fiel in eine eigene Zeile). Jetzt festes
2-Spalten-Grid -> CPU/RAM oben, GPU/DISK unten (DISK neben GPU), GB-Detail truncatet.
- Aktive-Modelle: inneres Grid (sm:grid-cols-2 xl:grid-cols-3) machte die Zelle winzig
-> Modellname abgeschnitten. Auf eine Spalte (volle Kartenbreite) -> Name voll sichtbar.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bisher lag der Verlauf in component-lokalem State (useSystemHistory / TokenPerformanceCard).
Beim Tab-Wechsel wurde die Zentrale unmountet -> Historie weg -> Graphen starteten leer
und mussten sich neu aufbauen.
Neu: lib/metricsStore.ts haelt den Verlauf modul-global (useSyncExternalStore) und wird
von useMetricsFeeder() gefuettert, das in App (immer gemountet) haengt. So sammelt der
Verlauf kontinuierlich weiter - unabhaengig vom aktiven Tab - und die Graphen zeigen beim
Zurueckwechseln sofort die volle Historie. Zentrale + Diagnose teilen denselben Store.
Verifiziert: Store waechst auch auf Modell-Manager weiter; Rueckkehr zeigt lueckenlosen
Verlauf statt Reset.
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>
- Token-Durchsatz nutzte bg-gradient-to-b statt bg-card/45 und verlor dadurch den
gradient-Top-Akzent + Hover-Lift (index.css greift nur bei bg-card/45). Zurueck auf
Standard-Kartenstil -> konsistent mit allen Karten.
- Zentrale: System-Status, Token-Durchsatz und Aktive Modelle als gleich-prominenter
Hero-Banner (3 Spalten) oben; Rest gruppiert darunter (Stack-Status: Rollen + Dienste,
Betrieb & Wissen: Updates + Hermes + Gedaechtnis).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Diagnose war groesstenteils Dublette (Metriken/Temps schon in Zentrale; Logs/Restart/
Updates im Pflege-Drawer). Tab entfernt, zwei einzigartige Teile umverteilt.
- Zentrale neu in 3 Zonen: Live-Telemetrie (System-Status + Token-Durchsatz nebeneinander
statt gestapelt), Stack-Status (Aktive Modelle / Rollen / Dienste), Betrieb & Wissen
(Updates / Hermes / Gedaechtnis).
- Neue ServicesCard (Dienste-Health aus Diagnose) auf der Zentrale.
- TokenStatsCard ('Effizienz & Ersparnis') in TokenPerformanceCard gemerged (Input/Output
+ gespart) -> eine Karte weniger, keine Dublette.
- Backup/Snapshot in den System-Wartung-Drawer verschoben.
- nav.ts/App.tsx: 'system'-View entfernt (6 statt 7 Tabs); SystemView.tsx geloescht.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gemeinsame LiveAreaChart-Komponente + useSystemHistory-Hook (EINE Quelle der Wahrheit
fuer den Live-Verlauf), genutzt von Zentrale & Diagnose.
- Diagnose: die 4 statischen Balken (CPU/RAM/GPU/Disk) sind jetzt farbcodierte
Einzel-Live-Charts (Spline, Gradient, Hover-Tooltip, dyn. Y-Achse).
- Neue TokenPerformanceCard (Zentrale): Live-Durchsatz tok/s, aus den kumulativen
Token-Zaehlern als Rate abgeleitet (Prompt/Prefill vs. Antwort/Generierung), KPI-
Headline (tok/s, Gesamt-Tokens, gespart EUR), dunkler Performance-Stil.
- SystemStatusCard auf die geteilte Komponente/Hook umgestellt (schlanker).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Auf Wunsch im Stil der Referenz-Dashboards: unified Live-Chart (CPU/RAM/GPU/Disk) mit
glatten Flaechen (monotone), Gradient-Fill, Legende mit Live-Werten + GB-Detail, und
gestyltem Hover-Tooltip (alle Serien an der Cursor-Position). Dynamische Y-Achse
(skaliert in 25er-Schritten auf den Peak), damit Linien auch bei idle-Box den Chart
ausfuellen. Reines Live (kein Monats-/Jahres-Dropdown), rollende 40 Punkte (~2 Min).
- recharts als Dependency
- Sparkline.tsx entfernt (durch Recharts ersetzt)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Die 4 Kennzahlen (CPU/RAM/GPU/Disk) auf der Zentrale zeigen jetzt rollende Sparklines
(Area+Linie) statt statischer Radial-Gauges. SystemStatusCard sammelt pro Poll (3s,
ueber dataUpdatedAt) einen Messpunkt, haelt die letzten 40 (~2 Min Verlauf) und rendert
sie via neuer Sparkline-Komponente. Farbcodierung (gruen/amber/rot) + "live"-Indikator;
RadialGauge entfernt (war nur hier genutzt).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Erlaubt, den Vite-Dev-Server gegen ein anderes Backend zu proxen (z.B. die Box)
ohne Code-Aenderung - genutzt fuer den End-to-End-Browser-Check des Modell-Managers.
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>
Manueller HF-Install hatte zwei scharfe Kanten:
- kein Fit/OOM-Schutz: zu grosses Modell stuerzte erst beim Laden ab
- stiller Rollen-Diebstahl: exklusiver Alias wanderte kommentarlos weg
Backend: /api/fit leitet params_b jetzt aus KATALOG (echte Metadaten, MoE-bewusst)
oder Namens-Schaetzung ab (params_b<=0) -> Fit-Vorschau fuer beliebige HF-Repos.
Frontend (AddModel): Hardware-Fit-Ampel (perfect/marginal/OOM) mit ~params/req_gb/tps
nach 'Quants laden'; OOM-Gate (zweiter, roter Klick noetig); Warnung welches Modell
die gewaehlte Rolle aktuell haelt und sie verliert.
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>
Cockpit VRAM-HUD las einen hardcodierten 16GB-APU-Fallback als Pool-Kapazitaet -> Leiste
zeigte z.B. "11.3/16GB". Jetzt: gtt_total aus /api/system/status (unified memory, ~124GB).
Label zeigt zusaetzlich die reale GTT-Belegung (inkl. KV) ehrlich an.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- agent.set_agent_brain(model_id): vergibt 'hermes'-Alias, tauscht das Modell in die
residente brains-Gruppe (altes Hirn raus, fast/vision bleiben) und zeigt die Hermes-Config
darauf (+ Gateway-Restart). Behebt: AgentView-Switch hielt das neue Hirn nicht warm.
- POST /api/agent/brain/set.
- Cockpit Agent-Hirn-Karte: Button "Hirn wechseln" + Modal mit allen installierten Modellen
(Groesse/Params/Rolle/Tools), aktuelles markiert; Hinweis zugunsten Hermes (Tool-Calling).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
_gguf_total_size summiert alle ...-NNNNN-of-NNNNN.gguf-Teile. size_bytes des ersten
Teils war bei Split-Modellen wie Qwen3.5-122B (11M Header + 47G + 25G) irrefuehrend.
Fix wirkt in UI-Anzeige UND Budget-Footprint.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
heavy ist Split-GGUF (size_bytes = nur erster Teil) -> aus Namen (122B); coder ohne
Groesse im Namen -> aus Dateigroesse (~84B). max() deckt beide Faelle ab.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
_foot() rechnet Gewichte aus size_bytes (genau) + kalibrierten KV-Anteil; Params werden
aus der Dateigroesse abgeleitet, wenn der Name keine Groesse hergibt (z.B. Qwen3-Coder-Next,
46GB -> ~84B). Damit ist das groesste on-demand-Modell im Budget realistisch.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Brain-Kontexte gesenkt (live config): hermes 128K->64K, fast/vision 128K->32K
-> Always-Warm-Footprint 74GB->51GB, ~23GB frei; heavy/coder passen wieder daneben.
- /api/agent/brain liefert jetzt `budget`: projiziert den Always-On-Footprint mit dem
empfohlenen Brain gegen das GTT-Budget (aus amdgpu.gttsize) und prueft, ob das groesste
on-demand-Modell daneben passt (fit.estimate_memory_gb).
- Cockpit Agent-Hirn-Karte: Budget-Zeile (gruen/rot) + Warnung im Update-Confirm, wenn ein
zu grosses Always-On-Brain das groesste on-demand-Modell verdraengen wuerde. Button wird rot.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- discover.rank_runnable: rankt jetzt fit-level > params_b(desc) > downloads -> fuer die
128GB-Box wird das faehigste passende (MoE-)Modell empfohlen statt kleiner Populaer-Modelle.
Top-4-Anzeige nutzt dasselbe Ranking.
- maintenance.model_upgrades: schlaegt KEIN Downgrade mehr vor (rec.params_b >= installiert*0.95).
Behebt: fast 35B-A3B -> 4B wurde faelschlich als Upgrade angeboten.
- Frontend: Rollen-Farb-Mapping zentralisiert in ModelBadges (ROLE_TONE/roleTone);
Cockpit/RolesCard/ActiveModelsCard nutzen es statt eigener Duplikate.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Engine-Cutover ROCm/HIP -> Vulkan/RADV (gfx1151): +12-22% tg auf MoE (llama-bench
verifiziert, fast 53->65 t/s). ROCm-Build bleibt als Rollback unter /opt/llamacpp.
- Backend: vocab-aware Speculative Decoding. services/gguf_meta.py liest den
Tokenizer-Fingerprint (model/pre/n_vocab) direkt aus dem GGUF-Header (ohne Modell-Load);
register_model + migrate_config haengen nur VOCAB-KOMPATIBLE Drafts an (inkl. --spec-type,
das in dieser llama.cpp-Generation noetig ist). Neue Endpoints /api/models/drafts + /{id}/draft.
- Frontend: idiotensichere Spec-Draft-UI (SpecDraftModal) - nur kompatible Drafts waehlbar,
inkompatible gesperrt mit Begruendung; SPEC/SPEC?-Badge nach echtem Aktiv-Status; Rolle in AddModel.
- maintenance.py: Engine-Update-Quelle -> ggml-org/llama.cpp (Build-Nummer-Vergleich),
ENGINE_PATH=/opt/llamacpp-vulkan.
- Startup-Warmup der brains (deploy/warmup.sh, self-detaching ExecStartPost) + deploy/provision-engine.sh.
- Cleanup: tote LiteLLM gateway/config.yaml + alle Referenzen (config.py/backup.py/backup.sh) entfernt;
README + docs/memory aktualisiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
client/hermes-agent/ war ein veralteter Eigenentwicklungs-Daemon (Port 8765),
der durch hermes-gateway (NousResearch) + mcp_pc.py ersetzt wurde.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- mcp/mcp_web.py: fetch_url + fetch_urls Tools
- Hermes kann jetzt Seiteninhalte lesen ohne externen API-Key
- trafilatura für saubere Textextraktion aus HTML
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
MC2 prüfte Gateway-Erreichbarkeit via GET /v1/models — der Hermes API-Server
lehnte jeden Request ohne gültigen API-Key ab (Spam alle 3s im Log).
Fix: /health-Endpoint nutzen, der keine Authentifizierung benötigt.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Hitonabi