Jak Hermes Agent v0.14.0 zerżnął 19 sekund z cold startu i przyspieszył operacje browsera 180×

v0.14.0 wypuścił stos pracy nad wydajnością, który złożony razem sprawia, że Hermes Agent czuje się jak inny program. Trzy nagłówki z release notes:

• •~19 sekund mniej z cold startu. Rozsiane po grafie importów, checkach doctora, lookupie katalogu modeli, welcome-bannerze.
• •180× szybsze browser_console. Jedno trwałe połączenie CDP zamiast otwierania nowej sesji DevTools na każdy call.
• •Międzysesyjny godzinny prompt-cache Claude. /new nie traci ci ciepłego prefix-cache.

Żadna z tych rzeczy to nie „przepisanie od zera". Każda to seria małych, lokalizowalnych PR-ów, które celują w konkretne hot pathy. Ten wpis to rozpiska PR-po-PR — co było wolne, co się zmieniło i jakie wnioski generalizują się dla każdego autora agenta.

Punkt wyjścia

Jeśli odpalałeś hermes na początku maja 2026, ścieżka cold startu wyglądała tak:

1. 1.Wstaje interpreter Pythona (~100 ms)
2. 2.import hermes ciągnie resztę grafu importów (~5–10 s)
3. 3.Plugin-discovery hermesa skanuje zainstalowane pluginy (~2–3 s)
4. 4.hermes doctor puszcza sondy łączności API po kolei (~3–5 s)
5. 5.Skills-index się ładuje, często znowu ciągnąc z sieci (~2–4 s)
6. 6.Renderuje się welcome-banner (~1 s)
7. 7.Pojawia się prompt

Czyli 15–25 sekund, zanim możesz zacząć pisać. Dość długo, żeby zerwać flow. Performance-fala v0.14.0 atakuje każdy z tych kroków.

Fala cold startu (10+ PR-ów)

