ZeroClaw non riprende mai uno stream interrotto. Il fatto che reinvii il turno dipende dal numero di candidati presenti nel profilo e, nell'unica release attuale, non corrisponde esattamente a quanto promette la documentazione. La documentazione di ZeroClaw per la v0.8.5, pubblicata il 5 settembre 2026, afferma che uno stream che fallisce prima di qualsiasi output viene ritentato senza streaming, mentre uno che fallisce dopo l'output non viene mai ripetuto. Eseguito il 1° ottobre 2026 contro un endpoint che ha interrotto lo stream durante la risposta, il client terminale della v0.8.5 ha fatto qualcosa di più semplice: con un solo candidato non ha eseguito alcun nuovo tentativo, né prima né dopo la comparsa del testo; con un secondo candidato ha reinviato il turno, senza streaming, a quel secondo modello, anche dopo che parte della risposta era già sullo schermo. Il recupero guidato dopo un output parziale è una richiesta di funzionalità aperta che non ha ancora ricevuto l'approvazione della progettazione. La domanda utile, quindi, non è come fare in modo che ZeroClaw riprovi, ma se per te è sicuro reinviare il turno e quale costo ha già comportato il tentativo interrotto.
Due note sull'ambito prima che tutto questo possa essere applicato. Ciò che è stato eseguito è circoscritto: il binario della release v0.8.5 nella modalità terminale interattiva, un endpoint compatibile con OpenAI e un server di test locale che ha chiuso intenzionalmente lo stream: i risultati sono riportati di seguito. Non sono stati eseguiti canali, WebSocket del gateway, RPC, ACP, lo slot Anthropic né vere interruzioni dei provider. Ogni altra affermazione è ricavata dal repository al tag di rilascio v0.8.5, dalla documentazione fissata alla versione in docs.zeroclaw.com/v0.8.5/ o da issue upstream datate, tutto al 21 settembre 2026. E fissa tu stesso quell'URL: il README indirizza i lettori al percorso /master/, il cui HEAD è sedici giorni avanti rispetto alla release e la contraddice proprio su questo argomento, mentre /latest/ restituisce 404. Qui ZeroClaw indica il runtime zeroclaw-labs/zeroclaw; se non sei certo che sia quello in esecuzione, ZeroClaw vs OpenClaw lo distingue dai progetti e fork che condividono il nome.
Quattro indicatori nella v0.8.5, e solo uno riguarda la rete
Prima di decidere qualsiasi cosa, leggi quale indicatore hai effettivamente ricevuto. Il file della lingua inglese di ZeroClaw alla v0.8.5 definisce queste voci come chiavi Fluent distinte, sotto un commento di intestazione che specifica che vengono aggiunte all'output dell'assistente, o salvate come tale, quando un turno viene interrotto, e mostrate agli utenti finali su ogni trasporto: canali, WS, RPC, ACP e CLI.
| Indicatore | Chiave Fluent | Cosa indica |
|---|---|---|
[stream interrupted] | turn-stream-interrupted | Lo stream di trasporto è morto a metà turno. Nessuno ha premuto stop. |
[interrupted by user] | turn-interrupted-by-user | Un'interruzione umana. |
[turn cancelled via client] | turn-cancelled-client-rpc | Il canale, non l'attore. Il commento nel codice specifica che le interruzioni umane e gli annullamenti programmatici da parte del client arrivano entrambi su questo percorso, quindi la formulazione identifica il canale. |
[interrupted by user before this tool produced a result] | turn-tool-interrupted-before-result | Uno strumento è stato interrotto prima di restituire il risultato. |
Una quinta chiave, turn-failed = [turn failed], esiste nello stesso file su master ma non nel file della lingua della v0.8.5, quindi una build rilasciata non la emette. È utile conoscere un comportamento perché cambia ciò che puoi leggere in seguito: il motore del turno salva il testo parziale con l'indicatore aggiunto solo quando tale testo parziale non è vuoto. Un turno che ha prodotto ragionamento o eventi di strumenti pre-eseguiti dal provider ma nessun testo visibile non salva assolutamente nulla: il commento nel codice descrive la persistenza come il salvataggio di ciò che il consumatore ha già visto. Le altre lingue contengono le stesse chiavi con valori tradotti, quindi la stringa letterale inglese tra parentesi quadre non è quella mostrata da un'installazione non in inglese.
Dove si trova effettivamente il limite dei tentativi
L'intera decisione si riduce a una domanda: qualcosa ha già raggiunto un sink di eventi immutabile?
| Cosa è successo | Comportamento documentato nella v0.8.5 | Avvertenza |
|---|---|---|
| Lo stream fallisce prima di qualsiasi output visibile | Il runtime riprova l'intera chiamata tramite il percorso non in streaming, rientrando nel ciclo completo di affidabilità | Documentato, ma non è ciò che è stato osservato con una configurazione a candidato singolo sulla build rilasciata: vedi sotto |
| Lo stream si completa senza testo finale e senza chiamate agli strumenti | Una risposta semanticamente vuota, non una risposta. Quando il risultato è contrassegnato come sicuro da ripetere e provider_retries è diverso da zero, viene effettuata una chiamata di recupero non in streaming allo stesso identico provider e modello, consumata una volta | Distribuito nella v0.8.5 tramite la pull request #10602, integrata il 4 settembre 2026. Si applica agli stream vuoti, non agli stream interrotti durante l'output |
| Testo, ragionamento o eventi di strumenti pre-eseguiti hanno già raggiunto un sink di eventi immutabile | StreamInterruptedAfterOutput. Il runtime non ripete la richiesta e il testo già inoltrato al consumatore è l'unico elemento che diventa testo parziale persistito dell'assistente | Deliberato e identico su master. Protetto da un test di regressione che afferma che un errore dello stream dopo un output visibile deve far fallire il turno senza un nuovo tentativo di fallback |
| Una qualsiasi delle situazioni precedenti | Lo stream viene aperto una sola volta e le voci non vengono trasferite dopo l'avvio | Il recupero è sempre una nuova richiesta. Nessuna famiglia di provider, incluso lo slot personalizzato, dispone di un percorso di ripresa |
I parametri disponibili sono globali, non per endpoint. [reliability] contiene provider_retries, valore predefinito documentato 2, e provider_backoff_ms, valore predefinito 500; il documento sul ciclo di vita specifica che ogni voce materializzata viene tentata fino a provider_retries + 1 volte. Il riferimento alla configurazione della v0.8.5 non documenta alcun override dei tentativi per provider o alias accanto a questi parametri. Non fare affidamento neppure sul pool di chiavi: la documentazione della v0.8.5 afferma che reliability.api_keys non è oggi un failover funzionante, perché il wrapper seleziona e registra una chiave alternativa dopo un limite di frequenza che consente nuovi tentativi, ma non riesce ad applicarla al provider costruito; il nuovo tentativo usa quindi ancora la credenziale originale. Una seconda chiave aggiunta aspettandosi un recupero non lo fornisce.
Indicare un solo endpoint è la configurazione che subisce il problema
Questo è il limite più netto per chi esegue ZeroClaw su un singolo gateway o su un singolo endpoint del fornitore, perché un solo endpoint è per definizione una configurazione di affidabilità con un solo candidato. La issue #10736 segnala che, sulla build rilasciata, un errore dello stream prima dell'output in questa configurazione registra un fallback alla chat non in streaming e poi non lo invia mai, terminando il turno con All model providers/models failed after 0 failure event(s). È stata chiusa il 18 settembre 2026, dopo la pubblicazione della v0.8.5, quindi la correzione è presente solo su master. Eseguita il 1° ottobre 2026, la v0.8.5 rilasciata si è comportata esattamente come descritto nella issue: una richiesta, poi quell'errore, sia quando lo stream si interrompeva prima sia quando si interrompeva dopo la comparsa del testo.
Qui due posizioni ufficiali non concordano, ed entrambe meritano di essere riportate. Il documento sull'architettura della v0.8.5 promette il tentativo non in streaming; la issue dimostra che la build rilasciata non lo esegue, e la sezione sul comportamento atteso richiede che il log dichiari un fallback soltanto quando questo verrà effettivamente tentato. Master aggiunge poi un'autorizzazione al recupero per il candidato singolo che la release non possiede, e la issue #10787 afferma che tale autorizzazione è stata concessa con RetryDecision::Admit(0) indipendentemente da provider_retries e senza backoff, quindi un upstream sovraccarico veniva reinviato immediatamente nella stessa finestra di sovraccarico. La issue è stata chiusa come completata il 26 settembre 2026, su master e dopo la v0.8.5, quindi neppure in questo caso è presente in una release. Il comportamento di master è ancora in evoluzione; non pianificare basandoti su di esso.
La forma documentata di mitigazione è una configurazione, non un'impostazione: assegna al profilo un secondo candidato, così il ciclo di affidabilità ha un percorso da seguire. Il 1° ottobre 2026 questa configurazione ha funzionato sulla v0.8.5 nel terminale, con un'avvertenza da conoscere prima di farvi affidamento: la richiesta di recupero è stata inviata al secondo modello, non al primo, quindi la risposta ottenuta dopo un'interruzione proviene dal fallback. La guida ai costi e alla configurazione dell'API di ZeroClaw descrive la forma della configurazione in cui inserire queste voci.
Cosa ha fatto la v0.8.5 quando lo stream è stato interrotto
Il 1° ottobre 2026, il binario della release v0.8.5, verificato tramite checksum rispetto a SHA256SUMS, è stato eseguito in un container usa e getta nella modalità terminale interattiva, cioè la modalità che effettua lo streaming; la modalità -m a messaggio singolo invia una richiesta non in streaming e non raggiunge mai questo percorso. Un profilo con slot personalizzato compatibile con OpenAI, provider_retries = 2, puntava a un server di test locale che rispondeva con uno stream normale e poi chiudeva la connessione senza [DONE], prima del primo evento oppure dopo un chunk di testo.
| Profilo | Dove si è interrotto lo stream | Richieste inviate | Cosa ha mostrato il terminale |
|---|---|---|---|
| Un candidato | Prima di qualsiasi testo | Una richiesta in streaming, senza nuovo tentativo | Errore: il provider del modello selezionato non è riuscito a completare l'operazione. Controlla la configurazione del provider o scegline un altro. Il log: Tutti i provider/modelli del modello non sono riusciti dopo 0 eventi di errore |
| Un candidato | Dopo la stampa del testo | Una richiesta in streaming, senza nuovo tentativo | Il testo parziale, poi lo stesso errore. Non è stato stampato alcun indicatore [stream interrupted] |
In più fallback_models con un secondo modello | Prima di qualsiasi testo | La richiesta in streaming, poi una richiesta non in streaming al secondo modello | La risposta del secondo modello |
In più fallback_models con un secondo modello | Dopo la stampa del testo | Le stesse due richieste | Il testo parziale, poi la risposta completa del secondo modello — quindi la risposta appare due volte |
Per chiunque esegua ZeroClaw da un terminale sulla v0.8.5 seguono tre considerazioni. Il fallimento con un solo candidato è il #10736, riprodotto; provider_retries non lo ha modificato. Il limite documentato del «nessun replay dopo output visibile» non si è applicato qui: il testo già stampato nel terminale non ha impedito un nuovo invio, quindi un turno che hai visto arrivare solo parzialmente può essere ancora inviato, a un modello diverso. Inoltre, il log del turno ha registrato il primo modello come modello del turno, mentre il testo proveniva dal secondo: è il divario di attribuzione rispetto al quale mette in guardia la documentazione della v0.8.5. Cosa non copre questa esecuzione: canali come Telegram o Slack, il WebSocket del gateway, i client RPC e ACP — i trasporti per i cui sink di eventi è stata scritta la regola di no-replay — lo slot Anthropic, reali interruzioni dei provider e qualsiasi richiesta tramite Kunavo.
Prima di inviare di nuovo: cosa è già stato eseguito e cosa è già stato addebitato
Il ciclo degli strumenti di ZeroClaw legge lo stream fino al completamento, recupera le chiamate agli strumenti dopo la sua conclusione, le esegue, poi apre una nuova chiamata in streaming per il turno successivo dell'assistente. Quindi gli strumenti richiesti dall'iterazione che si è interrotta non sono stati eseguiti — ma è una rassicurazione più limitata di quanto sembri. Le chiamate agli strumenti preeseguite dal provider sono una classe di eventi distinta che ha già prodotto effetti a monte, ed è proprio per questo che impediscono il replay. Inoltre, i turni lunghi si interrompono tardi: il #10736 nota che la chiamata allo strumento precedente era stata completata con successo prima dell'errore, mentre il log del #10787 mostra l'interruzione all'iterazione 2, con 126 messaggi nella richiesta. Inviare di nuovo il prompt originale ripete ogni effetto collaterale precedente che il modello ripeterebbe.
Nemmeno una trascrizione dall'aspetto pulito costituisce una prova. Il problema #9421, aperto con priorità p1 per entrambe le famiglie di provider Anthropic e compatibili con OpenAI, ha come titolo il fatto che le risposte incomplete del terminale possono essere segnalate come riuscite. Sulla superficie Code/ACP, altri due report p1 ancora aperti descrivono un turno fallito che elimina dalla cronologia persistente i prompt accettati e gli scambi di strumenti completati (#10788) e un turno che supera il budget e perde i progressi visibili dopo il ripristino della sessione (#10659), mentre la pull request per rendere persistenti i progressi del turno interrotto non è ancora stata integrata. Tutti erano aperti il 21 settembre 2026 e diversi risultano in lavorazione, quindi ricontrolla i dati invece di citare questa istantanea.
Sul costo, la v0.8.5 e master differiscono davvero, e dovresti leggere quella corrispondente alla tua build. La documentazione della release definisce il record finale un avviso di successo anziché un registro canonico di ogni tentativo e dice di non dedurre da esso l'accuratezza del costo per tentativo; master sostituisce quel paragrafo con un registro per tentativo usage_by_provider derivato dalla pull request #8966, integrata il 18 settembre 2026, che nessuna release contiene e che master stesso limita ai percorsi dei turni strumentati con eventi. Nel frattempo, l'istantanea dell'utilizzo dello stream interrotto è un campo facoltativo che può mancare, e ZeroClaw richiede agli endpoint compatibili con OpenAI l'utilizzo in un chunk SSE finale — quello che uno stream troncato potrebbe non inviare mai. Considera quest'ultimo punto un meccanismo da verificare nel tuo output dei costi, non un risultato misurato. Riconcilia invece i dati con il record di utilizzo dell'endpoint; su Kunavo, si tratta di il log dell'utilizzo.
Perché un gateway davanti a un modello produce questo indicatore
La causa di terze parti più probabile è un segnale di completamento che non arriva mai. La documentazione dello streaming di ZeroClaw v0.8.5 afferma che i trasporti non si basano sulla chiusura della connessione come segnale di successo: gli stream compatibili con OpenAI terminano con [DONE], gli stream OpenAI Responses con il relativo evento di risposta terminale e gli stream Anthropic con message_stop, mentre i server possono mantenere aperta la connessione HTTP dopo tali eventi. Uno stream che si chiude senza il relativo segnale viene presentato come errore — SSE stream closed before {completion_signal}: response truncated — anziché come un successo breve. Si tratta di un difetto dell'endpoint, non di ZeroClaw. È documentata un'eccezione: il parser Anthropic attualmente considera completo anche un EOF dopo un message_delta.stop_reason non vuoto, persino senza message_stop, e la pull request che propone di renderlo obbligatorio non è stata integrata in nessuno dei due ref.
La seconda causa è il silenzio su un socket aperto. ZeroClaw utilizza timeout di inattività dei byte anziché una scadenza per l'intera richiesta, documentati come 300 secondi per OpenAI Responses e per i provider compatibili con OpenAI e 90 secondi per Anthropic; ogni lettura del corpo reimposta il timer. Un endpoint che memorizza nel buffer una risposta upstream e non inoltra nulla per un minuto e mezzo attiva lo slot della famiglia Anthropic, mentre quello compatibile con OpenAI continua a funzionare — un dettaglio utile da sapere perché un endpoint Messages Anthropic va nello slot anthropic con un override uri, non in custom. Consulta la documentazione del base URL Messages e API compatibile con OpenAI per i due protocolli di rete.
Quanto costa un turno interrotto, con un calcolo esemplificativo
Separa i due addebiti. Il runtime ZeroClaw costa $0 — zeroclaw.com dichiara che è open source, con doppia licenza MIT O Apache-2.0, senza abbonamento e senza postazione ospitata, e che paghi solo i costi del tuo provider LLM, oppure nulla eseguendo un modello locale con Ollama. Nessun livello sblocca la ripresa, un budget di retry più ampio o il recupero guidato, perché non esistono livelli.
Il costo del modello è quello su cui incide un'interruzione. Queste cifre sono un calcolo dei token basato su ipotesi, non il costo misurato di un'attività né un limite massimo della fattura. Supponi un turno che invia 110.000 token di input non memorizzati nella cache — la dimensione del prompt nell'unico episodio datato di sovraccarico documentato nella issue #10787, in cui l'upstream ha accettato la richiesta ed eseguito il prefill prima di scartarla — e riceve 2.000 token di output prima che lo stream muoia. La colonna dei tre tentativi è provider_retries + 1 al valore predefinito documentato di 2. Le tariffe sono i prezzi aggiornati del catalogo Kunavo per milione di token.
| Modello | Input / output per 1M | Un tentativo interrotto | Tre tentativi |
|---|---|---|---|
| Claude Haiku 4.5 | $0,70 / $3,50 | $0,084 | $0,252 |
| GPT-5.6 Terra | $0,70 / $4,20 | $0,085 | $0,256 |
| Claude Sonnet 4.6 | $2,10 / $10,50 | $0,252 | $0,756 |
| Claude Opus 5 | $3,50 / $17,50 | $0,420 | $1,260 |
L'eventuale addebito da parte di un endpoint per una richiesta che ha interrotto è stabilito dalla politica di fatturazione dell'endpoint stesso, e nulla nel codice sorgente o nella documentazione di ZeroClaw lo specifica — questa pagina non lo ha misurato per alcun provider. Il calcolo serve a dimensionare la domanda, non a rispondervi. L'importo del catalogo Kunavo è un minimo di fatturazione, non un limite massimo: quando l'upstream comunica il proprio addebito, la fattura è il maggiore tra il costo di catalogo e il costo upstream moltiplicato per il markup applicabile. Il top-up minimo è $10 in credito prepagato, un minimo di finanziamento, non un costo per attività o un abbonamento — consulta i dettagli di fatturazione.
Quale percorso resiste meglio a questo errore
| Percorso | Come si comporta durante un'interruzione a metà stream | A cosa rinunci |
|---|---|---|
| Un endpoint, vendor diretto | Una configurazione di affidabilità con un solo candidato, quindi rientra nella popolazione segnalata dal #10736 sulla v0.8.5 | Il fatto di essere un vendor di prima parte non cambia il percorso; un candidato è un candidato |
| Un endpoint, gateway | Forma identica con un solo candidato. Qui un gateway consente di cambiare modello usando una sola chiave e un solo saldo, non di ottenere resilienza dello stream | Un passaggio aggiuntivo che può a sua volta chiudersi senza un segnale di completamento, e che ZeroClaw considera nel prezzo solo se scrivi personalmente le voci [cost.rates] |
| Due o più candidati nel profilo | Il percorso di affidabilità ha una destinazione. Nell'esecuzione da terminale del 1° ottobre 2026 si è ripreso dopo un'interruzione iniziale e una a metà risposta — tramite il secondo modello | Un secondo modello o alias da mantenere e una risposta recuperata che proviene dal tuo fallback anziché dalla prima scelta |
| Modello locale tramite Ollama | Un nuovo invio costa tempo e risorse hardware anziché denaro, quindi un retry prudente è economico | Il divario di capacità rispetto ai modelli frontier ospitati e una macchina per eseguirne uno |
| Un agente con abbonamento a tariffa fissa | Non è affatto un percorso ZeroClaw: il progetto non ha abbonamento né postazione ospitata | Cambieresti il client, non il comportamento di recupero di ZeroClaw |
Qualunque scelta tu faccia, la regola operativa è quella già codificata in ZeroClaw: dopo [stream interrupted], leggi il parziale persistito, stabilisci cosa ha già avuto effetto, poi invia di nuovo qualcosa di più circoscritto dell'originale. I riferimenti di configurazione di Kunavo per endpoint compatibili con OpenAI e in stile Messages sono documentazione di configurazione, non un test di compatibilità — l'esecuzione del 1° ottobre riportata sopra ha utilizzato un server di test locale, non Kunavo. Inizia dal riferimento degli errori per decodificare ciò che ha restituito il tuo endpoint e crea un account Kunavo quando sei pronto a finanziare una chiave. OpenRouter vs LiteLLM è il confronto più vicino per la decisione tra un solo candidato e molti descritta sopra.
Domande frequenti
ZeroClaw riprova uno stream interrotto?
Dipende interamente dal fatto che tu abbia già visto un output. La documentazione di ZeroClaw sull'instradamento dei provider per la versione rilasciata v0.8.5 afferma che lo stream viene aperto una sola volta e che le voci non vengono trasferite dopo l'avvio; pertanto non viene mai ripreso nulla: il recupero, quando esiste, è una richiesta completamente nuova. Se lo stream fallisce prima che sia visibile qualsiasi output di evento immutabile, il comportamento documentato prevede che il runtime riprovi l'intera chiamata tramite il percorso non in streaming. Quando testo, ragionamento o eventi di strumenti pre-eseguiti raggiungono un sink di eventi immutabile, l'interruzione diventa StreamInterruptedAfterOutput e il runtime non ripete la richiesta. Questa seconda regola è la stessa anche su master. Tuttavia, durante un'esecuzione del 1° ottobre 2026 nel client terminale interattivo della v0.8.5, nessuna delle due regole si è manifestata come descritto: con un solo candidato non è stato effettuato alcun tentativo, né prima né dopo la comparsa del testo, mentre con un secondo candidato in fallback_models il turno è stato reinviato senza streaming a quel secondo modello in entrambi i casi, anche dopo che parte della risposta era stata stampata. I canali e il WebSocket del gateway non sono stati eseguiti. Documentazione verificata il 21 settembre 2026.
Cosa significa [stream interrotto] in ZeroClaw?
È l'indicatore visibile all'utente per uno stream di trasporto interrotto a metà turno, definito nel file della lingua inglese di ZeroClaw come la chiave Fluent turn-stream-interrupted e mostrato su ogni trasporto: canali, WS, RPC, ACP e CLI. È deliberatamente diverso dagli indicatori [interrotto dall'utente] e [turno annullato tramite client], quindi la sua presenza indica che nessuno ha premuto stop. Quando lo stream muore dopo un output visibile, il testo parziale viene salvato come messaggio dell'assistente con l'indicatore aggiunto, ma solo quando tale testo parziale non è vuoto: un turno che ha prodotto soltanto ragionamento o soltanto eventi di strumenti pre-eseguiti non salva nulla. Le installazioni non in inglese mantengono la stessa chiave con testo tradotto, quindi non cercare la stringa inglese tra parentesi quadre in una di esse. Letto al tag di rilascio v0.8.5 il 21 settembre 2026. Nel client terminale interattivo della v0.8.5, il 1° ottobre 2026, un taglio dello stream durante la risposta non ha stampato questo indicatore; il terminale ha invece mostrato un errore di mancato funzionamento del provider.
È sicuro reinviare semplicemente il prompt dopo un'interruzione dello stream di ZeroClaw?
Non automaticamente, e i manutentori di ZeroClaw lo trattano proprio in questo modo. Il runtime legge lo stream fino al completamento, recupera le chiamate agli strumenti dopo la sua conclusione e poi le esegue: pertanto gli strumenti dell'iterazione interrotta non sono stati eseguiti. Tuttavia, un turno lungo può interrompersi anche nelle iterazioni successive: una segnalazione upstream osserva che la chiamata allo strumento precedente era stata completata correttamente prima del fallimento, mentre il log di un'altra mostra l'interruzione all'iterazione 2 con 126 messaggi nella richiesta. Qualsiasi operazione già eseguita da un'iterazione precedente — un file scritto, un comando eseguito, un messaggio inviato — viene ripetuta se reinvii lo stesso prompt alla cieca. La richiesta di funzionalità aperta per il recupero guidato elenca tra i propri obiettivi esclusi la riproduzione cieca di un turno con strumenti o autorizzazioni e il trattamento di ogni errore del provider come transitorio. Leggi prima il testo parziale salvato, verifica cosa ha già avuto effetto, quindi reinvia un prompt ristretto invece dell'originale.
Posso configurare ZeroClaw per riprendere lo stream interrotto?
No. Non esiste alcuna impostazione per farlo in nessuna versione rilasciata, né esiste un livello a pagamento che la abiliti: ZeroClaw è gratuito e open source, con doppia licenza MIT OR Apache-2.0, senza abbonamento né postazione ospitata; pertanto il limite è ingegneristico, non legato al piano. La regola che vieta la riproduzione dopo un output visibile è presente nel codice sorgente ed è protetta da un test di regressione il cui messaggio di errore afferma che un errore dello stream dopo un output visibile deve far fallire il turno senza un nuovo tentativo di fallback; tuttavia, nel client terminale interattivo della v0.8.5, il 1° ottobre 2026, un profilo con un secondo candidato ha effettivamente reinviato la richiesta dopo la stampa del testo, quindi la regola non è una garanzia su ogni trasporto. Il recupero guidato dopo un turno interrotto è la issue #10634: aperta, con stato accettata e priorità p2, e indirizzata innanzitutto alla progettazione o alla discussione di un RFC al 21 settembre 2026. Accettata significa che il triage ha accettato la descrizione del problema, non che il codice sia stato scritto o integrato.
Il mio log dice che sta passando alla chat non in streaming e poi il turno muore. Perché?
Nella v0.8.5 rilasciata, quella riga del log può essere falsa. La issue upstream #10736, intitolata al fatto che un errore dello stream prima dell'output salta il fallback non in streaming pubblicizzato, segnala che il runtime registra il passaggio alla chat non in streaming ma non invia la richiesta non in streaming, e il turno termina immediatamente con All model providers/models failed after 0 failure event(s). La sua dichiarazione sull'impatto identifica come popolazione interessata gli utenti con un solo candidato provider, soprattutto le configurazioni con zero tentativi. Zero tentativi non è l'unico caso: la riproduzione imposta provider_retries = 0, ma la issue successiva #10787 riproduce lo stesso fallimento immediato con provider_retries lasciato al valore predefinito documentato di 2. La issue è stata chiusa il 18 settembre 2026, dopo la pubblicazione della v0.8.5 il 5 settembre, quindi nessuna release pubblicata contiene la correzione. Il problema è stato riprodotto sulla v0.8.5 il 1° ottobre 2026: una richiesta in streaming, nessun seguito non in streaming e quell'errore, con provider_retries = 2 e sia quando lo stream si interrompeva prima sia quando si interrompeva dopo la comparsa del testo. L'aggiunta di un secondo modello in fallback_models è stata sufficiente per recuperare il turno. Eseguire il debug dai log della v0.8.5 significa leggere un fallback che non è mai avvenuto.
Mi è stato addebitato il turno interrotto e come posso verificarlo?
Controlla il registro di utilizzo dell'endpoint, non quello di ZeroClaw, perché la documentazione della v0.8.5 ti invita a non fidarti della cifra per tentativo: descrive l'avviso finale di fallback come un avviso di successo, non come un registro canonico di ogni tentativo, e afferma di non dedurre da esso l'accuratezza del costo per tentativo. Il registro per tentativo usage_by_provider che risolve questo problema è arrivato su master tramite la pull request #8966, integrata il 18 settembre 2026, dopo la distribuzione della v0.8.5; pertanto non è incluso in alcuna release, e su master è limitato ai percorsi del turno strumentati con eventi. ZeroClaw acquisisce uno snapshot di utilizzo durante uno stream interrotto, ma il campo è facoltativo e può mancare, e richiede agli endpoint compatibili con OpenAI l'utilizzo in un chunk SSE finale, cioè il chunk che uno stream troncato potrebbe non consegnare mai. Quest'ultimo punto è ricavato dal codice sorgente, non osservato in runtime. Separatamente, le cifre dei costi di ZeroClaw provengono dai prospetti tariffari [cost.rates] scritti dall'operatore nella tua configurazione, quindi un endpoint a cui non hai assegnato un prezzo lì non viene prezzato neppure da ZeroClaw.
Esecuzione del 1° ottobre 2026: il binario della release v0.8.5 in modalità terminale interattivo contro un server di test locale che ha interrotto lo stream — le quattro righe della tabella dei risultati; non è stato eseguito nient'altro e nessuna richiesta è stata inviata a Kunavo. Gli stati dei problemi sono stati ricontrollati lo stesso giorno (#10787 da allora è stato chiuso; #10634 è ancora aperto). Il codice sorgente del repository è stato letto al tag della release v0.8.5, la documentazione al percorso /v0.8.5/ fissato alla versione e gli stati dei problemi e delle pull request sono stati letti il 21 settembre 2026; diversi di quei problemi erano contrassegnati come in lavorazione e possono cambiare. Le tariffe dei token Kunavo provengono dal catalogo aggiornato e ogni cifra in dollari qui riportata è un calcolo esemplificativo dei token, non il costo misurato di un'attività.