ZeroClaw nunca reanuda un flujo interrumpido. Que vuelva a enviar el turno depende de cuántos candidatos tenga su perfil y, en la única versión publicada actualmente, no coincide del todo con lo que promete la documentación. La documentación de ZeroClaw para v0.8.5 (publicada el 5 de septiembre de 2026) indica que un flujo que falla antes de cualquier salida se reintenta sin streaming, y que uno que falla después de la salida nunca se repite. Ejecutado el 1 de octubre de 2026 contra un endpoint que interrumpió el flujo a mitad de la respuesta, el cliente de terminal de v0.8.5 hizo algo más sencillo: con un candidato no envió ningún reintento, ni antes ni después de que apareciera texto; con un segundo candidato, reenvió el turno sin streaming a ese segundo modelo, incluso después de que parte de la respuesta ya estuviera en pantalla. La recuperación guiada después de una salida parcial es una solicitud de función abierta que aún no ha recibido aprobación de diseño. Por tanto, la pregunta útil no es cómo hacer que ZeroClaw reintente, sino si para usted es seguro volver a enviar el turno y cuánto costó ya el intento interrumpido
Dos notas de alcance antes de que nada de esto sea aplicable. Lo ejecutado es limitado: el binario de la versión v0.8.5 en su modo de terminal interactivo, un endpoint compatible con OpenAI y un servidor de prueba local que cerró el flujo deliberadamente; los resultados aparecen a continuación. No se ejecutaron Channels, el WebSocket del gateway, RPC, ACP, el slot de Anthropic ni interrupciones reales de proveedores. Todas las demás afirmaciones se han extraído del repositorio en la etiqueta de versión v0.8.5, de la documentación fijada por versión en docs.zeroclaw.com/v0.8.5/ o de informes de issues upstream fechados, todo ello el 21 de septiembre de 2026. Y fije usted mismo esa URL: el README dirige a los lectores a la ruta /master/, cuyo HEAD está dieciséis días por delante de la versión y la contradice precisamente en este tema, mientras que /latest/ devuelve 404. ZeroClaw aquí significa el runtime zeroclaw-labs/zeroclaw; si no está seguro de que eso es lo que está ejecutando, ZeroClaw frente a OpenClaw lo diferencia de los proyectos y forks que comparten el nombre
Cuatro marcadores en v0.8.5, y solo uno de ellos es la red
Antes de decidir nada, lea qué marcador recibió realmente. El archivo de configuración regional en inglés de ZeroClaw en v0.8.5 define estas claves Fluent distintas bajo un comentario de encabezado que indica que se añaden a la salida del asistente, o se conservan como ella, cuando un turno se interrumpe, y que se muestran a los usuarios finales en todos los transportes: channels, WS, RPC, ACP y CLI
| Marcador | Clave Fluent | Qué le indica |
|---|---|---|
[stream interrupted] | turn-stream-interrupted | El flujo de transporte murió a mitad del turno. Nadie pulsó detener |
[interrupted by user] | turn-interrupted-by-user | Una interrupción humana |
[turn cancelled via client] | turn-cancelled-client-rpc | El canal, no el actor. El comentario del código indica que las interrupciones humanas y las cancelaciones programáticas del cliente llegan ambas por esta ruta, por lo que la redacción nombra el canal |
[interrupted by user before this tool produced a result] | turn-tool-interrupted-before-result | Una herramienta fue interrumpida antes de devolver resultados |
Una quinta clave, turn-failed = [turn failed], existe en el mismo archivo en master, pero no está en el archivo de configuración regional de v0.8.5, por lo que una versión publicada no la emite. Hay un comportamiento que conviene conocer porque cambia lo que puede leer después: el motor de turnos conserva el texto parcial con el marcador añadido solo cuando ese texto parcial no está vacío. Un turno que produjo razonamiento o eventos de herramientas preejecutados por el proveedor, pero ningún texto visible, no conserva absolutamente nada; el comentario del código plantea la persistencia como la confirmación de lo que el consumidor ya vio. Las demás configuraciones regionales contienen las mismas claves con valores traducidos, por lo que la cadena literal entre corchetes en inglés no es la que muestra una instalación en otro idioma
Dónde se encuentra realmente el límite de reintento
Toda la decisión se reduce a una pregunta: ¿había llegado ya algo a un sumidero de eventos inmutable?
| Qué ocurrió | Comportamiento documentado en v0.8.5 | Observación |
|---|---|---|
| El flujo falla antes de cualquier salida visible | El runtime reintenta la llamada completa mediante la ruta sin streaming, volviendo a entrar en todo el recorrido de fiabilidad | Documentado, pero no es lo que observó una configuración con un único candidato en la versión publicada; consulte más abajo |
| El flujo termina sin texto final y sin llamadas a herramientas | Una respuesta semánticamente vacía, no una respuesta. Cuando el resultado está marcado como seguro para repetir y provider_retries es distinto de cero, se realiza una única llamada de recuperación sin streaming al mismo proveedor y modelo exactos, y se consume una vez | Incluido en v0.8.5 mediante el pull request #10602, integrado el 4 de septiembre de 2026. Se aplica a flujos vacíos, no a flujos que se interrumpieron a mitad de la salida |
| El texto, el razonamiento o los eventos de herramientas preejecutados ya llegaron a un sumidero de eventos inmutable | StreamInterruptedAfterOutput. El runtime no repite la solicitud, y el texto ya reenviado al consumidor es todo lo que se convierte en texto parcial persistido del asistente | Deliberado e idéntico en master. Bloqueado por una prueba de regresión que afirma que un error del flujo después de una salida visible debe hacer que el turno falle sin un reintento alternativo |
| Cualquiera de los anteriores | El flujo se abre una sola vez y las entradas no se cambian después de que se haya iniciado | La recuperación siempre es una solicitud nueva. Ninguna familia de proveedores, incluido el slot personalizado, obtiene una ruta de reanudación |
Los controles que existen son globales, no específicos de cada endpoint. [reliability] contiene provider_retries, cuyo valor predeterminado documentado es 2, y provider_backoff_ms, cuyo valor predeterminado es 500; el documento del ciclo de vida indica que cada entrada materializada se intenta hasta provider_retries + 1 veces. La referencia de configuración de v0.8.5 no documenta junto a ellos ninguna anulación de reintentos por proveedor o por alias. Tampoco cuente con el grupo de claves: la documentación de v0.8.5 indica que reliability.api_keys no permite actualmente una conmutación por error funcional, porque el wrapper selecciona y registra una clave alternativa después de un límite de velocidad reintentable, pero no puede aplicarla al proveedor construido, por lo que el reintento sigue utilizando la credencial original. Una segunda clave añadida esperando que sirviera de rescate no lo proporciona
Apuntar a un único endpoint es la configuración que sale perjudicada
Este es el límite más importante para cualquiera que ejecute ZeroClaw contra un único gateway o un único endpoint de proveedor, porque un endpoint es, por definición, una configuración de fiabilidad con un único candidato. El issue #10736 informa de que, en la versión publicada, un fallo del flujo antes de la salida en esa configuración registra una alternativa al chat sin streaming y luego nunca la envía, lo que termina el turno con All model providers/models failed after 0 failure event(s). Se cerró el 18 de septiembre de 2026, después de la publicación de v0.8.5, por lo que la corrección solo está en master. Ejecutado el 1 de octubre de 2026, v0.8.5 se comportó exactamente como describe el issue: una solicitud y luego ese error, tanto si el flujo se interrumpía antes como después de que apareciera texto
Aquí discrepan dos posiciones oficiales y conviene conservar ambas. El documento de arquitectura de v0.8.5 promete el reintento sin streaming; el issue demuestra que la versión publicada no lo realiza, y su sección de comportamiento esperado solicita que el registro solo afirme que hay una alternativa cuando realmente vaya a intentarse. Después, master añade una posibilidad de recuperación para un único candidato que la versión publicada no tiene, y el issue #10787 indicaba que esa posibilidad se concedía con RetryDecision::Admit(0) independientemente de provider_retries y sin espera, por lo que un upstream sobrecargado se reenviaba inmediatamente durante la misma ventana de saturación. Ese issue se cerró como completado el 26 de septiembre de 2026, en master, después de v0.8.5, por lo que tampoco está en ninguna versión publicada. El comportamiento de master sigue cambiando; no planifique basándose en él
La forma documentada de mitigar el problema es una configuración, no un ajuste: proporcione al perfil un segundo candidato para que el recorrido de fiabilidad tenga adónde ir. El 1 de octubre de 2026 funcionó en v0.8.5 desde la terminal, con una salvedad que conviene conocer antes de confiar en ello: la solicitud de recuperación se dirigió al segundo modelo, no al primero, por lo que la respuesta que obtiene después de una interrupción procede de su alternativa. La guía de costes y configuración de la API de ZeroClaw cubre la estructura de configuración en la que se introducen esas entradas
Qué hizo v0.8.5 cuando se interrumpió el flujo
El 1 de octubre de 2026, el binario de la versión v0.8.5, cuyo checksum se verificó frente a SHA256SUMS de la versión, se ejecutó en un contenedor desechable en modo de terminal interactivo, el modo que transmite por streaming; el modo -m de un solo mensaje envía una solicitud sin streaming y nunca llega a esta ruta. Un perfil de slot personalizado compatible con OpenAI, provider_retries = 2, apuntaba a un servidor de prueba local que respondía con un flujo normal y luego cerraba la conexión sin [DONE], ya fuera antes del primer evento o después de un fragmento de texto
| Perfil | Dónde se interrumpió el flujo | Solicitudes enviadas | Lo que mostró el terminal |
|---|---|---|---|
| Un candidato | Antes de cualquier texto | Una solicitud de streaming, sin reintento | Error: El proveedor de modelos seleccionado falló. Revisa la configuración del proveedor o elige otro proveedor. El registro: Todos los proveedores/modelos de modelos fallaron después de 0 evento(s) de fallo |
| Un candidato | Después de que se imprimiera el texto | Una solicitud de streaming, sin reintento | El texto parcial y, después, el mismo error. No se imprimió el marcador [stream interrupted] |
Además, fallback_models con un segundo modelo | Antes de cualquier texto | La solicitud de streaming y, después, una solicitud sin streaming al segundo modelo | La respuesta del segundo modelo |
Además, fallback_models con un segundo modelo | Después de que se imprimiera el texto | Las mismas dos solicitudes | El texto parcial y, después, la respuesta completa del segundo modelo — por lo que la respuesta aparece dos veces |
De aquí se desprenden tres cosas para cualquiera que ejecute ZeroClaw desde un terminal en v0.8.5. El fallo con un solo candidato corresponde al issue #10736, reproducido; provider_retries no lo cambió. El límite documentado de «no reproducir después de una salida visible» no se aplicó aquí: el texto ya impreso en el terminal no impidió un reenvío, así que un turno cuya llegada viste a medias todavía puede enviarse de nuevo a otro modelo. Además, el registro del turno anotó el primer modelo como el modelo del turno, mientras que el texto procedía del segundo, precisamente la brecha de atribución sobre la que advierte la propia documentación de v0.8.5. Lo que esta ejecución no cubre: canales como Telegram o Slack, el WebSocket de la pasarela, clientes RPC y ACP — los transportes cuyos receptores de eventos son el objetivo de la regla de no reproducción —, el parámetro de Anthropic, interrupciones reales del proveedor y cualquier solicitud a través de Kunavo.
Antes de reenviar: qué ya se ejecutó y qué ya se facturó
El propio bucle de herramientas de ZeroClaw lee el flujo hasta completarlo, recupera las llamadas a herramientas cuando termina, las ejecuta y luego abre una nueva llamada de streaming para el siguiente turno del asistente. Por tanto, las herramientas solicitadas por la iteración que se interrumpió no se ejecutaron — pero es un consuelo más limitado de lo que parece. Las llamadas a herramientas preejecutadas en el lado del proveedor son una clase de evento independiente que ya produjo efectos en el sistema ascendente, precisamente por eso bloquean la reproducción. Además, los turnos largos fallan tarde: el #10736 señala que la llamada a herramienta anterior se completó correctamente antes del fallo, y el registro de #10787 muestra que la interrupción ocurrió en la iteración 2, con 126 mensajes en la solicitud. Reenviar el mensaje original reproduce todos los efectos secundarios anteriores que el modelo repetiría.
Tampoco una transcripción de aspecto limpio es una prueba. El issue #9421, abierto con prioridad p1 tanto para las familias de proveedores Anthropic como para las compatibles con OpenAI, se titula que las respuestas incompletas del terminal pueden informarse como exitosas. En la superficie Code/ACP, otros dos informes p1 abiertos describen un turno fallido que descarta mensajes aceptados y conversaciones de herramientas completadas del historial persistente (#10788) y un turno que excede el presupuesto y pierde el progreso visible después de restaurar la sesión (#10659), mientras que la solicitud de incorporación para persistir el progreso del turno interrumpido sigue sin fusionarse. Todos estaban abiertos el 21 de septiembre de 2026 y varios aparecen marcados como en progreso, así que vuelve a comprobarlo en lugar de citar esta instantánea.
En cuanto al coste, v0.8.5 y master realmente difieren, y debes leer el que corresponda a tu compilación. La documentación de la versión llama al registro final un aviso de éxito, no un libro mayor canónico de cada intento, y dice que no se debe inferir de él la exactitud del coste por intento; master sustituye ese párrafo por un libro mayor usage_by_provider por intento procedente de la solicitud de incorporación #8966, fusionada el 18 de septiembre de 2026, que ninguna versión publicada contiene y que el propio master limita a las rutas de turno instrumentadas para eventos. Mientras tanto, la instantánea de uso del flujo interrumpido es un campo opcional que puede faltar, y ZeroClaw solicita uso a los endpoints compatibles con OpenAI en un fragmento SSE final — el que quizá nunca envíe un flujo truncado. Considera este último punto un mecanismo que debes comprobar en tus propios datos de costes, no un resultado medido. Contrasta el resultado con el propio registro de uso del endpoint; en Kunavo, es el registro de uso.
Por qué una pasarela delante de un modelo produce este marcador
La causa más probable de terceros es que nunca llegue una señal de finalización. La documentación de streaming de ZeroClaw v0.8.5 afirma que los transportes no dependen del cierre de la conexión como señal de éxito: los flujos compatibles con OpenAI terminan en [DONE], los flujos de OpenAI Responses en su evento de respuesta terminal y los flujos de Anthropic en message_stop; los servidores pueden mantener abierta la conexión HTTP después de esos eventos. Un flujo que se cierra sin su señal se muestra como un error — SSE stream closed before {completion_signal}: response truncated — en lugar de como un éxito breve. Es un defecto del endpoint, no de ZeroClaw. Hay una excepción documentada: el analizador de Anthropic actualmente también considera completo un EOF después de un message_delta.stop_reason no vacío, incluso sin message_stop, y la solicitud de incorporación que propone exigirlo no se ha incorporado en ninguna de las dos referencias.
La segunda causa es el silencio en un socket abierto. ZeroClaw utiliza tiempos de espera por inactividad de bytes, no un límite para la solicitud completa, documentados como 300 segundos para OpenAI Responses y los proveedores compatibles con OpenAI, y 90 segundos para Anthropic; cada lectura del cuerpo reinicia el reloj. Un endpoint que almacena en búfer una respuesta ascendente y no reenvía nada durante un minuto y medio activa el parámetro de la familia Anthropic, pero sobrevive en el compatible con OpenAI — conviene saberlo porque un endpoint de Anthropic Messages se coloca en el parámetro anthropic con una sobrescritura uri, no en custom. Consulta la documentación de la URL base de Messages y la API compatible con OpenAI para conocer los dos protocolos de red.
Cuánto cuesta un turno interrumpido, con aritmética ilustrativa
Separa las dos facturas. El tiempo de ejecución de ZeroClaw cuesta 0 $ — zeroclaw.com afirma que es de código abierto, con licencia dual MIT O Apache-2.0, sin suscripción ni puesto alojado, y que solo pagas los costes de tu propio proveedor de LLM, o nada si ejecutas un modelo local con Ollama. Ningún nivel desbloquea la reanudación, un presupuesto de reintentos mayor o la recuperación guiada, porque no existen niveles.
La factura del modelo es la que afecta una interrupción. Estas cifras son aritmética de tokens basada en supuestos, no el coste medido de una tarea ni el límite máximo de una factura. Supón un turno que envía 110.000 tokens de entrada no almacenados en caché — el tamaño de la solicitud registrado en el único episodio fechado de sobrecarga, el #10787, en el que el sistema ascendente aceptó la solicitud y ejecutó el prellenado antes de descartarla — y recibe 2.000 tokens de salida antes de que muera el flujo. La columna de tres intentos es provider_retries + 1, con el valor predeterminado documentado de 2. Las tarifas son precios actuales del catálogo de Kunavo por millón de tokens.
| Modelo | Entrada/salida por 1M | Un intento interrumpido | Tres intentos |
|---|---|---|---|
| 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 |
Que un endpoint determinado cobre por una solicitud que descartó depende de su propia política de facturación, y nada en el código fuente o la documentación de ZeroClaw lo establece — esta página no lo midió para ningún proveedor. La aritmética sirve para dimensionar la pregunta, no para responderla. El importe del catálogo de Kunavo es un mínimo de facturación, no un tope: cuando el sistema ascendente informa de su cargo, la factura es el mayor entre el coste del catálogo y el coste ascendente multiplicado por el margen aplicable. La recarga mínima es $10 en crédito prepago, un mínimo de financiación, no una tarifa por tarea ni una suscripción — consulta los detalles de facturación.
Qué ruta resiste mejor este fallo
| Ruta | Cómo se comporta ante una interrupción a mitad del flujo | A qué renuncias |
|---|---|---|
| Un endpoint, proveedor directo | Una configuración de fiabilidad con un único candidato, por lo que forma parte de la población descrita en el #10736 en v0.8.5 | Ser un proveedor propio no cambia el recorrido; un candidato sigue siendo un candidato |
| Un endpoint, pasarela | La misma estructura de candidato único. Lo que ofrece aquí una pasarela es cambiar de modelo con una sola clave y un solo saldo, no resiliencia del flujo | Un salto adicional que también puede cerrarse sin una señal de finalización, y ZeroClaw solo le asigna un precio si escribes tú mismo sus entradas [cost.rates] |
| Dos o más candidatos en el perfil | El recorrido de fiabilidad tiene adónde continuar. En la ejecución de terminal del 1 de octubre de 2026, se recuperó después de una interrupción temprana y otra a mitad de la respuesta — mediante el segundo modelo | Un segundo modelo o alias que mantener, y una respuesta recuperada que procede de tu alternativa en lugar de tu primera opción |
| Modelo local mediante Ollama | Un reenvío cuesta tiempo y hardware, no dinero, así que un reintento conservador es barato | La brecha de capacidad frente a los modelos de frontera alojados, y una máquina para ejecutar uno |
| Un agente con suscripción de tarifa plana | No es una ruta de ZeroClaw — el proyecto no tiene suscripción ni puesto alojado | Cambiarías de cliente, no el comportamiento de recuperación de ZeroClaw |
Elijas lo que elijas, la regla operativa es la que ZeroClaw ya codifica: después de [stream interrupted], lee la parte parcial persistida, determina qué ya tuvo efecto y luego reenvía algo más limitado que el original. Las referencias de configuración de Kunavo para endpoints compatibles con OpenAI y endpoints de estilo Messages son documentación de configuración, no una prueba de compatibilidad — la ejecución del 1 de octubre mencionada arriba utilizó un servidor de pruebas local, no Kunavo. Empieza por la referencia de errores para descifrar lo que devolvió tu endpoint y crea una cuenta de Kunavo cuando estés listo para financiar una clave. OpenRouter frente a LiteLLM es la comparación más cercana para la decisión entre un único candidato y varios descrita arriba.
Preguntas frecuentes
¿ZeroClaw reintenta un flujo que se interrumpió?
Depende completamente de si ya había visto salida. La documentación de enrutamiento de proveedores de ZeroClaw para la versión publicada v0.8.5 indica que el flujo se abre una sola vez y las entradas no se cambian después de iniciarse, por lo que nunca se reanuda: la recuperación, cuando existe, es una solicitud completamente nueva. Si el flujo falla antes de que sea visible cualquier salida de evento inmutable, el comportamiento documentado es que el runtime reintenta la llamada completa mediante la ruta sin streaming. Una vez que el texto, el razonamiento o los eventos de herramientas preejecutados han llegado a un sumidero de eventos inmutable, la interrupción se convierte en StreamInterruptedAfterOutput y el runtime no repite la solicitud. Esa segunda regla es la misma en master. Sin embargo, al ejecutarlo el 1 de octubre de 2026 en el cliente de terminal interactivo de v0.8.5, ninguna de las dos reglas se mostró tal como está escrita: con un candidato no se reintentó nada, ni antes ni después de que apareciera texto, y con un segundo candidato en fallback_models, el turno se reenvió sin streaming a ese segundo modelo en ambos casos, incluso después de que se hubiera impreso parte de la respuesta. No se ejecutaron Channels ni el WebSocket del gateway. Documentación comprobada el 21 de septiembre de 2026
¿Qué significa [stream interrupted] en ZeroClaw?
Es el marcador visible para el usuario de un flujo de transporte que murió a mitad del turno, definido en el archivo de configuración regional en inglés de ZeroClaw como la clave Fluent turn-stream-interrupted y mostrado en todos los transportes: channels, WS, RPC, ACP y CLI. Es deliberadamente diferente de [interrupted by user] y [turn cancelled via client], por lo que verlo indica que nadie pulsó detener. Cuando el flujo muere después de que haya salida visible, el texto parcial se conserva como un mensaje del asistente con el marcador añadido, pero solo cuando ese texto parcial no está vacío: un turno que produjo únicamente razonamiento o únicamente eventos de herramientas preejecutados no conserva nada. Las instalaciones en idiomas distintos del inglés llevan la misma clave con texto traducido, así que no busque la cadena entre corchetes en inglés en una de ellas. Leído en la etiqueta de versión v0.8.5 el 21 de septiembre de 2026. En el cliente de terminal interactivo de v0.8.5, el 1 de octubre de 2026, un flujo interrumpido a mitad de la respuesta no mostró este marcador; la terminal mostró en su lugar un error de fallo del proveedor
¿Es seguro volver a enviar sin más el prompt después de una interrupción del flujo de ZeroClaw?
No automáticamente, y los propios mantenedores de ZeroClaw lo tratan así. El runtime lee un flujo hasta completarlo, recupera las llamadas a herramientas después de que termine y luego las ejecuta, por lo que las herramientas de la iteración que se interrumpió no se han ejecutado. Pero un turno largo también puede interrumpirse en iteraciones posteriores: un informe upstream señala que la llamada a la herramienta anterior se completó correctamente antes del fallo, y el registro de otro muestra la interrupción en la iteración 2 con 126 mensajes en la solicitud. Todo lo que una iteración anterior ya haya hecho —un archivo escrito, un comando ejecutado, un mensaje enviado— volverá a ocurrir si reenvía el mismo prompt a ciegas. La solicitud de función abierta para la recuperación guiada enumera como objetivos excluidos repetir a ciegas un turno que contenga herramientas o aprobaciones, y tratar todos los errores del proveedor como transitorios. Lea primero el texto parcial conservado, compruebe qué ya tuvo efecto y luego reenvíe un prompt acotado en lugar del original
¿Puedo configurar ZeroClaw para reanudar el flujo interrumpido?
No. No existe ninguna configuración para ello en ninguna versión publicada, ni ningún nivel de pago que la desbloquee: ZeroClaw es gratuito y de código abierto, con licencia dual MIT OR Apache-2.0, sin suscripción ni puesto alojado, por lo que el límite es de ingeniería, no de plan. La regla de no repetir después de una salida visible está en el código fuente y bloqueada por una prueba de regresión cuyo propio mensaje de error indica que un error del flujo después de una salida visible debe hacer que el turno falle sin un reintento alternativo; aunque en el cliente de terminal interactivo de v0.8.5, el 1 de octubre de 2026, un perfil con un segundo candidato sí reenvió la solicitud después de imprimirse texto, por lo que la regla no es una garantía en todos los transportes. La recuperación guiada después de un turno interrumpido es el issue #10634: abierto, con estado etiquetado como status:accepted y prioridad:p2, y dirigido a needs design o a una discusión de RFC primero a fecha del 21 de septiembre de 2026. Accepted significa que el triaje aceptó la descripción del problema, no que se haya escrito o integrado código
Mi registro indica que está recurriendo al chat sin streaming y luego el turno muere. ¿Por qué?
En la versión publicada v0.8.5, esa línea del registro puede ser falsa. El issue upstream #10736, titulado que un fallo del flujo antes de la salida omite la alternativa sin streaming anunciada, informa de que el runtime registra que está recurriendo al chat sin streaming, pero no envía la solicitud sin streaming, y el turno termina inmediatamente con All model providers/models failed after 0 failure event(s). Su propia declaración de impacto identifica como población afectada a los usuarios con un único candidato de proveedor, especialmente las configuraciones con cero reintentos. Cero reintentos no es el único caso: su reproducción establece provider_retries = 0, pero el issue posterior #10787 reproduce el mismo fallo inmediato con provider_retries en el valor predeterminado documentado de 2. El issue se cerró el 18 de septiembre de 2026, después de que v0.8.5 se publicara el 5 de septiembre, por lo que ninguna versión publicada contiene la corrección. Se reprodujo en v0.8.5 el 1 de octubre de 2026: una solicitud con streaming, ningún seguimiento sin streaming y ese error, con provider_retries = 2, tanto si el flujo se interrumpía antes como después de que apareciera texto. Añadir un segundo modelo en fallback_models bastó para que el turno se recuperara. Depurar esto a partir de los registros en v0.8.5 significa leer una alternativa que no ocurrió
¿Se me cobró por el turno interrumpido y cómo puedo comprobarlo?
Compruebe el registro de uso propio del endpoint en lugar del de ZeroClaw, porque la documentación de v0.8.5 le indica que no confíe en su cifra por intento: describe el aviso de alternativa final como un aviso de éxito, no como un libro mayor canónico de cada intento, y dice que no debe inferirse de él la exactitud del coste por intento. El libro mayor por intento usage_by_provider que resuelve esto llegó a master mediante el pull request #8966, integrado el 18 de septiembre de 2026, después de la publicación de v0.8.5, por lo que no está en ninguna versión publicada, y master lo limita a rutas de turno instrumentadas con eventos. ZeroClaw captura una instantánea de uso en un flujo interrumpido, pero el campo es opcional y puede faltar, y solicita uso a los endpoints compatibles con OpenAI en un fragmento SSE final, el fragmento que un flujo truncado puede no entregar nunca. Este último punto se deduce del código fuente, no se observó en tiempo de ejecución. Por separado, las propias cifras de coste de ZeroClaw proceden de las hojas de tarifas [cost.rates] escritas por el operador en su configuración, por lo que un endpoint que no haya tarifado allí tampoco está tarifado por ZeroClaw
Ejecutado el 1 de octubre de 2026: el binario de la versión v0.8.5 en modo de terminal interactivo contra un servidor de pruebas local que interrumpió el flujo — las cuatro filas de la tabla de resultados; no se ejecutó nada más y ninguna solicitud se envió a Kunavo. Los estados de los issues se volvieron a comprobar el mismo día (#10787 se ha cerrado desde entonces; #10634 sigue abierto). El código fuente del repositorio se leyó en la etiqueta de versión v0.8.5, la documentación en la ruta /v0.8.5/ fijada a esa versión y los estados de issues y solicitudes de incorporación se leyeron el 21 de septiembre de 2026; varios de esos issues estaban marcados como en progreso y pueden cambiar. Las tarifas de tokens de Kunavo proceden del catálogo actual, y cada cifra en dólares aquí es aritmética ilustrativa de tokens, no el coste medido de una tarea.