v0.14.0 trajo una pila de trabajo de rendimiento que, junto, hace que Hermes Agent se sienta como un programa distinto. Los tres titulares de las release notes:
- •~19 segundos menos en el arranque en frío. A lo largo del grafo de imports, los chequeos de doctor, el lookup del catálogo de modelos, el banner de bienvenida.
- •
browser_console180 veces más rápido. Una conexión CDP persistente en lugar de abrir una nueva sesión de DevTools por llamada. - •Caché de prompt de Claude de 1 hora entre sesiones.
/newya no te tira la caché caliente del prefix.
Ninguno de estos es una "reescritura desde cero". Cada uno es una serie de PRs pequeños y localizables que apuntaron a hot paths concretos. Este artículo es el desglose PR a PR — qué iba lento, qué cambió, y qué lecciones valen para cualquier autor de agente.
Punto de partida
Si lanzabas hermes a primeros de mayo de 2026, el camino del arranque en frío pintaba así:
- 1.El intérprete de Python arranca (~100 ms)
- 2.
import hermesdispara el resto del grafo de imports (~5–10 s) - 3.El descubrimiento de plugins de
hermesescanea plugins instalados (~2–3 s) - 4.
hermes doctorcorre sondas de conectividad a APIs en serie (~3–5 s) - 5.Carga del índice de skills, a menudo refetcheándolo de la red (~2–4 s)
- 6.Render del banner de bienvenida (~1 s)
- 7.Aparece el prompt
Eso son 15–25 segundos antes de poder teclear. Lo suficiente para romper el flujo. La ola de rendimiento de v0.14.0 ataca cada uno de esos pasos.
La ola de arranque en frío (10+ PRs)
Caché de skills + imports lazy de adaptadores (#22138)
La victoria individual más gorda. Dos cambios paralelos:
- 1.Índice de skills cacheado a disco. Antes: cada invocación de
hermesreleía el directorio de skills y corría una indexación ligera. Ahora: el índice vive en un archivo de caché, solo se reconstruye cuando cambia el directorio (chequeo por mtime). - 2.SDKs pesados de adaptadores en lazy. Antes: importar
hermesdisparaba el import del SDK de Feishu, el de WhatsApp, cada provider voice/TTS, cada SDK de generación de imagen. Ahora: cada uno se difiere al primer uso. Si nunca usas Feishu, el SDK de Feishu no se carga nunca.
Ambos cambios en #22138 y recortan ~5–8 segundos. El patrón de lazy-import es el héroe sin medalla — se aplicó de forma mecánica por todo el codebase pero no sale como un PR dramático único.
Saltarse el descubrimiento de plugins en subcomandos conocidos (#22120)
Si ejecutas hermes config set X Y, no necesitas descubrir plugins. Lo mismo para hermes tools, hermes model, hermes doctor. El dispatcher hace ahora cortocircuito en el descubrimiento de plugins cuando el comando es un built-in conocido. ~2 segundos ahorrados en la mayoría de invocaciones de CLI.
Lookup cache-first en models.dev (#22808)
Hermes consulta models.dev para el catálogo canónico de modelos. Antes de v0.14.0, cada arranque de hermes hacía la llamada HTTP. Ahora: lee primero de caché en disco; solo refetchea cuando está vieja (>24 h). El cache hit son ~5 ms en lugar de los ~200–500 ms de roundtrip de red.
Sondas de conectividad de hermes doctor en paralelo (#22766)
hermes doctor chequeaba "¿llego a Nous Portal, OpenRouter, Anthropic, OpenAI?" en serie. Ahora: asyncio.gather para lanzarlas a la vez, y se tira la sonda IMDS (instance metadata service) que daba timeout en máquinas no-cloud. Doctor pierde ~3–5 segundos en el caso típico.
chat -q se salta el banner (#22904)
Si estás en modo single-query (hermes chat -q "what's the time"), el banner de bienvenida es ruido. v0.14.0 se salta el render. ~1 segundo de vuelta para casos scripteados/automatizados.
Imports diferidos por todo el grafo
Una cola larga de PRs, cada uno difiere un import pesado:
- •
google-clouden el adaptadorgoogle_chat— solo se carga cuando se usa Google Chat (#22681) - •
QQAdapter,YuanbaoAdapter— diferimiento a nivel de módulo vía PEP 562 (#22790) - •
httpxen el adaptador de teams — solo en la primera llamada webhook (#22831) - •
fal_client— solo en la primera generación de imagen (#22859)
Cada PR es pequeño. Juntos suman otros 2–4 segundos.
Cachear la auth de Nous y los .env (#25341)
La pantalla hermes tools All-Platforms hacía sondas de auth por plataforma de forma síncrona. Eso bajó de 14 segundos a menos de 1.5 cuando aterrizó la caché. La pantalla sigue funcionando igual; solo deja de quemar 14 s de tiempo de red en cada invocación.
Resultado neto
Suma las victorias y sale el titular de 19 segundos. Ninguna por separado es dramática; juntas hacen que el programa se sienta receptivo.
La historia del 180× de browser_console (#23226)
La tool de browser en Hermes usa Chrome DevTools Protocol (CDP) para conducir un Chrome headless. Antes de v0.14.0, cada evaluación de browser_console hacía esto:
- 1.Abrir un WebSocket CDP nuevo contra Chrome
- 2.Esperar el handshake (~1–2 s)
- 3.Mandar el JavaScript a evaluar
- 4.Leer el resultado
- 5.Cerrar el WebSocket
Para una cadena de evaluaciones — por ejemplo, el agente inspeccionando una página paso a paso — eso eran ~1.5 s por evaluación. Un flujo típico de "mira esta página y cuéntame" iba doloroso de lento.
El cambio de v0.14.0: un WebSocket persistente por supervisor, compartido entre todas las llamadas de tool de browser. El handshake CDP ocurre una vez por sesión; las evaluaciones siguientes se saltan los pasos 1–2 enteros y solo mandan el payload.
Resultado: la latencia por llamada bajó de ~1.5 s a ~8 ms. Eso es ~180×.
La lección es general. Cualquier sitio donde tu agente haga N llamadas a tools y cada una abra una conexión nueva: el pool de conexiones gana al paralelismo para cargas a ritmo de chat. El trabajo total está en montar la conexión, no en el trabajo en sí.
Caché de prompt de Claude de 1 hora entre sesiones (#23828, #25434, #24778)
La caché de prompt de Claude (función de la API de Anthropic) te deja marcar un trozo de contexto como cacheable. Las requests siguientes dentro del TTL — históricamente 5 minutos — reutilizan el prefix cacheado a coste y latencia mucho menores.
Antes de v0.14.0, Hermes usaba esto dentro de una sesión: el system prompt + los skills activos se cacheaban, los aciertos dentro de la misma conversación iban más rápidos y baratos. Pero al ejecutar /new, la caché se invalidaba y la siguiente conversación empezaba en frío.
El trabajo de v0.14.0, repartido en tres PRs, extiende el TTL de la caché a 1 hora y hace que la clave de caché sobreviva a /new. La primera respuesta en una sesión nueva se beneficia de una caché caliente de tu sesión anterior. Para quien hace muchas conversaciones cortas al día, esta es una victoria de coste y latencia con peso.
La caché también cubre la bifurcación de revisión de memory en background (#25434) — el proceso periódico que revisita y consolida tu archivo de memory ahora pega contra la misma caché de prompt en lugar de pagar precio entero cada iteración.
Un arreglo complementario en este área: la clave de caché de prompt usa un timestamp solo de fecha, así que las cachés no se rompen al cruzar zonas horarias. Logs ruidosos del roundtrip gateway-DB redondean la mejora de observabilidad.
Las herramientas que sacaron las victorias
¿Cómo encontraron los autores esos hot paths concretos? Dos respuestas:
- •Profiling del arranque en frío sobre instalación real. Corrieron
hermescon cronómetro y siguieron qué imports tardaban más. Y fueron a por ellos uno a uno. - •Reportes de "Hermes va lento" de usuarios. Que la pantalla
hermes toolsAll-Platforms iba lenta era un bug report concreto; una vez aflorado, el arreglo era directo.
No hay magia. Las victorias se encuentran con python -X importtime, cProfile y escuchando a la gente quejarse.
Lecciones para cualquier autor de agente
Si estás construyendo un agente, la ola de v0.14.0 generaliza a unas pocas reglas:
- 1.No importes lo que no uses. Lazy-import cada SDK de adaptador y de provider. El grafo de imports es tu arranque en frío.
- 2.Cachea cualquier cosa estable. Índice de skills, catálogo de modelos, tokens de auth. Refetchea solo cuando sepas que está vieja.
- 3.Junta las conexiones en un pool. Si llamas a una API o a un servidor CDP más de una vez por sesión, sostén la conexión.
- 4.Lanza sondas independientes en paralelo. Chequeos de doctor, health checks, lo que sea donde el orden no importe.
- 5.No renderices UI que no haga falta. Banners de bienvenida, salida decorativa — sáltala en rutas no interactivas.
Ninguna de estas es nueva. Es el manual estándar de rendimiento para cualquier CLI. Lo interesante de v0.14.0 es que aplicaron el manual entero en una sola ventana de release y el resultado se notó en el momento en que la gente actualizó.
Si tu Hermes se sentía pesado a primeros de mayo, v0.14.0 es la release donde se acabó el camino en frío.