v0.14.0 leverde een stapel performance-werk dat, samen genomen, Hermes Agent als een ander programma laat voelen. De drie koppen uit de release notes:
- •~19 seconden van de cold start af. Verspreid over de import-graph, de doctor-checks, de model-catalog-lookup, de welcome-banner.
- •180× snellere
browser_console. Eén persistente CDP-verbinding in plaats van een nieuwe DevTools-sessie per call openen. - •Cross-session 1-uurs Claude prompt-cache.
/newslaat je warme prefix-cache niet meer weg.
Geen van deze is een "rewrite from scratch". Het zijn telkens series kleine, lokaliseerbare PRs die op specifieke hot paths mikten. Deze post is de PR-voor-PR-uitsplitsing — wat was traag, wat veranderde en welke lessen gelden voor elke agent-auteur.
Het startpunt
Draaide je hermes begin mei 2026, dan zag het cold-start-pad er zo uit:
- 1.Python-interpreter start (~100 ms)
- 2.
import hermestriggert de rest van de import-graph (~5–10 s) - 3.
hermes-plugin-discovery scant geïnstalleerde plugins (~2–3 s) - 4.
hermes doctordraait API-connectivity-probes sequentieel (~3–5 s) - 5.Skills-index laadt, vaak met een nieuwe netwerk-fetch (~2–4 s)
- 6.Welcome-banner rendert (~1 s)
- 7.Prompt verschijnt
Dat is 15–25 seconden voor je kunt typen. Lang genoeg om je flow te breken. De perf-golf van v0.14.0 valt elk van die stappen aan.
De cold-start-golf (10+ PRs)
Skills-cache + lazy adapter-imports (#22138)
De grootste enkele winst. Twee parallelle veranderingen:
- 1.De skills-index wordt naar schijf gecachet. Vroeger: elke
hermes-aanroep las de skills-directory opnieuw en deed lichte indexering. Nu: de index leeft in een cache-file; wordt alleen opnieuw opgebouwd als de directory verandert (mtime-check). - 2.Zware adapter-SDK's worden lazy. Voorheen:
import hermestriggerde het importeren van de Feishu-SDK, de WhatsApp-SDK, elke voice/TTS-provider, elke image-gen-SDK. Nu: elke wordt uitgesteld tot het eerste gebruik. Als je nooit Feishu gebruikt, wordt de Feishu-SDK ook nooit geladen.
Beide zaten in #22138 en sneden ~5–8 seconden af. Het lazy-import-patroon is de niet-bezongen held — het wordt mechanisch over de codebase toegepast maar duikt niet op als één dramatische PR.
Eager plugin-discovery overslaan bij bekende subcommands (#22120)
Draai je hermes config set X Y, dan heb je geen plugin-discovery nodig. Hetzelfde voor hermes tools, hermes model, hermes doctor. De dispatcher kortsluit nu plugin-discovery wanneer het commando een bekende built-in is. ~2 seconden bespaard op de meeste CLI-aanroepen.
models.dev cache-first-lookup (#22808)
Hermes klopt bij models.dev aan voor de canonieke modelcatalogus. Vóór v0.14.0 deed elke hermes-start de HTTP-call. Nu: eerst uit de disk-cache lezen; pas refetchen wanneer stale (>24 u). De cache-hit is ~5 ms in plaats van ~200–500 ms (netwerk-roundtrip).
Parallelle API-connectivity-probes in hermes doctor (#22766)
hermes doctor checkte "kan ik Nous Portal, OpenRouter, Anthropic, OpenAI bereiken" sequentieel. Nu: asyncio.gather ze, en drop IMDS-probing (instance metadata service) dat op non-cloud-machines stond te timeout'en. ~3–5 seconden van doctor af in het typische geval.
chat -q slaat de welcome-banner over (#22904)
Zit je in single-query-modus (hermes chat -q "what's the time"), dan is de welcome-banner ruis. v0.14.0 slaat het renderen over. ~1 seconde terug voor scripted/automation-use cases.
Uitgestelde imports door de hele graph
Een lange staart aan PRs, elk stelt één zwaargewicht-import uit:
- •
google-cloudin degoogle_chat-adapter — laadt pas wanneer google chat voor het eerst wordt gebruikt (#22681) - •
QQAdapter,YuanbaoAdapter— module-level-uitstel via PEP 562 (#22790) - •
httpxin de teams-adapter — pas bij de eerste webhook-call (#22831) - •
fal_client— pas bij de eerste image-generation (#22859)
Elke PR is klein. Samen nog eens 2–4 seconden.
Cache Nous-auth + .env-loads (#25341)
Het hermes tools All-Platforms-scherm deed vroeger per-platform auth-probes synchroon. Dat zakte van 14 seconden naar onder de 1,5 seconde toen de cache landde. Het scherm werkt nog hetzelfde; het brandt alleen niet meer 14 s netwerktijd per aanroep.
Netto-resultaat
Tel de winsten op en je krijgt de headline van 19 seconden. Geen van de losse stukken is dramatisch; samen voelt het programma responsive.
Het 180×-browser_console-verhaal (#23226)
De browser-tool in Hermes gebruikt Chrome DevTools Protocol (CDP) om een headless Chrome aan te sturen. Vóór v0.14.0 deed elke browser_console-evaluatie dit:
- 1.Open een nieuwe CDP-WebSocket naar Chrome
- 2.Wacht op de handshake (~1–2 s)
- 3.Stuur het te evalueren JavaScript
- 4.Lees het resultaat
- 5.Sluit de WebSocket
Voor een keten evaluaties — pakweg de agent die stap voor stap een pagina inspecteert — was dit ~1,5 s per evaluatie. Een typische "kijk eens naar deze pagina en vertel me erover"-workflow voelde pijnlijk traag.
De v0.14.0-verandering: één persistente WebSocket per supervisor, gedeeld over alle browser-tool-calls. De CDP-handshake gebeurt eenmaal per sessie; latere evaluaties slaan stap 1–2 helemaal over en sturen alleen de payload.
Resultaat: per-call-latency zakte van ~1,5 s naar ~8 ms. Dat is ~180×.
De les is algemeen. Overal waar jouw agent N tool-calls doet en elke daarvan opent een nieuwe verbinding: connection-pooling verslaat parallelisme bij chat-tempo-werk. Het werk zit in de connection-setup, niet in het werk zelf.
Cross-session 1-uurs Claude prompt-cache (#23828, #25434, #24778)
Claude's prompt-cache (Anthropic API-feature) laat je een blok context als cacheable markeren. Vervolgaanroepen binnen de TTL — historisch 5 minuten — hergebruiken het gecachete prefix tegen veel lagere kosten en latency.
Vóór v0.14.0 gebruikte Hermes dit binnen een sessie: de system-prompt + actieve skills werden gecachet, hits binnen hetzelfde gesprek waren sneller en goedkoper. Maar bij /new werd de cache geïnvalideerd en startte het volgende gesprek koud.
Het v0.14.0-werk, verdeeld over drie PRs, verlengt de cache-TTL tot 1 uur en zorgt dat de cache-key /new overleeft. Het eerste antwoord in een verse sessie profiteert van een warme cache uit je vorige sessie. Voor mensen die veel korte gesprekken per dag voeren is dit een serieuze winst op kosten en latency.
De cache dekt ook de background memory-review-fork (#25434) — het periodieke proces dat je memory-file herziet en consolideert, klopt nu ook op dezelfde prompt-cache aan, in plaats van per iteratie de volle prijs te betalen.
Een complementaire perf-fix in dit gebied: de prompt-cache-key gebruikt een datum-only-timestamp zodat caches niet kapot gaan over tijdzones. Luide gateway-DB-roundtrip-logging maakt de observability af.
Welke tools de winsten naar boven brachten
Hoe vonden de auteurs deze specifieke hot paths? Twee antwoorden:
- •Cold-start-profiling op een echte install. Ze draaiden
hermesonder timing en hielden bij welke imports het langst duurden. Daarna kwamen ze die één voor één tegen het lijf. - •User-reports van "Hermes voelt traag". Dat het
hermes toolsAll-Platforms-scherm traag was, was een specifieke bug-report; toen die bovenkwam was de fix rechttoe-rechtaan.
Geen magie. De winsten zijn vindbaar met python -X importtime, cProfile en luisteren naar mensen die klagen.
Lessen voor elke agent-auteur
Bouw je een agent, dan generaliseert de perf-golf van v0.14.0 in een paar regels:
- 1.Importeer niet wat je niet gebruikt. Lazy-import elke adapter- en provider-SDK. De import-graph is je cold start.
- 2.Cache alles wat stabiel is. Skills-index, model-catalog, auth-tokens. Refetch alleen wanneer bekend stale.
- 3.Pool je connecties. Roep je een API of een CDP-server meer dan eens per sessie aan, houd dan de verbinding vast.
- 4.Draai onafhankelijke probes parallel. Doctor-checks, health-checks, alles waar volgorde niet uitmaakt.
- 5.Render geen UI die je niet nodig hebt. Welcome-banners, decoratieve output — sla over in non-interactieve paden.
Niets hiervan is nieuw. Het is de standaard performance-playbook voor elke CLI. Het interessante aan v0.14.0 is dat ze de hele playbook in één release-venster hebben toegepast en het resultaat te voelen was op het moment dat gebruikers updateden.
Voelde je Hermes begin mei bros, dan is v0.14.0 de release waarin het koude pad verdween.