v0.14.0 a sorti une pile de travail de perf qui, mise bout à bout, fait de Hermes Agent un programme différent. Les trois titres des release notes :
- •~19 secondes en moins au démarrage à froid. Réparties sur le graphe d'imports, les checks de doctor, le lookup du catalogue de modèles, la bannière de bienvenue.
- •
browser_console180 fois plus rapide. Une connexion CDP persistante au lieu d'ouvrir une nouvelle session DevTools à chaque appel. - •Cache de prompt Claude d'une heure entre sessions.
/newne te tue plus le cache du préfixe encore chaud.
Aucune de ces choses n'est une « réécriture depuis zéro ». Chacune est une suite de PRs petits et localisés qui visaient des hot paths précis. Cet article, c'est le décorticage PR par PR — ce qui était lent, ce qui a changé, et les leçons qui se généralisent pour n'importe quel auteur d'agent.
Le point de départ
Si tu lançais hermes début mai 2026, le chemin du démarrage à froid ressemblait à ça :
- 1.L'interpréteur Python démarre (~100 ms)
- 2.
import hermesdéclenche le reste du graphe d'imports (~5–10 s) - 3.La découverte de plugins de
hermesscanne les plugins installés (~2–3 s) - 4.
hermes doctorlance les sondes de connectivité API en séquence (~3–5 s) - 5.L'index des skills se charge, souvent en refaisant un fetch réseau (~2–4 s)
- 6.La bannière de bienvenue s'affiche (~1 s)
- 7.Le prompt apparaît
Ça fait 15–25 secondes avant que tu puisses taper. Assez long pour casser le flow. La vague de perf de v0.14.0 attaque chacune de ces étapes.
La vague de démarrage à froid (10+ PRs)
Cache de skills + imports lazy d'adaptateurs (#22138)
La plus grosse victoire seule. Deux changements en parallèle :
- 1.L'index des skills est mis en cache sur disque. Avant : chaque invocation de
hermesrelisait le dossier skills et lançait une indexation légère. Nouveau : l'index vit dans un fichier de cache ; il n'est reconstruit que quand le dossier change (vérification par mtime). - 2.Les SDKs d'adaptateurs lourds passent en lazy. Avant : importer
hermesdéclenchait l'import du SDK Feishu, du SDK WhatsApp, de chaque provider voice/TTS, de chaque SDK de génération d'images. Nouveau : chacun est différé jusqu'à la première utilisation. Si tu n'utilises jamais Feishu, le SDK Feishu ne se charge jamais.
Les deux changements sont dans #22138 et ont raboté ~5–8 secondes. Le pattern lazy-import est le héros silencieux — appliqué mécaniquement à travers la codebase mais sans apparaître comme un PR unique spectaculaire.
Sauter la découverte agressive de plugins sur les sous-commandes connues (#22120)
Si tu lances hermes config set X Y, tu n'as pas besoin de découverte de plugins. Pareil pour hermes tools, hermes model, hermes doctor. Le dispatcher court-circuite maintenant la découverte de plugins quand la commande est un built-in connu. ~2 secondes économisées sur la majorité des invocations CLI.
Lookup cache-first sur models.dev (#22808)
Hermes interroge models.dev pour le catalogue canonique des modèles. Avant v0.14.0, chaque démarrage de hermes faisait l'appel HTTP. Nouveau : lecture d'abord depuis le cache disque ; refetch uniquement quand le cache est périmé (>24 h). Le cache hit est de ~5 ms au lieu de ~200–500 ms (aller-retour réseau).
Sondes API parallèles dans hermes doctor (#22766)
hermes doctor vérifie « est-ce que j'arrive à joindre Nous Portal, OpenRouter, Anthropic, OpenAI » en séquence. Nouveau : asyncio.gather pour tout lancer en même temps, plus la sonde IMDS (instance metadata service) qui timeoutait sur les machines non-cloud a été retirée. ~3–5 secondes rabotées sur doctor dans le cas typique.
chat -q saute la bannière de bienvenue (#22904)
Si tu es en mode requête unique (hermes chat -q "what's the time"), la bannière de bienvenue est du bruit. v0.14.0 saute le rendu. ~1 seconde récupérée pour les cas scriptés / d'automatisation.
Imports différés à travers le graphe
Une longue queue de PRs où chacun diffère un import lourd :
- •
google-clouddans l'adaptateurgoogle_chat— ne se charge que quand Google Chat est utilisé pour la première fois (#22681) - •
QQAdapter,YuanbaoAdapter— différement au niveau module via PEP 562 (#22790) - •
httpxdans l'adaptateur teams — seulement au premier appel webhook (#22831) - •
fal_client— seulement à la première génération d'image (#22859)
Chaque PR est petit. Ensemble, ils valent 2–4 secondes supplémentaires.
Cache de l'auth Nous et des loads .env (#25341)
L'écran All-Platforms de hermes tools faisait des sondes d'auth par plateforme de manière synchrone. Avec le cache, ça est tombé de 14 secondes à moins de 1,5. L'écran marche pareil ; il ne brûle juste plus 14 s de réseau à chaque invocation.
Résultat net
Tu additionnes les gains et tu retombes sur le titre de 19 secondes. Aucun n'est spectaculaire pris seul ; ensemble, ils rendent le programme réactif.
L'histoire du 180× de browser_console (#23226)
L'outil browser dans Hermes utilise Chrome DevTools Protocol (CDP) pour piloter un Chrome headless. Avant v0.14.0, chaque évaluation browser_console faisait ça :
- 1.Ouvrir un nouveau WebSocket CDP vers Chrome
- 2.Attendre le handshake (~1–2 s)
- 3.Envoyer le JavaScript à évaluer
- 4.Lire le résultat
- 5.Fermer le WebSocket
Pour une chaîne d'évaluations — disons l'agent qui inspecte une page étape par étape — c'était ~1,5 s par évaluation. Un workflow typique « regarde cette page et raconte-moi » était péniblement lent.
Le changement v0.14.0 : un WebSocket persistant par superviseur, partagé entre tous les appels d'outil browser. Le handshake CDP se fait une fois par session ; les évaluations suivantes sautent complètement les étapes 1–2 et envoient juste le payload.
Résultat : latence par appel tombée de ~1,5 s à ~8 ms. C'est ~180×.
La leçon se généralise. Partout où ton agent fait N appels d'outil et que chacun ouvre une nouvelle connexion : le pooling de connexion bat le parallélisme pour les charges au rythme du chat. Tout le travail est dans le setup de connexion, pas dans le boulot lui-même.
Cache de prompt Claude d'une heure entre sessions (#23828, #25434, #24778)
Le cache de prompt de Claude (feature de l'API Anthropic) te laisse marquer un morceau de contexte comme cacheable. Les requêtes suivantes dans le TTL — historiquement 5 minutes — réutilisent le préfixe caché à coût et latence bien plus bas.
Avant v0.14.0, Hermes utilisait ça à l'intérieur d'une session : le system prompt + les skills actifs étaient cachés, les hits dans la même conversation étaient plus rapides et moins chers. Mais quand tu lançais /new, le cache était invalidé, et la conversation suivante repartait à froid.
Le travail de v0.14.0, sur trois PRs, étend le TTL de cache à 1 heure et fait survivre la clé de cache à /new. La première réponse dans une session fraîche profite d'un cache encore chaud de ta session précédente. Pour qui fait plein de courtes conversations par jour, c'est un gain significatif en coût et en latence.
Le cache couvre aussi le fork de revue de memory en arrière-plan (#25434) — le processus périodique qui revisite et consolide ton fichier memory tape maintenant le même cache de prompt au lieu de payer plein tarif à chaque itération.
Un fix de perf complémentaire dans le coin : la clé de cache de prompt utilise un timestamp date-only, donc les caches ne sautent pas en traversant des fuseaux horaires. Des logs bruyants d'aller-retour gateway-DB ont été aussi rangés au passage côté observabilité.
Les outils qui ont fait remonter les gains
Comment les auteurs ont-ils trouvé ces hot paths précis ? Deux réponses :
- •Profiling de démarrage à froid sur une install réelle. Ils ont lancé
hermessous chrono et tracé quels imports prenaient le plus de temps. Puis ils s'y sont attaqués un par un. - •Reports utilisateurs « Hermes est lent ». L'écran All-Platforms de
hermes toolslent, c'était un bug report précis ; une fois remonté, le fix était direct.
Pas de magie. Les gains se trouvent avec python -X importtime, cProfile, et en écoutant les gens se plaindre.
Leçons pour n'importe quel auteur d'agent
Si tu construis un agent, la vague de perf v0.14.0 se généralise en quelques règles :
- 1.N'importe pas ce que tu n'utilises pas. Lazy-import chaque SDK d'adaptateur et de provider. Le graphe d'imports, c'est ton démarrage à froid.
- 2.Mets en cache tout ce qui est stable. Index des skills, catalogue des modèles, tokens d'auth. Ne refetch que quand tu sais que c'est périmé.
- 3.Mets les connexions en pool. Si tu appelles une API ou un serveur CDP plus d'une fois par session, garde la connexion.
- 4.Lance les sondes indépendantes en parallèle. Checks doctor, health checks, tout ce qui ne demande pas d'ordre précis.
- 5.Ne rends pas d'UI dont tu n'as pas besoin. Bannières de bienvenue, sorties décoratives — saute-les sur les chemins non interactifs.
Rien de tout ça n'est nouveau. C'est le manuel de perf standard pour n'importe quelle CLI. Ce qui est intéressant avec v0.14.0, c'est qu'ils ont appliqué le manuel entier dans une seule fenêtre de release et que le résultat s'est senti au moment précis où les utilisateurs ont mis à jour.
Si ton Hermes te paraissait poussif début mai, v0.14.0 est la release où le chemin froid a disparu.