Cache skilli + lazy importy adapterów (#22138)

Pojedyncze największe zwycięstwo. Dwie równoległe zmiany:

1. 1.Skills-index zcache-owany na dysk. Wcześniej: każde wywołanie hermes znowu czytało katalog skilli i odpalało lekką indeksację. Teraz: index żyje w pliku cache; przebudowywany tylko, kiedy zmienia się katalog (check mtime).
2. 2.Ciężkie SDK adapterów lecą lazy. Wcześniej: import hermes ciągnął import SDK Feishu, SDK WhatsAppa, każdego dostawcy voice/TTS, każdego SDK do image-gen. Teraz: każdy odroczony do pierwszego użycia. Jeśli nigdy nie używasz Feishu, SDK Feishu nigdy się nie ładuje.

Obie zmiany w #22138 ściągnęły ~5–8 sekund. Wzorzec lazy-import to nieopiewany bohater — jest mechanicznie nakładany na cały codebase, ale nie pojawia się jako jeden dramatyczny PR.

Pomijaj agresywne plugin-discovery na znanych subkomendach (#22120)

Jeśli odpalasz hermes config set X Y, plugin-discovery jest niepotrzebne. Tak samo dla hermes tools, hermes model, hermes doctor. Dispatcher teraz robi zwarcie w plugin-discovery, kiedy komenda to znany built-in. ~2 sekundy zaoszczędzone na większości wywołań CLI.

Lookup models.dev cache-first (#22808)

Hermes bije do models.dev po kanoniczny katalog modeli. Przed v0.14.0 każdy start hermesa robił call HTTP. Teraz: najpierw czyta z cache na dysku; refetch dopiero, kiedy stale (>24 h). Cache hit to ~5 ms zamiast ~200–500 ms (sieciowy round-trip).

Równoległe sondy łączności API w hermes doctor (#22766)

hermes doctor sprawdzał „czy dosięgnę Nous Portal, OpenRouter, Anthropic, OpenAI" sekwencyjnie. Teraz: asyncio.gather je razem, plus wywalono sondowanie IMDS (instance metadata service), które na niechmurowych maszynach taimowało. ~3–5 sekund zerżnięte z doctora w typowym przypadku.

chat -q pomija welcome-banner (#22904)

Jeśli jesteś w trybie pojedynczego zapytania (hermes chat -q "what's the time"), welcome-banner to szum. v0.14.0 pomija jego rendering. ~1 sekunda z powrotem dla skryptowanych / zautomatyzowanych use case'ów.

Odroczone importy w całym grafie

Długi ogon PR-ów, każdy odracza jeden ciężkawy import:

• •google-cloud w adapterze google_chat — ładuje się dopiero, kiedy google chat jest po raz pierwszy używany (#22681)
• •QQAdapter, YuanbaoAdapter — odroczenie na poziomie modułu przez PEP 562 (#22790)
• •httpx w adapterze teams — dopiero przy pierwszym wywołaniu webhooka (#22831)
• •fal_client — dopiero przy pierwszej generacji obrazu (#22859)

Każdy PR mały. Razem to kolejne 2–4 sekundy.

Cache auth-a Nous i ładowań .env (#25341)

Ekran All-Platforms w hermes tools robił sondy auth-a per-platforma synchronicznie. To zleciało z 14 sekund do mniej niż 1,5, kiedy wjechał cache. Ekran nadal działa tak samo; tylko nie pali 14 s czasu sieciowego na każde wywołanie.

Wynik netto

Dodaj zwycięstwa i wychodzi nagłówkowe 19 sekund. Z osobna nic nie jest dramatyczne; razem program robi się responsywny.

Historia 180× w browser_console (#23226)

Tool browsera w Hermesie używa Chrome DevTools Protocol (CDP), żeby sterować headless Chrome'em. Przed v0.14.0 każde wywołanie browser_console robiło to:

1. 1.Otwórz nowy WebSocket CDP do Chrome'a
2. 2.Czekaj na handshake (~1–2 s)
3. 3.Wyślij JavaScript do oceny
4. 4.Wczytaj wynik
5. 5.Zamknij WebSocket

Dla łańcucha ocen — powiedzmy, agent inspekcjonuje stronę krok po kroku — to było ~1,5 s na ocenę. Typowy flow „popatrz na tę stronę i mi opowiedz" był boleśnie wolny.

Zmiana w v0.14.0: jeden trwały WebSocket per supervisor, dzielony między wszystkie wywołania toola browsera. Handshake CDP dzieje się raz na sesję; kolejne oceny w ogóle pomijają kroki 1–2 i lecą tylko z payloadem.

Wynik: latencja per-call zleciała z ~1,5 s do ~8 ms. Czyli ~180×.

Lekcja jest ogólna. Wszędzie tam, gdzie twój agent robi N wywołań toola i każde otwiera nowe połączenie: dla obciążeń w tempie czatu connection pooling bije paralelizm. Cała robota siedzi w setupowaniu połączenia, nie w samej robocie.

Międzysesyjny godzinny prompt-cache Claude (#23828, #25434, #24778)

Prompt-cache Claude (feature API Anthropica) pozwala oznaczyć kawałek kontekstu jako cacheable. Kolejne requesty w TTL — historycznie 5 minut — reużywają zcache-owanego prefixa za dużo niższy koszt i latencję.

Przed v0.14.0 Hermes używał tego wewnątrz sesji: system-prompt + aktywne skille się cache-owały, hity w tej samej rozmowie były szybsze i tańsze. Ale kiedy odpaliłeś /new, cache był unieważniany, a kolejna rozmowa startowała na zimno.

Robota v0.14.0, rozsiana po trzech PR-ach, rozciąga TTL cache'u na 1 godzinę i sprawia, że klucz cache'u przeżywa /new. Pierwsza odpowiedź w świeżej sesji ma zysk z ciepłego cache'u z poprzedniej sesji. Dla osób, które prowadzą dużo krótkich rozmów dziennie, to konkretne zwycięstwo na koszcie i latencji.

Cache pokrywa też gałąź background memory review (#25434) — okresowy proces, który rewiduje i konsoliduje twój memory-plik, teraz uderza w ten sam prompt-cache, zamiast płacić pełną cenę na każdej iteracji.

Komplementarny perf-fix w tym obszarze: klucz prompt-cache'u używa timestampa tylko-z-datą, żeby cache nie pękały przez strefy czasowe. Głośne logowanie round-tripów gateway-DB dopełnia obraz pod kątem observability.

Narzędzia, które wyciągnęły zwycięstwa na powierzchnię

Jak autorzy znaleźli te konkretne hot pathy? Dwie odpowiedzi:

• •Profilowanie cold startu na prawdziwej instalacji. Odpalali hermes pod stoperem i śledzili, które importy trwały najdłużej. Potem po kolei pakowali się w nie.
• •Reporty userów typu „Hermes mi się ślimaczy". To, że ekran All-Platforms w hermes tools był wolny, to był konkretny bug report; gdy wypłynął, fix był prosty.

Żadnej magii. Te zwycięstwa są znajdowalne z python -X importtime, cProfile i słuchaniem ludzi, którzy narzekają.

Wnioski dla każdego autora agenta

Jeśli budujesz agenta, performance-fala v0.14.0 generalizuje się w kilka reguł:

1. 1.Nie importuj tego, czego nie używasz. Lazy-import każdego adaptera i SDK providera. Graf importów to twój cold start.
2. 2.Cache-uj wszystko, co stabilne. Skills-index, katalog modeli, tokeny auth-a. Refetch dopiero, kiedy wiesz, że jest stale.
3. 3.Pulpiruj połączenia. Jeśli wołasz API albo CDP-serwer więcej niż raz na sesję, trzymaj połączenie.
4. 4.Niezależne sondy puszczaj równolegle. Checki doctora, healthchecki, cokolwiek, gdzie kolejność nie ma znaczenia.
5. 5.Nie renderuj UI, którego nie potrzebujesz. Welcome-bannery, dekoracyjny output — pomijaj w nieinteraktywnych ścieżkach.

Żadna z nich nie jest nowa. To standardowy performance playbook dla dowolnego CLI. Ciekawa rzecz w v0.14.0 to to, że puścili cały playbook w jednym oknie wydania i wynik było czuć w momencie, kiedy userzy zaktualizowali.

Jeśli twój Hermes na początku maja czuł się kruchy, v0.14.0 to wydanie, w którym zimna ścieżka znikła.

Dalsza lektura

• •Release notes v0.14.0 — sekcja performance
• •PR #22138 — cache skilli + lazy importy adapterów
• •PR #23226 — 180× browser_console
• •PR #23828 — międzysesyjny prompt-cache
• •Hermes Agent na GitHubie