v0.14.0 ha portato a casa una pila di lavoro sulla performance che, presi insieme, fa sembrare Hermes Agent un programma diverso. I tre titoli delle release notes:
- •~19 secondi via dal cold start. Distribuiti sul grafo degli import, sui check del doctor, sul lookup del catalogo modelli, sul banner di benvenuto.
- •
browser_console180× più veloce. Una connessione CDP persistente al posto di aprire una nuova sessione DevTools per chiamata. - •Cache di prompt Claude cross-sessione da 1 ora. Il
/newnon ti perde il prefisso caldo della cache.
Nessuna di queste è una "riscrittura da zero". Ciascuna è una serie di PR piccoli e localizzabili che hanno preso di mira hot path specifici. Questo post è lo smontaggio PR per PR — cosa era lento, cosa è cambiato, e quali lezioni valgono per chiunque scriva un agente.
Il punto di partenza
Se lanciavi hermes ai primi di maggio 2026, il percorso di cold start somigliava a questo:
- 1.Parte l'interprete Python (~100 ms)
- 2.
import hermesfa partire il resto del grafo degli import (~5–10 s) - 3.La plugin discovery di
hermessetaccia i plugin installati (~2–3 s) - 4.
hermes doctorfa girare in sequenza le sonde di connettività API (~3–5 s) - 5.L'indice degli skill si carica, spesso rifacendo il fetch dalla rete (~2–4 s)
- 6.Il banner di benvenuto si renderizza (~1 s)
- 7.Compare il prompt
Sono 15–25 secondi prima che tu possa digitare. Abbastanza per romperti il flow. L'ondata di perf di v0.14.0 attacca ognuno di questi passi.
L'ondata sul cold start (10+ PR)
Cache degli skill + import lazy degli adapter (#22138)
La vittoria singola più grossa. Due cambiamenti in parallelo:
- 1.L'indice degli skill è cacheato su disco. Comportamento precedente: ogni invocazione di
hermesrileggeva la directory degli skill e faceva un'indicizzazione leggera. Comportamento nuovo: l'indice vive in un file di cache ; ricostruito solo quando la directory cambia (check su mtime). - 2.Gli SDK degli adapter pesanti diventano lazy. Prima: importare
hermesfaceva caricare l'SDK Feishu, l'SDK WhatsApp, ogni provider voice/TTS, ogni SDK di image-gen. Ora: ognuno è differito al primo uso. Se non usi mai Feishu, l'SDK Feishu non viene mai caricato.
Entrambi i cambiamenti stanno in #22138 e hanno tagliato ~5–8 secondi. Il pattern del lazy-import è l'eroe non celebrato — è applicato meccanicamente in tutto il codice, ma non compare come un unico PR drammatico.
Saltare la plugin discovery aggressiva sui sottocomandi noti (#22120)
Se lanci hermes config set X Y, della plugin discovery non te ne fai nulla. Stessa cosa per hermes tools, hermes model, hermes doctor. Adesso il dispatcher cortocircuita la plugin discovery quando il comando è un built-in noto. ~2 secondi risparmiati sulla maggior parte delle invocazioni CLI.
Lookup cache-first su models.dev (#22808)
Hermes interroga models.dev per il catalogo canonico dei modelli. Prima di v0.14.0, ogni avvio di hermes faceva la chiamata HTTP. Adesso: legge prima dalla cache su disco ; rifa il fetch solo quando è stale (>24 h). Il cache hit fa ~5 ms invece di ~200–500 ms (round-trip di rete).
Sonde di API in parallelo dentro hermes doctor (#22766)
hermes doctor controllava "raggiungo Nous Portal, OpenRouter, Anthropic, OpenAI" in sequenza. Adesso: le asyncio.gather, e mandato in pensione il probing IMDS (instance metadata service) che andava in timeout sulle macchine non-cloud. ~3–5 secondi tagliati dal doctor nel caso tipico.
chat -q salta il banner di benvenuto (#22904)
Se sei in modalità single-query (hermes chat -q "what's the time"), il banner di benvenuto è rumore. v0.14.0 ne salta il rendering. ~1 secondo restituito per casi d'uso da script / automazione.
Import differiti in giro per il grafo
Una coda lunga di PR, ognuno che differisce un import pesante:
- •
google-cloudnell'adaptergoogle_chat— si carica solo quando si usa google chat per la prima volta (#22681) - •
QQAdapter,YuanbaoAdapter— differimento a livello di modulo via PEP 562 (#22790) - •
httpxnell'adapter di teams — solo alla prima chiamata webhook (#22831) - •
fal_client— solo alla prima generazione di immagine (#22859)
Ogni PR è piccolo. Tutti insieme valgono altri 2–4 secondi.
Cache dell'auth Nous e dei load di .env (#25341)
La schermata All-Platforms di hermes tools faceva sonde di auth per piattaforma in modo sincrono. Quando è atterrata la cache, quella schermata è scesa da 14 secondi a meno di 1,5. La schermata funziona uguale ; solo che non brucia più 14 s di rete ad ogni invocazione.
Risultato netto
Somma le vittorie e ti escono i 19 secondi del titolo. Nessuna è drammatica da sola ; insieme fanno sentire il programma reattivo.
La storia del 180× su browser_console (#23226)
Il tool browser di Hermes usa Chrome DevTools Protocol (CDP) per pilotare un Chrome headless. Prima di v0.14.0, ogni valutazione di browser_console faceva questo:
- 1.Apre un nuovo WebSocket CDP verso Chrome
- 2.Aspetta l'handshake (~1–2 s)
- 3.Manda il JavaScript da valutare
- 4.Legge il risultato
- 5.Chiude il WebSocket
Per una catena di valutazioni — diciamo, l'agente che ispeziona una pagina passo per passo — questo era ~1,5 s a valutazione. Un tipico workflow "guarda questa pagina e raccontamela" era doloroso, lento.
La modifica di v0.14.0: un WebSocket persistente per supervisor, condiviso da tutte le chiamate al tool browser. L'handshake CDP avviene una volta per sessione ; le valutazioni successive saltano del tutto i passi 1–2 e mandano direttamente il payload.
Risultato: la latenza per chiamata è scesa da ~1,5 s a ~8 ms. Cioè ~180×.
La lezione è generale. Ovunque il tuo agente faccia N chiamate a tool e ognuna apra una nuova connessione: per i carichi al ritmo della chat, il pooling delle connessioni batte la parallelizzazione. Il lavoro totale è nella creazione della connessione, non nel lavoro vero e proprio.
Cache di prompt Claude cross-sessione da 1 ora (#23828, #25434, #24778)
La prompt cache di Claude (una feature dell'API Anthropic) ti lascia marcare un pezzo di contesto come cacheabile. Le richieste successive entro il TTL — storicamente 5 minuti — riusano il prefisso cacheato a costo e latenza molto più bassi.
Prima di v0.14.0, Hermes la usava dentro una sessione: il system prompt + gli skill attivi venivano cacheati, gli hit nella stessa conversazione erano più veloci e più economici. Ma quando lanciavi /new, la cache veniva invalidata e la conversazione successiva partiva fredda.
Il lavoro di v0.14.0, distribuito su tre PR, estende il TTL della cache a 1 ora e fa sì che la chiave di cache sopravviva al /new. La prima risposta in una sessione nuova trae beneficio da una cache calda dalla sessione precedente. Per chi fa molte conversazioni brevi in un giorno, è una vittoria reale su costo e latenza.
La cache copre anche il ramo di memory review in background (#25434) — il processo periodico che rivede e consolida il tuo file di memory adesso pesca dalla stessa prompt cache invece di pagare il prezzo pieno ad ogni iterazione.
Un fix di perf complementare in quest'area: la chiave della prompt cache usa un timestamp ridotto alla data, così le cache non saltano attraversando i fusi orari. Il logging chiassoso dei round-trip gateway-DB completa l'osservabilità.
I tool che hanno tirato fuori le vittorie
Come hanno fatto gli autori a trovare questi hot path specifici? Due risposte:
- •Profilazione del cold start su un'installazione vera. Hanno fatto girare
hermescol cronometro e tenuto sotto controllo quali import erano più lunghi. Poi sotto, uno a uno. - •Segnalazioni degli utenti che "Hermes va lento". Il fatto che la schermata All-Platforms di
hermes toolsfosse lenta era un bug report puntuale ; una volta venuto a galla, il fix è stato lineare.
Niente magia. Le vittorie si trovano con python -X importtime, cProfile, e ascoltando chi si lamenta.
Lezioni per chiunque scriva un agente
Se stai costruendo un agente, l'ondata di perf di v0.14.0 si generalizza in poche regole:
- 1.Non importare quello che non usi. Lazy-import su ogni adapter e SDK di provider. Il grafo degli import è il tuo cold start.
- 2.Cache qualunque cosa sia stabile. Indice degli skill, catalogo modelli, token di auth. Rifai il fetch solo quando sai che è stale.
- 3.Riusa le connessioni. Se chiami un'API o un server CDP più di una volta per sessione, tieniti la connessione.
- 4.Lancia in parallelo le sonde indipendenti. Check del doctor, health check, qualsiasi cosa in cui l'ordine non conta.
- 5.Non renderizzare UI che non serve. Banner di benvenuto, output decorativi — saltali nei percorsi non interattivi.
Nessuna di queste è nuova. È il playbook standard di performance per qualunque CLI. La cosa interessante di v0.14.0 è che hanno applicato il playbook intero in una sola finestra di release e il risultato si è sentito nel momento esatto in cui gli utenti hanno fatto l'update.
Se il tuo Hermes ti sembrava pesante a inizio maggio, v0.14.0 è la release in cui il percorso freddo è sparito.