A v0.14.0 entregou uma pilha de trabalho de performance que, somada, faz o Hermes Agent parecer um programa diferente. As três manchetes das release notes:
- •~19 segundos a menos no cold start. Espalhados pelo grafo de imports, pelos checks do doctor, pela consulta ao catálogo de modelos e pelo banner de boas-vindas.
- •
browser_console180× mais rápido. Uma conexão CDP persistente em vez de abrir uma sessão de DevTools nova por chamada. - •Cache de prompt do Claude de 1 hora entre sessões. O
/newnão te tira o prefixo quente do cache.
Nenhum desses é uma "reescrita do zero". Cada um é uma série de PRs pequenos e localizáveis que miraram hot paths específicos. Este post é o desmonte PR a PR — o que tava lento, o que mudou e quais lições servem pra qualquer autor de agente.
O ponto de partida
Se você abriu o hermes no começo de maio de 2026, o caminho de cold start era assim:
- 1.Interpretador Python sobe (~100 ms)
- 2.
import hermesdispara o resto do grafo de imports (~5–10 s) - 3.A descoberta de plugins do
hermesvarre os plugins instalados (~2–3 s) - 4.
hermes doctorroda sondas de conectividade de API em sequência (~3–5 s) - 5.Índice de skills carrega, frequentemente puxando da rede de novo (~2–4 s)
- 6.Banner de boas-vindas renderiza (~1 s)
- 7.O prompt aparece
São 15–25 segundos antes de você conseguir digitar. Tempo suficiente pra quebrar o fluxo. A onda de performance da v0.14.0 ataca cada um desses passos.
A onda de cold start (10+ PRs)
Cache de skills + imports lazy de adapter (#22138)
A maior vitória isolada. Duas mudanças paralelas:
- 1.Índice de skills cacheado em disco. Antes: cada invocação do
hermesrelia o diretório de skills e rodava uma indexação leve. Agora: o índice vive num arquivo de cache ; só é reconstruído quando o diretório muda (checagem por mtime). - 2.SDKs pesados de adapter passam pra lazy. Antes: dar import em
hermesdisparava o import do SDK do Feishu, do WhatsApp, de cada provider de voice/TTS, de cada SDK de geração de imagem. Agora: cada um é diferido pro primeiro uso. Se você nunca usa Feishu, o SDK do Feishu nunca carrega.
As duas mudanças estão na #22138 e cortaram ~5–8 segundos. O padrão lazy-import é o herói não premiado — aplicado mecanicamente em todo o codebase mas não aparece como um único PR dramático.
Pular a descoberta agressiva de plugin em subcomandos conhecidos (#22120)
Se você roda hermes config set X Y, não precisa de descoberta de plugin. Mesmo pra hermes tools, hermes model, hermes doctor. O dispatcher agora encurta a descoberta de plugin quando o comando é um built-in conhecido. ~2 segundos economizados na maior parte das invocações de CLI.
Lookup cache-first no models.dev (#22808)
O Hermes consulta o models.dev pra ter o catálogo canônico de modelos. Antes da v0.14.0, cada start do hermes fazia o HTTP call. Agora: lê primeiro do cache em disco ; só refaz fetch quando passa o prazo (>24 h). O cache hit é ~5 ms em vez de ~200–500 ms (roundtrip de rede).
Sondas paralelas de API no hermes doctor (#22766)
O hermes doctor checa "consigo alcançar Nous Portal, OpenRouter, Anthropic, OpenAI" em sequência. Agora: asyncio.gather joga tudo de uma vez, e a sonda IMDS (instance metadata service) que dava timeout em máquinas não-cloud foi tirada. ~3–5 segundos cortados do doctor no caso típico.
chat -q pula o banner de boas-vindas (#22904)
Se você tá em modo single-query (hermes chat -q "what's the time"), o banner de boas-vindas é ruído. A v0.14.0 pula a renderização. ~1 segundo de volta pra casos de uso scriptados / automação.
Imports diferidos pelo grafo afora
Uma cauda longa de PRs, cada um diferindo um import pesado:
- •
google-cloudno adaptergoogle_chat— só carrega quando o google chat é usado pela primeira vez (#22681) - •
QQAdapter,YuanbaoAdapter— diferimento em nível de módulo via PEP 562 (#22790) - •
httpxno adapter de teams — só na primeira chamada de webhook (#22831) - •
fal_client— só na primeira geração de imagem (#22859)
Cada PR é pequeno. Juntos, mais 2–4 segundos.
Cache da auth Nous e dos loads .env (#25341)
A tela All-Platforms do hermes tools fazia sondas de auth por plataforma em sequência. Quando o cache pousou, isso caiu de 14 segundos pra menos de 1,5. A tela funciona igual ; só não queima 14 s de rede em cada invocação.
Resultado líquido
Soma as vitórias e dá o headline de 19 segundos. Nenhuma é dramática individualmente ; juntas, o programa fica responsivo.
A história do 180× no browser_console (#23226)
A tool de browser no Hermes usa Chrome DevTools Protocol (CDP) pra dirigir um Chrome headless. Antes da v0.14.0, cada avaliação do browser_console fazia assim:
- 1.Abrir um novo WebSocket CDP com o Chrome
- 2.Esperar o handshake (~1–2 s)
- 3.Mandar o JavaScript pra avaliar
- 4.Ler o resultado
- 5.Fechar o WebSocket
Pra uma cadeia de avaliações — digamos, o agente inspecionando uma página passo a passo — isso era ~1,5 s por avaliação. Um fluxo típico "olha essa página e me conta" era dolorosamente lento.
A mudança da v0.14.0: um WebSocket persistente por supervisor, compartilhado entre todas as chamadas da tool de browser. O handshake CDP acontece uma vez por sessão ; as avaliações seguintes pulam os passos 1–2 inteiros e mandam só o payload.
Resultado: latência por chamada caiu de ~1,5 s pra ~8 ms. Isso é ~180×.
A lição é geral. Em qualquer lugar onde seu agente faz N chamadas de tool e cada uma abre uma conexão nova: pooling de conexão ganha de paralelismo pra cargas em ritmo de chat. O trabalho todo tá no setup da conexão, não no trabalho em si.
Cache de prompt do Claude de 1 hora entre sessões (#23828, #25434, #24778)
O cache de prompt do Claude (feature da API da Anthropic) deixa você marcar um pedaço de contexto como cacheável. As requisições seguintes dentro do TTL — historicamente 5 minutos — reusam o prefixo cacheado com custo e latência bem menores.
Antes da v0.14.0, o Hermes usava isso dentro de uma sessão: o system prompt + skills ativos eram cacheados, hits dentro da mesma conversa eram mais rápidos e baratos. Mas quando você dava /new, o cache era invalidado, e a próxima conversa começava do frio.
O trabalho da v0.14.0, em três PRs, estendeu o TTL do cache pra 1 hora e fez a chave do cache sobreviver ao /new. A primeira resposta numa sessão nova se beneficia de um cache ainda quente da sessão anterior. Pra quem faz várias conversas curtas por dia, é uma vitória relevante em custo e latência.
O cache também cobre a revisão de memory em background (#25434) — o processo periódico que revisita e consolida o seu arquivo de memory agora bate no mesmo cache de prompt em vez de pagar tarifa cheia a cada iteração.
Um fix de performance complementar nessa área: a chave do cache de prompt usa um timestamp só de data, daí os caches não estouram entre fusos. Logs barulhentos de roundtrip gateway-DB também foram arrumados, fechando a melhoria de observabilidade.
As ferramentas que destacaram as vitórias
Como os autores acharam esses hot paths específicos? Duas respostas:
- •Profiling de cold start numa instalação real. Rodaram o
hermescronometrado e seguiram quais imports demoravam mais. Aí foram cobrir um por um. - •Reports de usuário "Hermes parece lento". A tela All-Platforms do
hermes toolsestar lenta era um bug report específico ; uma vez aflorado, o fix foi direto.
Sem mágica. As vitórias dá pra achar com python -X importtime, cProfile e escutando gente reclamar.
Lições pra qualquer autor de agente
Se você tá construindo um agente, a onda da v0.14.0 generaliza em algumas regras:
- 1.Não importa o que você não usa. Lazy-importa cada SDK de adapter e provider. O grafo de imports é seu cold start.
- 2.Cacheia qualquer coisa estável. Índice de skills, catálogo de modelos, tokens de auth. Refaz fetch só quando souber que tá velho.
- 3.Pool de conexões. Se você chama uma API ou servidor CDP mais de uma vez por sessão, segura a conexão.
- 4.Sondas independentes em paralelo. Checks de doctor, health checks, qualquer coisa em que a ordem não importa.
- 5.Não renderiza UI que você não precisa. Banners de boas-vindas, saída decorativa — pula em caminhos não interativos.
Nada disso é novo. É o playbook padrão de performance pra qualquer CLI. O interessante da v0.14.0 é que aplicaram o playbook inteiro numa janela só de release, e o resultado foi sentido na hora em que a galera atualizou.
Se seu Hermes parecia pesado no começo de maio, a v0.14.0 é o release em que o caminho frio sumiu.