"Context compression timed out before it could commit" significa che il modello di riepilogo di Hermes — quello sotto auxiliary.compression, non il modello principale — non ha fatto progressi prima che il budget di compressione di Hermes si esaurisse, e il turno è stato interrotto senza inviare la chiamata principale. Dipende dalla versione: abbiamo riprodotto entrambi i suoi messaggi su Hermes Agent v0.21.3 e siamo usciti dalla situazione facendo rispondere il summariser e ritentando nella stessa sessione, mentre nella v0.21.5 lo stesso blocco ha prodotto una lunga attesa invece dell’errore. Testato il 1° ottobre 2026 con un sostituto di registrazione per entrambi i modelli, non con un provider reale.
Se stai configurando Hermes sul tuo endpoint anziché eseguire il debug, inizia da Hermes Agent con un’API personalizzata.
I due messaggi e ciò che ciascuno indica
| Cosa vedi | Quando è comparso | Chiamata principale inviata? |
|---|---|---|
| "La compressione del contesto è scaduta prima di poter essere confermata mentre la richiesta conteneva ancora circa 83.485 token. La chiamata al provider non è stata inviata. Esegui /compress e attendi il completamento, quindi ritenta." | v0.21.3, modello di riepilogo silenzioso, richiesta (~83.485 token) più grande della finestra di 64.000 token del modello | No |
| "La compressione del contesto è scaduta senza ridurre questa conversazione. Nessun messaggio è stato eliminato. Avvia una nuova sessione con /new oppure controlla auxiliary.compression prima di ritentare /compress." | v0.21.3, modello di riepilogo silenzioso, richiesta (~57.489 token) oltre la soglia di compressione di 54.400 token ma all’interno della finestra | No |
La quantità di token nel primo messaggio è la stima di Hermes della richiesta che avrebbe inviato. Entrambi i turni sono terminati nel log come reason=context_compression_timeout con api_calls=0, dopo un avviso del tipo "Context compression made no progress for 5.0s" — cinque secondi perché il test impostava compression.context_timeout_seconds: 5 per mantenere brevi le esecuzioni; il valore predefinito è 120.
La versione in uso determina cosa succede
| Stato del summariser | v0.21.3 (14 settembre) | v0.21.5 (24 settembre) |
|---|---|---|
| Silenzioso, richiesta all’interno della finestra | Turno interrotto — secondo messaggio sopra | Ha atteso (blocchi di 30 s e 90 s), compresso 9 messaggi in 5 e inviato la richiesta |
| Silenzioso, richiesta oltre la finestra | Turno interrotto — primo messaggio sopra | Non eseguito con un summariser silenzioso; la documentazione vincola questo caso a un budget di inattività e a un riepilogo di fallback deterministico |
| Errori di risposta (404) | Due tentativi, compressione ignorata, richiesta inviata (testata all’interno della finestra) | Lo stesso; è stata inviata anche una richiesta oltre la finestra, che un provider reale rifiuterebbe |
| Reattivo | Compresso e inviato | Compresso e inviato |
Il limite è nel codice sorgente. Nella v0.21.4 (tag v2026.9.21), la funzione che interrompe un turno dopo una compressione scaduta è stata limitata alle richieste oltre la finestra del modello, citando le issue #113646 e #114594; la v0.21.3 interrompe ogni richiesta. La documentazione di configurazione della v0.21.5 aggiunge poi che l’attesa della compressione "is floored at the auxiliary compression request's own timeout (auxiliary.compression.timeout, minimum 300s)" — per questo la nostra impostazione di cinque secondi non ha avuto effetto. Quindi, in una build attuale, un summariser lento costa minuti di attesa anziché un errore, mentre uno inattivo viene ignorato.
Diagnosi più breve
- Controlla la versione con
hermes --version. Nella v0.21.3 o precedente, entrambi i messaggi sopra rappresentano il comportamento previsto per un summariser bloccato. - Trova il summariser in
~/.hermes/logs/agent.log: una riga "Auxiliary compression: using <provider> (<model>) at <url>" indica il modello e l’endpoint che hanno eseguito il timeout. Senza un bloccoauxiliary.compression, eredita il modello principale. - Leggi la riga del trigger, "Pre-API compression: ~N request tokens >= T threshold (context=W)". Se N è maggiore di W, il turno non può essere inviato senza riduzione in alcuna versione.
- Controlla la finestra del summariser. La documentazione di Hermes richiede che sia almeno grande quanto quella del modello principale, perché gli viene inviata l’intera parte centrale della conversazione.
Recupero verificato
In ogni caso v0.21.3 sopra, riavviare il sostituto con un summariser che risponde e inviare un altro turno nella stessa sessione (--resume) ha prodotto una risposta normale, mantenendo intatta la conversazione. In pratica, ciò significa una delle seguenti cose: indirizzare auxiliary.compression verso un modello veloce raggiungibile, correggere l’endpoint a cui punta oppure aumentare compression.context_timeout_seconds se il summariser è lento ma funziona correttamente — per esempio un modello locale. Quindi ritenta nella stessa sessione.
# ~/.hermes/config.yaml — the summariser is its own model, with its own budget
auxiliary:
compression:
base_url: https://api.kunavo.com/v1 # overrides provider; any OpenAI-compatible endpoint
api_key: sk-kn-...
model: claude-haiku-4-5 # fast, and a context window >= your main model's
timeout: 300
compression:
context_timeout_seconds: 120 # inactivity budget for the summary (default)
context_total_ceiling_seconds: 600Due elementi non sono stati testati: le superfici Desktop e messaging-gateway di Hermes, che hanno una propria compressione di igiene con budget diversi, e un provider reale che rifiuti una richiesta oltre la finestra. Le esecuzioni erano turni hermes chat -Q one-shot.
Quanto costa
Un turno interrotto non invia alcuna richiesta al modello principale, quindi il modello principale non addebita nulla per esso. La richiesta di riepilogo è stata inviata — circa 19.000 caratteri di prompt in queste esecuzioni — e un provider la addebita se alla fine viene completata. Il ritentativo paga quindi un riepilogo e una chiamata principale. Un modello di riepilogo piccolo e veloce riduce sia l’attesa sia questo sovraccosto; su Kunavo, Claude Haiku 4.5 è elencato a $0,70 per milione di token di input e $3,50 per milione di token di output, con addebito per token da un saldo prepagato. Nessuno di Kunavo ha eseguito Hermes sull’endpoint di Kunavo; le esecuzioni qui hanno usato un sostituto locale.
Domande frequenti
Cosa significa "Context compression timed out before it could commit" in Hermes?
Hermes ha provato a ridurre la conversazione prima di inviare il tuo turno, il modello di riepilogo utilizzato non ha prodotto alcun avanzamento entro il tempo disponibile e la richiesta era troppo grande per essere inviata senza ridurla — quindi Hermes ha interrotto il turno senza chiamare affatto il modello principale. Riprodotto su Hermes Agent v0.21.3 con un summariser bloccato e una richiesta di 83.485 token verso una finestra da 64.000 token; la riga di log del turno riportava api_calls=0. Il problema non riguarda il modello principale né il suo timeout API. Riguarda il summariser: il modello indicato sotto auxiliary.compression in config.yaml.
Come risolvo un timeout della compressione del contesto in Hermes?
Fai in modo che il summariser risponda, quindi riprova nella stessa sessione. Nella riproduzione, indirizzare auxiliary.compression verso un modello reattivo e inviare il turno successivo nella stessa sessione ha funzionato ogni volta su v0.21.3, mantenendo intatta la cronologia — il messaggio stesso specifica che nessun messaggio è stato eliminato. Anche l'aggiornamento cambia il comportamento: da v0.21.4 una compressione scaduta non interrompe più una richiesta che rientra ancora nella finestra del modello e, in v0.21.5, l'attesa del riepilogo ha come limite minimo il timeout della richiesta del summariser, almeno 300 secondi. Anche avviare una nuova sessione con /new funziona, al costo del contesto della conversazione.
Il timeout della compressione Hermes è stato risolto?
In parte, e ha cambiato forma. Fino alla v0.21.3 (14 settembre 2026), qualsiasi compressione preflight scaduta interrompeva il turno. La v0.21.4 (21 settembre) interrompe solo una richiesta che supera la finestra di contesto del modello. Nella v0.21.5 (24 settembre), un summariser bloccato per 30 e poi 90 secondi non ha interrotto affatto il turno: Hermes ha atteso, compresso e inviato la richiesta; quindi, in una versione attuale, il sintomo di un summariser lento è una lunga pausa, non questo errore. Un summariser inattivo anziché lento è diverso: viene ritentato, poi ignorato, e il turno prosegue senza compressione.
Aumentare HERMES_API_TIMEOUT è utile?
No. Quella variabile governa la chiamata al modello principale, con un valore predefinito di 1.800 secondi. La compressione ha budget propri in config.yaml: compression.context_timeout_seconds (un budget di inattività, predefinito di 120 secondi), compression.context_total_ceiling_seconds (predefinito di 600) e auxiliary.compression.timeout per la richiesta di riepilogo stessa. La documentazione di Hermes aggiunge un requisito altrettanto importante quanto la velocità: la finestra di contesto del modello di riepilogo deve essere almeno grande quanto quella del modello principale, perché riceve l’intera parte centrale della conversazione.
Il turno scaduto ha avuto un costo?
Not on the main model: the turn ended before the main call was sent. The summary request was sent, though, and a summariser that eventually finishes is billed by its provider like any other call — in the runs here the summary prompt was about 19,000 characters. The retry then pays for one summary and one main call. That is why pointing compression at a small, fast model is cheaper as well as quicker: on Kunavo, Claude Haiku 4.5 lists at $0,70 per million input tokens.
Riprodotto il 1° ottobre 2026 con Hermes Agent v0.21.3 (tag v2026.9.14) e v0.21.5 (tag v2026.9.24), installati dal codice sorgente delle rispettive versioni, contro un sostituto locale che registrava le richieste e serviva sia il modello principale sia quello di riepilogo (risposte trattenute per un modello di riepilogo bloccato, 404 per uno non funzionante), con una finestra di 64.000 token e quattro turni ripresi di contenuto riempitivo prima del turno di test. Il limite tra le versioni è stato ricavato da agent/turn_context.py ai tag v2026.9.14, v2026.9.21 e v2026.9.24, mentre i budget provengono dalla documentazione di configurazione di ciascun tag. Il sostituto non è un modello né un provider: accetta richieste di qualsiasi dimensione, quindi gli errori di contesto lato provider non sono stati riprodotti.