Hlídač, který nepozná práci od zamrznutí

Stalo se 2. 8. 2026 v 6:17 ráno.

Teze: Časovač nečinnosti měří ticho, ne nečinnost. U přemýšlejícího modelu volaného bez streamu jsou to dvě různé věci — a rozdíl mezi nimi je celý rozdíl mezi „zaseklo se to" a „skoro to dopočítalo".

Co přišlo ráno

⚠️ Cron „Konsolidace deníků" failed: provider timeout. Fallback chain was exhausted or unavailable.

Ta hláška říká „poskytovatel neodpověděl". Neodpověděl je ale silné slovo pro něco, co celou dobu počítalo.

Chybná stopa

Předchozí večer se měnilo rozvržení modelů v paměti — z 21 GB rezidentních vah se stalo 39,8 GB. Selhání přišlo v prvním nočním běhu po té změně. Nabízelo se to samo: paměťový tlak, odkládání, zpomalení.

Claude Code to napsal jako hypotézu. Byla špatná.

Vyvrátil ji jeden řádek z logu inferenčního serveru:

[thinkingcap-27b] Accumulated 5128 tokens in reasoning content
slot release: task 1300 | n_tokens = 46817, truncated = 0

Model nezamrzl. Byl 5 128 tokenů hluboko v přemýšlení nad kontextem o 46 817 tokenech a na konci vygeneroval tool calls — tedy dopočítal a chystal se pokračovat. Zabili ho těsně před cílem.

Paměť se pro jistotu ještě přeměřila, protože vyloučit hypotézu logem je slabší než ji vyloučit měřením:

Rozdíl v šumu. Rezidentní druhý model nestál nic.

Skutečná příčina

Plánovač má hlídač nečinnosti, výchozí limit 600 sekund. Ve zdrojáku u něj stojí, čím se obnovuje:

Uses the agent's built-in activity tracker (updated by _touch_activity() on every tool call, API call, and stream delta).

Tři zdroje signálu. Jeden dlouhý tah nevolá nástroj ani nezačíná nové API volání, takže zbývá jediný — stream delta. A volání bylo nestreamované:

last_activity=waiting for non-streaming API response | iteration=4/150 | tool=none

Žádné delty, žádný signál, žádný život. Po 601 sekundách hlídač usoudil, že je po pacientovi.

Aritmetika sedí: 46 817 tokenů prefillu plus 5 128 tokenů generování při ~13 tok/s je zhruba 400 sekund jen na psaní, k tomu prefill. Jeden legitimní tah přetekl limit určený pro celou úlohu.

Proč to nebyl problém dřív

Protože se sešly tři věci, z nichž každá sama o sobě je v pořádku:

1. Přemýšlející model — 5 128 tokenů, které nikam neodejdou, dokud nejsou hotové
2. Nestreamované volání — jediný kanál, kterým mohl dát o sobě vědět, byl vypnutý
3. Rostoucí vstup — úloha čte klouzavé okno posledních dnů, takže se nafukuje sama

Limit 600 s byl přiměřený, dokud tah trval desítky sekund. Nikdo ho nezvedl, protože se nic nezměnilo — jen přibylo dat.

Oprava

Obě podmínky té pasti jsou výchozí nastavení Hermes Agent v0.19.1 (2026.7.30): hlídač nečinnosti má 600 s a streaming.enabled je false. Nikdo z nás to nezapnul ani nezhoršil — sešlo se to samo s modelem, který dlouho přemýšlí, a se vstupem, který roste.

HERMES_CRON_TIMEOUT=1800. Jeden tah smí trvat půl hodiny.

Je to ale odklad, ne řešení. Vstup poroste dál, protože roste sám od sebe. Správnější pořadí je: nejdřív zmenšit vstup, teprve pak zvedat limit — a ještě lépe zapnout streamování, aby hlídač měřil to, co měřit má.

Metodická poznámka

Hypotéza o paměti padla dřív, než se kdokoli podíval do logu inferenčního serveru — dívat se jen do logu vlastní aplikace nestačí, když ta aplikace o druhé straně nic neví. Vyvrátil ji jeden řádek, který měl být na stole dřív než domněnka.