v0.14.0 hat einen Stapel Performance-Arbeit ausgeliefert, der zusammengenommen Hermes Agent wie ein anderes Programm anfühlen lässt. Die drei Headlines aus den Release Notes:
- •~19 Sekunden weniger Kaltstart. Quer durch den Import-Graph, die Doctor-Checks, das Modellkatalog-Lookup, das Welcome-Banner.
- •180-mal schnelleres
browser_console. Eine persistente CDP-Verbindung statt pro Aufruf eine neue DevTools-Session. - •Sessionsübergreifender 1-Stunden-Claude-Prompt-Cache.
/newreißt dir den warmen Prefix-Cache nicht mehr weg.
Keines davon ist eine „komplette Neuschrift". Jedes ist eine Reihe kleiner, ortbarer PRs, die auf bestimmte Hot Paths zielen. Dieser Beitrag ist die PR-für-PR-Aufschlüsselung — was langsam war, was sich geändert hat und welche Lektionen sich für jeden Agent-Autor verallgemeinern lassen.
Der Ausgangspunkt
Wenn du Anfang Mai 2026 hermes gestartet hast, sah der Kaltstart so aus:
- 1.Python-Interpreter startet (~100 ms)
- 2.
import hermeszieht den restlichen Import-Graph hoch (~5–10 s) - 3.Die Plugin-Discovery von
hermesscannt installierte Plugins (~2–3 s) - 4.
hermes doctorläuft API-Konnektivitäts-Probes sequenziell (~3–5 s) - 5.Skills-Index lädt, oft mit Netzwerkanfrage (~2–4 s)
- 6.Welcome-Banner rendert (~1 s)
- 7.Prompt erscheint
Macht 15–25 Sekunden, bevor du tippen kannst. Lang genug, um den Flow zu zerreißen. Die Performance-Welle in v0.14.0 geht jeden dieser Schritte an.
Die Kaltstart-Welle (10+ PRs)
Skills-Cache + Lazy-Adapter-Imports (#22138)
Der einzelne größte Gewinn. Zwei parallele Änderungen:
- 1.Skills-Index auf Disk gecacht. Vorher: jeder
hermes-Aufruf hat das Skills-Verzeichnis neu eingelesen und ein leichtes Indexing gefahren. Neu: Der Index lebt in einer Cache-Datei und wird nur neu gebaut, wenn sich das Verzeichnis ändert (mtime-Check). - 2.Schwergewichtige Adapter-SDKs sind jetzt lazy. Vorher:
import hermeszog den Import des Feishu-SDK, des WhatsApp-SDK, jedes Voice-/TTS-Providers, jedes Image-Gen-SDK mit. Neu: jedes wird bis zur ersten Nutzung verzögert. Wenn du Feishu nie benutzt, wird das Feishu-SDK nie geladen.
Beide Änderungen sitzen in #22138 und sparen ~5–8 Sekunden. Das Lazy-Import-Muster ist der heimliche Held — mechanisch quer durch die Codebase angewandt, ohne als einzelner spektakulärer PR aufzufallen.
Plugin-Discovery bei bekannten Subcommands überspringen (#22120)
Wenn du hermes config set X Y aufrufst, brauchst du keine Plugin-Discovery. Dasselbe für hermes tools, hermes model, hermes doctor. Der Dispatcher kürzt die Plugin-Discovery jetzt ab, wenn der Befehl ein bekanntes Built-in ist. ~2 Sekunden gespart in den meisten CLI-Aufrufen.
Cache-first-Lookup bei models.dev (#22808)
Hermes fragt models.dev für den kanonischen Modellkatalog. Vor v0.14.0 hat jeder hermes-Start den HTTP-Call gemacht. Neu: zuerst aus dem Disk-Cache lesen, nur neu holen, wenn der Eintrag älter ist (>24 h). Cache-Hit liegt bei ~5 ms statt ~200–500 ms (Netzwerk-Roundtrip).
Parallele API-Probes in hermes doctor (#22766)
hermes doctor prüft „komme ich an Nous Portal, OpenRouter, Anthropic, OpenAI?" sequenziell. Neu: asyncio.gather für alle zusammen, plus das IMDS-Probing (Instance-Metadata-Service), das auf Nicht-Cloud-Maschinen ständig in Timeouts lief, ist raus. ~3–5 Sekunden weg in typischen Fällen.
chat -q lässt das Welcome-Banner weg (#22904)
Wenn du im Single-Query-Modus bist (hermes chat -q "what's the time"), ist das Welcome-Banner Lärm. v0.14.0 rendert es in dem Fall nicht. ~1 Sekunde zurück für scripted/Automation-Cases.
Verzögerte Imports quer durch den Graph
Eine lange Reihe von PRs, jeder verzögert genau einen schwergewichtigen Import:
- •
google-cloudimgoogle_chat-Adapter — lädt erst, wenn Google Chat zum ersten Mal benutzt wird (#22681) - •
QQAdapter,YuanbaoAdapter— Verzögerung auf Modulebene via PEP 562 (#22790) - •
httpxim Teams-Adapter — nur beim ersten Webhook-Call (#22831) - •
fal_client— nur bei der ersten Bildgenerierung (#22859)
Jeder PR ist klein. Zusammen weitere 2–4 Sekunden.
Nous-Auth und .env-Loads cachen (#25341)
Der All-Platforms-Bildschirm von hermes tools hat pro Plattform synchron Auth-Probes gemacht. Mit dem Cache ist das von 14 Sekunden auf unter 1,5 gefallen. Der Screen funktioniert gleich; er verbrennt nur nicht mehr pro Aufruf 14 s Netzwerk-Zeit.
Netto-Ergebnis
Du addierst die Gewinne und kommst bei den Headline-19-Sekunden an. Einzeln ist nichts davon spektakulär; zusammen fühlt sich das Programm reaktionsschnell an.
Die 180×-Story bei browser_console (#23226)
Das Browser-Tool in Hermes nutzt das Chrome DevTools Protocol (CDP), um ein Headless-Chrome zu steuern. Vor v0.14.0 lief jede browser_console-Auswertung so:
- 1.Neuen CDP-WebSocket zu Chrome öffnen
- 2.Auf den Handshake warten (~1–2 s)
- 3.JavaScript zur Auswertung schicken
- 4.Ergebnis lesen
- 5.WebSocket schließen
Für eine Auswertungskette — sagen wir, der Agent inspiziert eine Seite Schritt für Schritt — waren das ~1,5 s pro Auswertung. Ein typischer „schau dir die Seite an und erzähl mir was dazu"-Workflow war schmerzhaft langsam.
Die Änderung in v0.14.0: ein persistenter WebSocket pro Supervisor, geteilt über alle Browser-Tool-Calls. Der CDP-Handshake passiert pro Session einmal; spätere Auswertungen überspringen Schritte 1–2 komplett und schicken nur das Payload.
Ergebnis: Latenz pro Call von ~1,5 s auf ~8 ms. Das ist ~180×.
Die Lektion ist allgemein. Überall, wo dein Agent N Tool-Calls macht und jeder eine neue Verbindung aufmacht: Connection-Pooling schlägt Parallelism bei Chat-Tempo-Workloads. Die ganze Arbeit liegt im Verbindungsaufbau, nicht in der eigentlichen Arbeit.
Sessionsübergreifender 1-Stunden-Claude-Prompt-Cache (#23828, #25434, #24778)
Claudes Prompt-Cache (Anthropic-API-Feature) lässt dich einen Kontext-Block als cachebar markieren. Folgende Requests innerhalb des TTL — historisch 5 Minuten — verwenden den gecachten Präfix bei sehr viel niedrigeren Kosten und Latenz wieder.
Vor v0.14.0 hat Hermes das innerhalb einer Session benutzt: System-Prompt + aktive Skills wurden gecacht, Treffer innerhalb derselben Konversation waren schneller und billiger. Aber wenn du /new gefahren bist, war der Cache invalidiert und die nächste Konversation startete kalt.
Die Arbeit in v0.14.0 verteilt sich auf drei PRs: Cache-TTL auf 1 Stunde verlängert und der Cache-Key überlebt /new. Die erste Antwort in einer frischen Session profitiert von einem warmen Cache aus deiner vorigen Session. Für Leute, die viele kurze Konversationen am Tag fahren, ist das ein spürbarer Gewinn an Kosten und Latenz.
Der Cache deckt auch den Background-Memory-Review-Fork ab (#25434) — der periodische Prozess, der dein Memory-File wieder besucht und konsolidiert, trifft jetzt denselben Prompt-Cache, statt pro Iteration den vollen Preis zu zahlen.
Ein begleitender Performance-Fix in dem Bereich: Der Prompt-Cache-Key nutzt jetzt einen date-only Timestamp, damit Caches über Zeitzonen hinweg nicht platzen. Laute Gateway-DB-Roundtrip-Logs runden die Observability-Verbesserung ab.
Welche Werkzeuge die Gewinne sichtbar gemacht haben
Wie haben die Autoren genau diese Hot Paths gefunden? Zwei Antworten:
- •Kaltstart-Profiling auf einer echten Installation. Sie haben
hermesunter Zeitmessung laufen lassen und nachverfolgt, welche Imports am längsten brauchten. Dann sind sie sie der Reihe nach angegangen. - •User-Reports „Hermes fühlt sich langsam an". Dass der All-Platforms-Screen von
hermes toolslangsam war, war ein konkreter Bug-Report; sobald er sichtbar wurde, war der Fix unspektakulär.
Keine Zauberei. Die Gewinne sind mit python -X importtime, cProfile und dem Zuhören, wenn Leute sich beschweren, findbar.
Lektionen für jeden Agent-Autor
Wenn du an einem Agenten baust, lassen sich aus der v0.14.0-Performance-Welle ein paar Regeln ableiten:
- 1.Importiere nichts, was du nicht nutzt. Lazy-importiere jeden Adapter und jedes Provider-SDK. Der Import-Graph ist dein Kaltstart.
- 2.Cache alles, was stabil ist. Skills-Index, Modellkatalog, Auth-Tokens. Refetch nur bei known-stale.
- 3.Bündele Connections. Wenn du eine API oder einen CDP-Server pro Session mehr als einmal aufrufst, halt die Verbindung.
- 4.Unabhängige Probes parallel. Doctor-Checks, Health-Checks, alles, wo die Reihenfolge egal ist.
- 5.Render keine UI, die du nicht brauchst. Welcome-Banner, dekorative Ausgaben — auf nicht-interaktiven Pfaden weglassen.
Nichts davon ist neu. Es ist das Standard-Performance-Playbook für jede CLI. Was an v0.14.0 interessant ist: Sie haben das gesamte Playbook in einem einzigen Release-Fenster angewendet, und das Ergebnis war im Moment des Updates spürbar.
Wenn sich dein Hermes Anfang Mai zäh anfühlte, ist v0.14.0 das Release, in dem der kalte Pfad verschwunden ist.