ZeroClaw ne reprend jamais un flux interrompu. Le fait qu'il renvoie ou non le tour dépend du nombre de candidats de votre profil, et dans l'unique version publiée actuelle, le comportement ne correspond pas tout à fait à ce que promet la documentation. La documentation de ZeroClaw pour v0.8.5 (publiée le 5 septembre 2026) indique qu'un flux qui échoue avant toute sortie est réessayé sans streaming, et qu'un flux qui échoue après une sortie n'est jamais rejoué. Exécuté le 1er octobre 2026 contre un endpoint qui a interrompu le flux en cours de réponse, le client de terminal de v0.8.5 a fait quelque chose de plus simple : avec un seul candidat, il n'a effectué aucune nouvelle tentative, avant ou après l'apparition du texte ; avec un second candidat, il a renvoyé le tour, sans streaming, à ce second modèle — même après l'affichage d'une partie de la réponse. La récupération guidée après une sortie partielle est une demande de fonctionnalité ouverte qui n'a pas obtenu l'approbation de conception. La question utile n'est donc pas de savoir comment faire réessayer ZeroClaw, mais si votre tour peut être renvoyé sans risque pour vous et quel coût la tentative interrompue a déjà engendré.
Deux précisions de portée avant que tout cela puisse être mis en pratique. L'exécution effectuée est limitée : le binaire de la version v0.8.5 en mode terminal interactif, un endpoint compatible OpenAI et un serveur de test local qui a délibérément fermé le flux — les résultats sont ci-dessous. Les canaux, le WebSocket de la passerelle, RPC, ACP, le slot Anthropic et les pannes réelles de fournisseurs n'ont pas été exécutés. Toute autre affirmation est tirée du dépôt au tag de version v0.8.5, de la documentation liée à cette version sur docs.zeroclaw.com/v0.8.5/ ou de rapports d'issues amont datés, tous consultés le 21 septembre 2026. Épinglez vous-même cette URL : le README redirige les lecteurs vers le chemin /master/, dont le HEAD a seize jours d'avance sur la version publiée et contredit celle-ci précisément sur ce sujet, tandis que /latest/ renvoie une erreur 404. ZeroClaw désigne ici le runtime zeroclaw-labs/zeroclaw ; si vous n'êtes pas certain qu'il s'agit bien de celui que vous exécutez, ZeroClaw vs OpenClaw le distingue des projets et forks qui partagent ce nom.
Quatre marqueurs dans v0.8.5, dont un seul correspond au réseau
Avant de décider quoi que ce soit, vérifiez quel marqueur vous avez réellement reçu. Le fichier de locale anglais de ZeroClaw dans v0.8.5 définit ces marqueurs comme des clés Fluent distinctes sous un commentaire d'en-tête indiquant qu'ils sont ajoutés à la sortie de l'assistant, ou conservés comme celle-ci, lorsqu'un tour est interrompu, et qu'ils sont affichés aux utilisateurs finaux sur chaque transport — canaux, WS, RPC, ACP et CLI.
| Marqueur | Clé Fluent | Ce que cela vous indique |
|---|---|---|
[stream interrupted] | turn-stream-interrupted | Le flux de transport s'est interrompu en cours de tour. Personne n'a appuyé sur le bouton d'arrêt. |
[interrupted by user] | turn-interrupted-by-user | Une interruption humaine. |
[turn cancelled via client] | turn-cancelled-client-rpc | Le canal, et non l'acteur. Le commentaire du code correspondant indique que les interruptions humaines et les annulations programmatiques du client arrivent toutes deux sur ce chemin ; la formulation désigne donc le canal. |
[interrupted by user before this tool produced a result] | turn-tool-interrupted-before-result | Un outil a été interrompu avant de renvoyer un résultat. |
Une cinquième clé, turn-failed = [turn failed], existe dans le même fichier sur master mais pas dans le fichier de locale de v0.8.5 ; une version publiée ne l'émet donc pas. Un comportement mérite d'être connu, car il modifie ce que vous pouvez lire ensuite : le moteur de tour conserve le texte partiel avec le marqueur ajouté uniquement lorsque ce texte partiel n'est pas vide. Un tour qui a produit du raisonnement ou des événements d'outils préexécutés côté fournisseur, mais aucun texte visible, ne conserve absolument rien — le commentaire du code présente la conservation comme l'enregistrement de ce que le consommateur a déjà vu. Les autres locales contiennent les mêmes clés avec des valeurs traduites ; la chaîne anglaise littérale entre crochets n'est donc pas celle qu'affiche une installation non anglophone.
Où se situe réellement la limite de nouvelle tentative
Toute la décision se résume à une question : quelque chose avait-il déjà atteint un récepteur d'événements immuable ?
| Ce qui s’est passé | Comportement documenté dans v0.8.5 | Réserve |
|---|---|---|
| Le flux échoue avant toute sortie visible | Le runtime réessaie l'appel complet via le chemin sans streaming, en réintégrant le parcours complet de fiabilité | Documenté, mais différent de ce qu'a observé une configuration à candidat unique sur la version publiée — voir ci-dessous |
| Le flux se termine sans texte final ni appels d'outils | Une réponse vide sur le plan sémantique, et non une réponse. Lorsque le résultat est marqué comme pouvant être rejoué et que provider_retries est différent de zéro, un appel de récupération sans streaming vers exactement le même fournisseur et modèle, consommé une seule fois | Livré dans v0.8.5 via la pull request #10602, fusionnée le 4 septembre 2026. S'applique aux flux vides, et non aux flux interrompus en cours de sortie |
| Du texte, du raisonnement ou des événements d'outils préexécutés ont déjà atteint un récepteur d'événements immuable | StreamInterruptedAfterOutput. Le runtime ne rejoue pas la requête, et le texte déjà transmis au consommateur est le seul à devenir du texte partiel conservé de l'assistant | Délibéré et identique sur master. Verrouillé par un test de non-régression affirmant qu'une erreur de flux après une sortie visible doit faire échouer le tour sans nouvelle tentative de repli |
| L'un des cas ci-dessus | Le flux est ouvert une seule fois et les entrées ne sont pas basculées après son démarrage | La récupération est toujours une nouvelle requête. Aucune famille de fournisseurs, y compris le slot personnalisé, ne dispose d'un chemin de reprise |
Les paramètres disponibles sont globaux et non propres à chaque endpoint. [reliability] contient provider_retries, dont la valeur par défaut documentée est 2, ainsi que provider_backoff_ms, dont la valeur par défaut est 500 ; le document consacré au cycle de vie indique que chaque entrée matérialisée est tentée jusqu'à provider_retries + 1 fois. La référence de configuration de v0.8.5 ne documente aucun remplacement de nouvelle tentative par fournisseur ou par alias à côté de ces paramètres. Ne comptez pas non plus sur le pool de clés : la documentation de v0.8.5 indique que reliability.api_keys ne constitue pas aujourd'hui un basculement fonctionnel, car le wrapper sélectionne et journalise une autre clé après une limite de débit permettant une nouvelle tentative, mais ne peut pas l'appliquer au fournisseur construit ; la nouvelle tentative utilise donc toujours l'identifiant d'origine. Une deuxième clé ajoutée dans l'espoir d'un secours n'en fournit pas.
Pointer vers un seul endpoint est la configuration qui en pâtit
Il s'agit de la limite la plus nette pour quiconque exécute ZeroClaw avec une seule passerelle ou un seul endpoint fournisseur, car un endpoint constitue par définition une configuration de fiabilité à candidat unique. L'issue #10736 rapporte que, dans la version publiée, une défaillance du flux avant la sortie dans cette configuration journalise un basculement vers le chat sans streaming puis ne l'envoie jamais, ce qui interrompt le tour avec All model providers/models failed after 0 failure event(s). Elle a été clôturée le 18 septembre 2026 — après la publication de v0.8.5 — ; le correctif se trouve donc uniquement sur master. Lors d'une exécution le 1er octobre 2026, la version publiée v0.8.5 s'est comportée exactement comme le décrit l'issue : une requête, puis cette erreur, que le flux se soit interrompu avant ou après l'apparition du texte.
Deux positions officielles divergent ici et méritent toutes deux d'être conservées. Le document d'architecture de v0.8.5 promet la nouvelle tentative sans streaming ; l'issue montre que la version publiée ne l'effectue pas et sa section consacrée au comportement attendu demande que le journal n'annonce un repli que lorsqu'il sera effectivement tenté. Master ajoute ensuite une autorisation de récupération pour les candidats uniques que la version publiée ne possède pas — et l'issue #10787 indiquait que cette autorisation était accordée avec RetryDecision::Admit(0), indépendamment de provider_retries et sans temporisation ; un amont surchargé était donc renvoyé immédiatement dans la même fenêtre de saturation. Cette issue a été clôturée comme terminée le 26 septembre 2026 — sur master, après v0.8.5 ; elle ne figure donc elle non plus dans une version publiée. Le comportement de master évolue encore ; ne concevez pas votre plan sur cette base.
La forme documentée d'une mesure d'atténuation relève de la configuration plutôt que d'un paramètre : donnez au profil un second candidat afin que le parcours de fiabilité puisse continuer ailleurs. Le 1er octobre 2026, cela a fonctionné dans v0.8.5 depuis le terminal — avec une réserve à connaître avant de vous y fier : la requête de récupération a été envoyée au second modèle, et non au premier ; après une interruption, la réponse obtenue provient donc de votre modèle de repli. Le guide des coûts et de la configuration de l'API ZeroClaw décrit la structure de configuration dans laquelle placer ces entrées.
Ce que v0.8.5 a fait lorsque le flux a été interrompu
Le 1er octobre 2026, le binaire de la version v0.8.5, dont la somme de contrôle a été vérifiée par rapport au SHA256SUMS de la version publiée, a été exécuté dans un conteneur temporaire en mode terminal interactif — le mode qui diffuse le flux ; le mode -m à message unique envoie une seule requête sans streaming et n'emprunte jamais ce chemin. Un profil à slot personnalisé compatible OpenAI, provider_retries = 2, pointait vers un serveur de test local qui répondait avec un flux normal puis fermait la connexion sans [DONE], soit avant le premier événement, soit après un fragment de texte.
| Profil | L’endroit où le flux s’est interrompu | Requêtes envoyées | Ce qu’a affiché le terminal |
|---|---|---|---|
| Un seul candidat | Avant tout texte | Une requête en streaming, sans nouvelle tentative | Erreur : le fournisseur du modèle sélectionné a échoué. Vérifiez la configuration du fournisseur ou choisissez un autre fournisseur. Journal : Tous les fournisseurs/modèles ont échoué après 0 événement(s) d’échec |
| Un seul candidat | Après l’affichage du texte | Une requête en streaming, sans nouvelle tentative | Le texte partiel, puis la même erreur. Aucun marqueur [stream interrupted] n’a été affiché |
Avec fallback_models et un second modèle | Avant tout texte | La requête en streaming, puis une requête sans streaming vers le second modèle | La réponse du second modèle |
Avec fallback_models et un second modèle | Après l’affichage du texte | Les deux mêmes requêtes | Le texte partiel, puis la réponse complète du second modèle — la réponse apparaît donc deux fois |
Trois conséquences s’ensuivent pour toute personne exécutant ZeroClaw depuis un terminal sous v0.8.5. L’échec avec un seul candidat est le problème #10736, reproduit ; provider_retries n’y a rien changé. La limite documentée « aucune répétition après l’affichage d’une sortie visible » ne s’est pas appliquée ici : du texte déjà affiché dans le terminal n’a pas empêché un nouvel envoi, de sorte qu’un tour dont vous avez vu l’arrivée partielle peut encore être renvoyé à un autre modèle. De plus, le journal du tour a enregistré le premier modèle comme modèle du tour, alors que le texte provenait du second, ce qui constitue l’écart d’attribution signalé par la propre documentation de v0.8.5. Ce que cette exécution ne couvre pas : les canaux tels que Telegram ou Slack, le WebSocket de la passerelle, les clients RPC et ACP — les transports dont les récepteurs d’événements sont concernés par la règle d’absence de répétition —, le fournisseur Anthropic, les pannes réelles de fournisseurs et toute requête passant par Kunavo.
Avant de renvoyer : ce qui a déjà été exécuté et ce qui a déjà été facturé
La propre boucle d’outils de ZeroClaw lit le flux jusqu’à son terme, récupère les appels d’outils après leur fin, les exécute, puis ouvre un nouvel appel en streaming pour le tour suivant de l’assistant. Ainsi, les outils demandés par l’itération qui s’est interrompue n’ont pas été exécutés — mais cette assurance est moins rassurante qu’il n’y paraît. Les appels d’outils préexécutés côté fournisseur constituent une catégorie d’événements distincte qui a déjà produit des effets en amont, ce qui explique précisément pourquoi ils empêchent la répétition. Les longs tours s’interrompent tardivement : #10736 indique que l’appel d’outil précédent s’est terminé avec succès avant l’échec, et le journal de #10787 montre que l’interruption s’est produite à l’itération 2, avec 126 messages dans la requête. Renvoyer l’invite d’origine répète chaque effet secondaire antérieur que le modèle reproduirait.
Un transcript qui semble intact ne constitue pas non plus une preuve. Le problème #9421, ouvert avec la priorité p1 pour les familles de fournisseurs Anthropic et compatibles avec OpenAI, est intitulé « les réponses terminales incomplètes peuvent être signalées comme réussies ». Sur l’interface Code/ACP, deux autres rapports p1 ouverts décrivent un tour échoué supprimant de l’historique durable les invites acceptées et les échanges d’outils terminés (#10788), ainsi qu’un tour ayant dépassé le budget perdant la progression visible après la restauration de la session (#10659), tandis que la demande de modification visant à conserver la progression d’un tour interrompu n’a toujours pas été fusionnée. Tous étaient ouverts le 21 septembre 2026 et plusieurs sont marqués comme en cours ; vérifiez donc à nouveau plutôt que de citer cet instantané.
Concernant les coûts, v0.8.5 et master divergent réellement, et vous devez lire celui qui correspond à votre build. La documentation de la version publiée qualifie l’enregistrement final d’avis de réussite plutôt que de registre canonique de chaque tentative et indique qu’il ne faut pas en déduire l’exactitude du coût par tentative ; master remplace ce paragraphe par un registre usage_by_provider par tentative issu de la demande de modification #8966, fusionnée le 18 septembre 2026, que ne contient aucune version publiée et que master lui-même limite aux chemins de tour instrumentés par les événements. Par ailleurs, l’instantané d’utilisation d’un flux interrompu est un champ facultatif qui peut être absent, et ZeroClaw demande aux points de terminaison compatibles avec OpenAI l’utilisation dans un dernier fragment SSE — celui qu’un flux tronqué peut ne jamais envoyer. Considérez ce dernier point comme un mécanisme à vérifier dans votre propre sortie de coûts, et non comme un résultat mesuré. Faites plutôt la concordance avec le propre enregistrement d’utilisation du point de terminaison ; sur Kunavo, il s’agit de l’historique d’utilisation.
Pourquoi une passerelle devant un modèle produit ce marqueur
La cause tierce la plus probable est un signal de fin qui n’arrive jamais. La documentation du streaming de ZeroClaw v0.8.5 précise que les transports ne considèrent pas la fermeture de la connexion comme signal de réussite : les flux compatibles avec OpenAI se terminent sur [DONE], les flux OpenAI Responses sur leur événement de réponse terminal, et les flux Anthropic sur message_stop ; les serveurs peuvent maintenir la connexion HTTP ouverte après ces événements. Un flux qui se ferme sans son signal est présenté comme une erreur — SSE stream closed before {completion_signal}: response truncated — plutôt que comme une réussite brève. Il s’agit d’un défaut du point de terminaison, pas de ZeroClaw. Une exception est documentée : l’analyseur Anthropic considère actuellement aussi un EOF après un message_delta.stop_reason non vide comme complet, même sans message_stop, et la demande de modification proposant de l’exiger n’a été intégrée sur aucune des deux références.
La deuxième cause est le silence sur une socket ouverte. ZeroClaw utilise des délais d’inactivité en octets plutôt qu’une échéance pour toute la requête, documentés à 300 secondes pour OpenAI Responses et les fournisseurs compatibles avec OpenAI, et à 90 secondes pour Anthropic ; chaque lecture du corps réinitialise le délai. Un point de terminaison qui met en mémoire tampon une réponse en amont et ne transmet rien pendant une minute et demie déclenche le délai de la famille Anthropic tout en restant dans le délai de la famille compatible avec OpenAI — un point à connaître, car un point de terminaison Anthropic Messages utilise l’emplacement anthropic avec une surcharge uri, et non custom. Consultez la documentation sur l’URL de base Messages et l’API compatible avec OpenAI pour les deux protocoles filaires.
Ce que coûte un tour interrompu, en calcul indicatif
Distinguez les deux factures. Le runtime ZeroClaw coûte 0 $ — zeroclaw.com indique qu’il est open source, sous double licence MIT OU Apache-2.0, sans abonnement ni siège hébergé, et que vous ne payez que les coûts de votre propre fournisseur de LLM, voire rien du tout si vous exécutez un modèle local avec Ollama. Aucun niveau ne débloque la reprise, un budget de nouvelles tentatives plus élevé ou une récupération guidée, puisqu’il n’existe aucun niveau.
La facture du modèle est celle qu’une interruption affecte. Ces chiffres sont un calcul de jetons fondé sur des hypothèses, et non le coût mesuré d’une tâche ni un plafond de facturation. Supposons qu’un tour envoie 110 000 jetons d’entrée non mis en cache — la taille de l’invite enregistrée dans le seul épisode de surcharge daté, #10787, où le système en amont a accepté la requête et exécuté le préremplissage avant de l’interrompre — et reçoive 2 000 jetons de sortie avant l’arrêt du flux. La colonne des trois tentatives est provider_retries + 1 avec la valeur par défaut documentée de 2. Les tarifs sont les prix actuels du catalogue Kunavo par million de jetons.
| Modèle | Entrée / sortie par million | Une tentative interrompue | Trois tentatives |
|---|---|---|---|
| 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 |
La question de savoir si un point de terminaison donné facture une requête qu’il a interrompue relève de sa propre politique de facturation, et rien dans le code source ou la documentation de ZeroClaw ne le précise — cette page ne l’a mesuré pour aucun fournisseur. Le calcul sert à évaluer l’ordre de grandeur de la question, pas à y répondre. Le montant du catalogue Kunavo constitue un plancher de facturation, et non un plafond : lorsque le système en amont signale son coût, la facture correspond au montant le plus élevé entre le coût du catalogue et le coût en amont multiplié par la majoration applicable. Le rechargement minimal est de $10 de crédit prépayé, un minimum de financement et non des frais de tâche ou un abonnement — consultez les détails de facturation.
Quelle route résiste le mieux à cet échec
| Formule | Son comportement lors d’une interruption en cours de flux | Ce à quoi vous renoncez |
|---|---|---|
| Un point de terminaison, fournisseur direct | Une configuration de fiabilité à candidat unique, qui appartient donc à la population signalée par #10736 sous v0.8.5 | Le fait d’utiliser un fournisseur de première partie ne change rien au fonctionnement ; un candidat reste un candidat |
| Un point de terminaison, passerelle | Même configuration à candidat unique. Ici, une passerelle permet de changer de modèle avec une seule clé et un seul solde, mais n’améliore pas la résilience du flux | Un saut supplémentaire qui peut lui-même se fermer sans signal de fin, et que ZeroClaw ne tarifie que si vous renseignez vous-même ses entrées [cost.rates] |
| Deux candidats ou plus dans le profil | Le mécanisme de fiabilité a une solution de repli. Lors de l’exécution dans le terminal du 1er octobre 2026, il a récupéré après une interruption précoce et une interruption en cours de réponse — grâce au second modèle | Un second modèle ou alias à maintenir, et une réponse récupérée provenant de votre solution de repli plutôt que de votre premier choix |
| Modèle local via Ollama | Un nouvel envoi coûte du temps et du matériel plutôt que de l’argent ; une nouvelle tentative prudente est donc peu coûteuse | L’écart de capacité par rapport aux modèles de pointe hébergés, ainsi qu’une machine pour en exécuter un |
| Un agent à abonnement forfaitaire | Ce n’est pas une route ZeroClaw — le projet n’a ni abonnement ni siège hébergé | Vous changeriez de client, et non le comportement de récupération de ZeroClaw |
Quel que soit votre choix, la règle opérationnelle est celle que ZeroClaw encode déjà : après [stream interrupted], lisez la partie persistée, déterminez ce qui a déjà pris effet, puis renvoyez quelque chose de plus restreint que l’original. Les références de configuration de Kunavo pour les points de terminaison compatibles avec OpenAI et de type Messages sont des documents de configuration, et non un test de compatibilité — l’exécution du 1er octobre ci-dessus utilisait un serveur de test local, pas Kunavo. Commencez par la référence des erreurs pour décoder ce que votre point de terminaison a renvoyé, puis créez un compte Kunavo lorsque vous serez prêt à créditer une clé. OpenRouter contre LiteLLM est la comparaison la plus proche pour le choix entre un seul candidat et plusieurs candidats ci-dessus.
Questions fréquentes
ZeroClaw réessaie-t-il un flux qui a été interrompu ?
Cela dépend entièrement de la présence ou non d'une sortie déjà reçue. La documentation de ZeroClaw consacrée au routage des fournisseurs pour la version publiée v0.8.5 indique que le flux est ouvert une seule fois et que les entrées ne sont pas basculées après son démarrage ; rien n'est donc jamais repris — lorsqu'une récupération existe, il s'agit d'une toute nouvelle requête. Si le flux échoue avant qu'une sortie d'événement immuable soit visible, le comportement documenté consiste pour le runtime à réessayer l'appel complet via le chemin sans streaming. Dès que du texte, du raisonnement ou des événements d'outils préexécutés ont atteint un récepteur d'événements immuable, l'interruption devient StreamInterruptedAfterOutput et le runtime ne rejoue pas la requête. Cette deuxième règle est identique sur master. Mais lors de l'exécution du 1er octobre 2026 dans le client de terminal interactif de v0.8.5, aucune des deux règles ne s'est manifestée comme indiqué : avec un seul candidat, rien n'a été réessayé, avant ou après l'apparition du texte, et avec un second candidat dans fallback_models, le tour a été renvoyé sans streaming à ce second modèle dans les deux cas, y compris après l'affichage d'une partie de la réponse. Les canaux et le WebSocket de la passerelle n'ont pas été exécutés. Documentation vérifiée le 21 septembre 2026.
Que signifie [stream interrupted] dans ZeroClaw ?
Il s'agit du marqueur visible par l'utilisateur pour un flux de transport interrompu en cours de tour, défini dans le fichier de locale anglais de ZeroClaw comme la clé Fluent turn-stream-interrupted et affiché sur chaque transport — canaux, WS, RPC, ACP et CLI. Il s'agit volontairement d'un marqueur différent de [interrupted by user] et [turn cancelled via client] ; sa présence indique donc que personne n'a appuyé sur le bouton d'arrêt. Lorsque le flux s'interrompt après l'affichage d'une sortie, le texte partiel est conservé comme message de l'assistant avec le marqueur ajouté, mais uniquement lorsque ce texte partiel n'est pas vide : un tour qui n'a produit que du raisonnement ou uniquement des événements d'outils préexécutés ne conserve rien. Les installations non anglophones utilisent la même clé avec un texte traduit ; ne recherchez donc pas la chaîne anglaise entre crochets dans l'une d'elles. Lecture effectuée sur le tag de version v0.8.5 le 21 septembre 2026. Dans le client de terminal interactif de v0.8.5, le 1er octobre 2026, une coupure du flux en cours de réponse n'a pas affiché ce marqueur ; le terminal a affiché une erreur d'échec du fournisseur.
Puis-je simplement renvoyer l'invite après une interruption de flux ZeroClaw ?
Pas automatiquement, et les mainteneurs de ZeroClaw le traitent eux-mêmes ainsi. Le runtime lit un flux jusqu'à son terme, récupère les appels d'outils après la fin du flux, puis les exécute — les outils de l'itération interrompue n'ont donc pas été exécutés. Mais un long tour peut également s'interrompre lors d'itérations ultérieures : un rapport en amont indique que l'appel d'outil précédent s'était terminé avec succès avant l'échec, et le journal d'un autre rapport montre une interruption à l'itération 2 avec 126 messages dans la requête. Tout ce qu'une itération précédente a déjà effectué — un fichier écrit, une commande exécutée, un message envoyé — se reproduira si vous renvoyez aveuglément la même invite. La demande de fonctionnalité ouverte consacrée à la récupération guidée énumère elle-même parmi ses objectifs exclus le rejeu aveugle d'un tour comportant des outils ou des autorisations, ainsi que le traitement de chaque erreur de fournisseur comme transitoire. Lisez d'abord le texte partiel conservé, vérifiez ce qui a déjà pris effet, puis renvoyez une invite restreinte plutôt que l'originale.
Puis-je configurer ZeroClaw pour reprendre le flux interrompu ?
Non. Aucune version publiée ne propose de paramètre pour cela, et aucun forfait payant ne permet d'en débloquer un — ZeroClaw est gratuit et open source, sous double licence MIT OR Apache-2.0, sans abonnement ni siège hébergé ; cette limite relève donc de l'ingénierie et non du forfait. La règle d'absence de rejeu après une sortie visible figure dans le code source et est verrouillée par un test de non-régression dont le message d'échec indique lui-même qu'une erreur de flux après une sortie visible doit faire échouer le tour sans nouvelle tentative de repli — bien que, dans le client de terminal interactif de v0.8.5 le 1er octobre 2026, un profil comportant un second candidat ait effectivement renvoyé la requête après l'affichage du texte ; la règle n'est donc pas une garantie sur chaque transport. La récupération guidée après un tour interrompu correspond à l'issue #10634 — ouverte, portant les étiquettes status:accepted et priority:p2, et orientée d'abord vers un travail de conception ou une discussion RFC, selon l'état constaté au 21 septembre 2026. « Accepted » signifie que le triage a accepté l'énoncé du problème, et non que le code a été écrit ou fusionné.
Mon journal indique un basculement vers le chat sans streaming, puis le tour s'interrompt. Pourquoi ?
Dans la version publiée v0.8.5, cette ligne du journal peut être fausse. L'issue amont #10736, intitulée « une défaillance du flux avant la sortie ignore le repli sans streaming annoncé », rapporte que le runtime journalise un basculement vers le chat sans streaming mais n'envoie pas la requête sans streaming ; le tour se termine immédiatement avec All model providers/models failed after 0 failure event(s). Sa déclaration d'impact désigne comme population concernée les utilisateurs disposant d'un seul candidat fournisseur, en particulier les configurations avec zéro nouvelle tentative. Zéro nouvelle tentative n'est toutefois pas le seul cas : sa reproduction définit provider_retries = 0, mais l'issue suivante #10787 reproduit le même échec immédiat avec provider_retries laissé à sa valeur par défaut documentée de 2. L'issue a été clôturée le 18 septembre 2026, après la publication de v0.8.5 le 5 septembre ; aucune version publiée ne contient donc le correctif. Le problème a été reproduit dans v0.8.5 le 1er octobre 2026 : une requête en streaming, aucun suivi sans streaming, puis cette erreur — avec provider_retries = 2, que le flux se soit interrompu avant ou après l'apparition du texte. L'ajout d'un second modèle dans fallback_models a suffi à récupérer le tour. Pour déboguer cela à partir des journaux de v0.8.5, il faut comprendre qu'un repli n'a pas eu lieu.
Le tour interrompu m'a-t-il été facturé, et comment le vérifier ?
Consultez l'enregistrement d'utilisation propre à l'endpoint plutôt que celui de ZeroClaw, car la documentation de v0.8.5 vous indique de ne pas vous fier à son chiffre par tentative : elle décrit la notification de repli finale comme une notification de succès, et non comme un registre canonique de chaque tentative, et précise qu'il ne faut pas en déduire l'exactitude du coût par tentative. Le registre par tentative usage_by_provider qui permet de résoudre ce point est arrivé sur master via la pull request #8966, fusionnée le 18 septembre 2026, après la publication de v0.8.5 ; il ne figure donc dans aucune version — et master le limite aux chemins de tour instrumentés par des événements. ZeroClaw capture bien un instantané d'utilisation lors d'un flux interrompu, mais le champ est facultatif et peut être absent ; il demande en outre aux endpoints compatibles OpenAI l'utilisation dans un dernier fragment SSE — fragment qu'un flux tronqué peut ne jamais transmettre. Ce dernier point est déduit du code source et non observé à l'exécution. Par ailleurs, les propres chiffres de coût de ZeroClaw proviennent des grilles tarifaires [cost.rates] saisies par l'opérateur dans votre configuration ; un endpoint qui n'y est pas tarifé ne l'est pas non plus par ZeroClaw.
Exécution du 1er octobre 2026 : le binaire de la version v0.8.5 en mode terminal interactif, face à un serveur de test local qui a interrompu le flux — les quatre lignes du tableau de résultats ; rien d’autre n’a été exécuté et aucune requête n’a été envoyée à Kunavo. Les états des problèmes ont été revérifiés le même jour (#10787 est depuis lors fermé ; #10634 est toujours ouvert). Le code source du dépôt a été consulté sur l’étiquette de version v0.8.5, la documentation sur le chemin /v0.8.5/ correspondant à cette version, et les états des problèmes et demandes de modification ont été consultés le 21 septembre 2026 ; plusieurs de ces problèmes étaient marqués comme en cours et peuvent évoluer. Les tarifs des jetons Kunavo proviennent du catalogue actuel, et chaque montant en dollars indiqué ici est un calcul indicatif de jetons, et non le coût mesuré d’une tâche.