O ZeroClaw nunca retoma um stream interrompido. O fato de reenviar o turno depende de quantos candidatos seu perfil tem e, na única versão atual, não corresponde exatamente ao que a documentação promete. A documentação do ZeroClaw para a v0.8.5 (publicada em 5 de setembro de 2026) diz que um stream que falha antes de qualquer saída é tentado novamente sem streaming, e que um que falha depois da saída nunca é reproduzido. Executado em 1º de outubro de 2026 contra um endpoint que interrompeu o stream no meio da resposta, o cliente de terminal da v0.8.5 fez algo mais simples: com um candidato, não enviou nenhuma nova tentativa, antes ou depois de o texto aparecer; com um segundo candidato, reenviou o turno, sem streaming, para esse segundo modelo — mesmo depois de parte da resposta já estar na tela. A recuperação guiada após uma saída parcial é uma solicitação de recurso aberta que ainda não recebeu aprovação de design. Portanto, a pergunta útil não é como fazer o ZeroClaw tentar novamente. É se o seu turno pode ser reenviado com segurança e quanto a tentativa interrompida já custou.
Duas observações de escopo antes que qualquer parte disso possa ser acionável. O que foi executado é restrito: o binário da versão v0.8.5 em seu modo de terminal interativo, um endpoint compatível com OpenAI e um servidor de teste local que encerrou o stream de propósito — os resultados estão abaixo. Canais, o WebSocket do gateway, RPC, ACP, o slot da Anthropic e interrupções reais dos provedores não foram executados. Todas as outras afirmações foram lidas no repositório na tag de lançamento v0.8.5, na documentação fixada nessa versão em docs.zeroclaw.com/v0.8.5/ ou em relatórios de issues upstream datados, todos em 21 de setembro de 2026. E fixe essa URL você mesmo: o README direciona os leitores para o caminho /master/, cujo HEAD está dezesseis dias à frente da versão e o contradiz exatamente neste assunto, enquanto /latest/ retorna 404. ZeroClaw aqui significa o runtime zeroclaw-labs/zeroclaw; se você não tiver certeza de que é isso que está executando, ZeroClaw vs OpenClaw o diferencia dos projetos e forks que compartilham o nome.
Quatro marcadores em v0.8.5, e apenas um deles é a rede
Antes de decidir qualquer coisa, leia qual marcador você realmente recebeu. O arquivo de locale em inglês do ZeroClaw na v0.8.5 define estes como chaves Fluent distintas sob um comentário de cabeçalho que diz que elas são anexadas à saída do assistente, ou persistidas como tal, quando um turno é interrompido, e exibidas aos usuários finais em todos os transportes — canais, WS, RPC, ACP e CLI.
| Marcador | Chave Fluent | O que isso informa |
|---|---|---|
[stream interrupted] | turn-stream-interrupted | O stream de transporte morreu no meio do turno. Ninguém pressionou parar. |
[interrupted by user] | turn-interrupted-by-user | Uma interrupção humana. |
[turn cancelled via client] | turn-cancelled-client-rpc | O canal, não o ator. O próprio comentário do código diz que interrupções humanas e cancelamentos programáticos do cliente chegam por este caminho, portanto o texto nomeia o canal. |
[interrupted by user before this tool produced a result] | turn-tool-interrupted-before-result | Uma ferramenta foi interrompida antes de retornar. |
Uma quinta chave, turn-failed = [turn failed], existe no mesmo arquivo em master, mas não está no arquivo de locale da v0.8.5, portanto uma build lançada não a emite. Vale conhecer um comportamento porque ele muda o que você pode ler depois: o mecanismo de turnos persiste o texto parcial com o marcador anexado somente quando esse texto parcial não está vazio. Um turno que produziu raciocínio ou eventos de ferramentas pré-executados pelo provedor, mas nenhum texto visível, não persiste absolutamente nada — o comentário do código descreve a persistência como o commit do que o consumidor já viu. Outros locales carregam as mesmas chaves com valores traduzidos, portanto a string literal entre colchetes em inglês não é o que uma instalação em outro idioma exibe.
Onde o limite de retry realmente fica
Toda a decisão se reduz a uma pergunta: algo já chegou a um coletor de eventos imutável?
| O que aconteceu | Comportamento documentado na v0.8.5 | Ressalva |
|---|---|---|
| O stream falha antes de qualquer saída visível | O runtime tenta novamente a chamada inteira pelo caminho sem streaming, reentrando no fluxo completo de confiabilidade | Documentado, mas não foi o que uma configuração com um único candidato observou na build lançada — veja abaixo |
| O stream termina sem texto final e sem chamadas de ferramentas | Uma resposta semanticamente vazia, não uma resposta. Quando o resultado é marcado como seguro para replay e provider_retries é diferente de zero, uma chamada de recuperação sem streaming para exatamente o mesmo provedor e modelo, consumida uma vez | Entregue na v0.8.5 pela pull request #10602, mesclada em 4 de setembro de 2026. Aplica-se a streams vazios, não a streams que falharam no meio da saída |
| Texto, raciocínio ou eventos de ferramentas pré-executados já chegaram a um coletor de eventos imutável | StreamInterruptedAfterOutput. O runtime não reproduz a requisição, e somente o texto já encaminhado ao consumidor se torna texto parcial persistido do assistente | Deliberado e idêntico em master. Bloqueado por um teste de regressão que afirma que um erro de stream após saída visível deve falhar o turno sem retry de fallback |
| Qualquer um dos casos acima | O stream é aberto uma vez e as entradas não são trocadas depois que ele começa | A recuperação é sempre uma nova requisição. Nenhuma família de provedores, incluindo o slot personalizado, recebe um caminho de retomada |
Os controles que existem são globais, não por endpoint. [reliability] contém provider_retries, com padrão documentado de 2, e provider_backoff_ms, padrão 500, e o documento do ciclo de vida afirma que cada entrada materializada é tentada até provider_retries + 1 vezes. A referência de configuração da v0.8.5 não documenta nenhuma substituição de retry por provedor ou alias junto deles. Também não conte com o pool de chaves: a documentação da v0.8.5 diz que reliability.api_keys não é um failover funcional atualmente, porque o wrapper seleciona e registra uma chave alternativa após um limite de taxa passível de retry, mas não consegue aplicá-la ao provedor construído, portanto o retry ainda usa a credencial original. Uma segunda chave adicionada esperando uma recuperação não oferece uma.
Apontar para um único endpoint é a configuração que mais sofre
Este é o limite mais importante para quem executa o ZeroClaw contra um único gateway ou endpoint de fornecedor, porque um endpoint é, por definição, uma configuração de confiabilidade com um único candidato. A Issue #10736 relata que, na build lançada, uma falha de stream antes da saída nesse formato registra um fallback para chat sem streaming e depois nunca o envia, encerrando o turno com All model providers/models failed after 0 failure event(s). Ela foi encerrada em 18 de setembro de 2026 — após a publicação da v0.8.5 — portanto a correção existe apenas em master. Executada em 1º de outubro de 2026, a v0.8.5 lançada se comportou exatamente como a issue descreve: uma requisição e depois esse erro, independentemente de o stream ter falhado antes ou depois de o texto aparecer.
Duas posições oficiais divergem aqui, e vale manter ambas. O documento de arquitetura da v0.8.5 promete o retry sem streaming; a issue demonstra que a build lançada não o executa, e sua seção de comportamento esperado pede que o log só alegue um fallback quando um realmente será tentado. Master então adiciona uma permissão de recuperação para um único candidato que a versão lançada não possui — e a issue #10787 disse que essa permissão foi concedida com RetryDecision::Admit(0) independentemente de provider_retries e sem backoff, portanto um upstream sobrecarregado foi reenviado imediatamente para a mesma janela de descarte. Essa issue foi encerrada como concluída em 26 de setembro de 2026 — em master, após a v0.8.5, portanto em nenhuma versão lançada. O comportamento de master ainda está mudando; não planeje com base nele.
A forma documentada de mitigação é uma alteração na configuração, não uma opção de ajuste: dê ao perfil um segundo candidato para que o fluxo de confiabilidade tenha para onde ir. Em 1º de outubro de 2026, isso funcionou na v0.8.5 no terminal — com uma ressalva que vale conhecer antes de confiar nisso: a requisição de recuperação foi para o segundo modelo, não para o primeiro, portanto a resposta obtida após uma interrupção vem do seu fallback. O guia de custos e configuração da API do ZeroClaw aborda o formato de configuração em que essas entradas são inseridas.
O que a v0.8.5 fez quando o stream foi interrompido
Em 1º de outubro de 2026, o binário da versão v0.8.5, verificado por checksum contra o SHA256SUMS da versão, foi executado em um contêiner descartável no modo de terminal interativo — o modo que usa streaming; o modo -m de mensagem única envia uma requisição sem streaming e nunca chega a este caminho. Um perfil de slot personalizado compatível com OpenAI, provider_retries = 2, apontou para um servidor de teste local que respondeu com um stream normal e depois fechou a conexão sem [DONE], seja antes do primeiro evento ou depois de um trecho de texto.
| Perfil | Onde o stream falhou | Requisições enviadas | O que o terminal exibiu |
|---|---|---|---|
| Um candidato | Antes de qualquer texto | Uma requisição de streaming, sem retry | Erro: o provedor do modelo selecionado falhou. Revise a configuração do provedor ou escolha outro provedor. O log: Todos os provedores/modelos de modelo falharam após 0 evento(s) de falha |
| Um candidato | Depois que o texto foi impresso | Uma requisição de streaming, sem retry | O texto parcial, depois o mesmo erro. Nenhum marcador [stream interrupted] foi impresso |
Mais fallback_models com um segundo modelo | Antes de qualquer texto | A requisição de streaming, depois uma requisição sem streaming para o segundo modelo | A resposta do segundo modelo |
Mais fallback_models com um segundo modelo | Depois que o texto foi impresso | As mesmas duas requisições | O texto parcial, depois a resposta completa do segundo modelo — portanto a resposta aparece duas vezes |
Três conclusões se aplicam a quem executa o ZeroClaw em um terminal na v0.8.5. A falha com um único candidato é a #10736, reproduzida; provider_retries não a alterou. O limite documentado de "não reproduzir após saída visível" não se aplicou aqui: o texto já impresso no terminal não impediu um novo envio, portanto um turno que você viu chegar pela metade ainda pode ser enviado novamente, para um modelo diferente. E o log do turno registrou o primeiro modelo como o modelo do turno, enquanto o texto veio do segundo, que é a lacuna de atribuição sobre a qual a própria documentação da v0.8.5 alerta. O que esta execução não abrange: canais como Telegram ou Slack, o WebSocket do gateway, clientes RPC e ACP — os transportes cujos coletores de eventos são o alvo da regra de não reprodução —, o slot da Anthropic, interrupções reais dos provedores e qualquer requisição pelo Kunavo.
Antes de reenviar: o que já foi executado e o que já foi cobrado
O próprio loop de ferramentas do ZeroClaw lê o stream até o fim, recupera chamadas de ferramentas depois que ele termina, executa-as e então abre uma nova chamada de streaming para o próximo turno do assistente. Portanto, as ferramentas solicitadas pela iteração que falhou não foram executadas — mas isso é uma garantia mais limitada do que parece. Chamadas de ferramentas pré-executadas no lado do provedor são uma classe de eventos separada que já produziu efeitos no upstream, precisamente por isso impedindo a reprodução. E turnos longos falham tarde: a #10736 observa que a chamada de ferramenta anterior foi concluída com sucesso antes da falha, e o log da #10787 mostra a falha ocorrendo na iteração 2, com 126 mensagens na requisição. Reenviar o prompt original reproduz todos os efeitos colaterais anteriores que o modelo repetiria.
Um transcript com aparência limpa também não é prova. A Issue #9421, aberta com prioridade p1 contra as famílias de provedores Anthropic e compatíveis com OpenAI, tem como título que respostas incompletas do terminal podem ser reportadas como bem-sucedidas. Na superfície Code/ACP, outros dois relatórios p1 abertos descrevem um turno falho descartando prompts aceitos e trocas de ferramentas concluídas do histórico persistente (#10788) e um turno que excedeu o orçamento perdendo o progresso visível após a restauração da sessão (#10659), com a pull request para persistir o progresso de turnos interrompidos ainda não mesclada. Todas estavam abertas em 21 de setembro de 2026 e várias estão marcadas como em andamento, portanto verifique novamente em vez de citar este instantâneo.
Quanto ao custo, v0.8.5 e master realmente divergem, e você deve ler a versão correspondente à sua build. O documento da versão chama o registro final de aviso de sucesso, em vez de um livro-caixa canônico de todas as tentativas, e diz para não inferir dele a precisão do custo por tentativa; master substitui esse parágrafo por um livro-caixa por tentativa usage_by_provider da pull request #8966, mesclada em 18 de setembro de 2026, que nenhuma versão lançada contém e que o próprio master limita aos caminhos de turno instrumentados por eventos. Enquanto isso, o snapshot de uso de um stream interrompido é um campo opcional que pode estar ausente, e o ZeroClaw solicita uso aos endpoints compatíveis com OpenAI em um chunk SSE final — aquele que um stream truncado pode nunca enviar. Trate esse último ponto como um mecanismo a verificar na sua própria saída de custos, não como um resultado medido. Em vez disso, concilie com o próprio registro de uso do endpoint; no Kunavo, esse é o log de uso.
Por que um gateway diante de um modelo produz este marcador
A causa de terceiros mais provável é um sinal de conclusão que nunca chega. A documentação de streaming da v0.8.5 do ZeroClaw afirma que os transportes não dependem do fechamento da conexão como sinal de sucesso: streams compatíveis com OpenAI terminam em [DONE], streams da OpenAI Responses em seu evento de resposta terminal e streams da Anthropic em message_stop, e os servidores podem manter a conexão HTTP aberta após esses eventos. Um stream que fecha sem seu sinal é apresentado como erro — SSE stream closed before {completion_signal}: response truncated — em vez de um sucesso curto. Isso é um defeito do endpoint, não do ZeroClaw. Há uma exceção documentada: o parser da Anthropic atualmente também trata EOF após um message_delta.stop_reason não vazio como concluído, mesmo sem message_stop, e a pull request que propõe exigir isso não foi incorporada em nenhuma das duas refs.
A segunda causa é o silêncio em um socket aberto. O ZeroClaw usa timeouts de inatividade de bytes, não um prazo para a requisição inteira, documentados como 300 segundos para OpenAI Responses e provedores compatíveis com OpenAI e 90 segundos para Anthropic, com cada leitura do corpo reiniciando o relógio. Um endpoint que armazena uma resposta do upstream e não encaminha nada por um minuto e meio aciona o slot da família Anthropic enquanto sobrevive ao compatível com OpenAI — algo importante porque um endpoint Messages da Anthropic vai para o slot anthropic com uma substituição uri, não para custom. Consulte o documento da URL base do Messages e API compatível com OpenAI para os dois protocolos de transmissão.
Quanto custa um turno interrompido, em uma aritmética ilustrativa
Separe as duas cobranças. O runtime ZeroClaw custa $0 — zeroclaw.com afirma que ele é open source, licenciado duplamente sob MIT OU Apache-2.0, sem assinatura e sem assento hospedado, e que você paga apenas os custos do seu próprio provedor de LLM, ou absolutamente nada ao executar um modelo local com Ollama. Nenhum nível desbloqueia retomada, um orçamento de retry maior ou recuperação guiada, porque não existe nível.
A cobrança do modelo é a que uma interrupção afeta. Estes valores são aritmética de tokens baseada em premissas, não um custo de tarefa medido nem um teto de cobrança. Suponha um turno enviando 110.000 tokens de entrada não armazenados em cache — o tamanho do prompt no único episódio datado de sobrecarga registrado na #10787, em que o upstream aceitou a requisição e executou o prefill antes de descartá-la — e recebendo 2.000 tokens de saída antes de o stream morrer. A coluna de três tentativas é provider_retries + 1 no padrão documentado de 2. As tarifas são preços atuais do catálogo do Kunavo por milhão de tokens.
| Modelo | Entrada / saída por 1M | Uma tentativa interrompida | Três tentativas |
|---|---|---|---|
| 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 |
Se determinado endpoint cobra por uma requisição que ele descartou é uma política de cobrança própria desse endpoint, e nada no código-fonte ou na documentação do ZeroClaw afirma isso — esta página não mediu isso para nenhum provedor. A aritmética está aqui para dimensionar a questão, não para respondê-la. O valor do catálogo do Kunavo é um piso de cobrança, não um teto: quando o upstream informa sua cobrança, a fatura é o maior entre o custo do catálogo e o custo do upstream multiplicado pelo markup aplicável. O top-up mínimo é $10 em crédito pré-pago, um mínimo de financiamento, não uma taxa por tarefa ou assinatura — consulte detalhes de cobrança.
Qual rota se sustenta melhor contra esta falha
| Opção | Como se comporta em uma interrupção no meio do stream | O que você abre mão |
|---|---|---|
| Um endpoint, fornecedor direto | Uma configuração de confiabilidade com um único candidato, portanto incluída na população relatada pela #10736 na v0.8.5 | Nada em ser um fornecedor primário muda o fluxo; um candidato é um candidato |
| Um endpoint, gateway | Formato idêntico de candidato único. O que um gateway oferece aqui é a troca de modelos em uma chave e um saldo, não resiliência de stream | Um salto adicional que pode fechar sem um sinal de conclusão, e que o ZeroClaw só precifica se você escrever as entradas [cost.rates] por conta própria |
| Dois ou mais candidatos no perfil | O fluxo de confiabilidade tem para onde ir. Na execução de terminal de 1º de outubro de 2026, ele se recuperou após uma interrupção inicial e outra no meio da resposta — por meio do segundo modelo | Um segundo modelo ou alias para manter, e uma resposta recuperada que vem do seu fallback em vez da sua primeira escolha |
| Modelo local via Ollama | Um novo envio custa tempo e hardware, não dinheiro, portanto um retry conservador é barato | A lacuna de capacidade em relação aos modelos de fronteira hospedados, e uma máquina para executar um deles |
| Um agente de assinatura com tarifa fixa | Não é uma rota do ZeroClaw — o projeto não tem assinatura nem assento hospedado | Você estaria mudando o cliente, não o comportamento de recuperação do ZeroClaw |
Independentemente da sua escolha, a regra operacional é a que o ZeroClaw já codifica: após [stream interrupted], leia o parcial persistido, estabeleça o que já surtiu efeito e então reenvie algo mais restrito que o original. As referências de configuração do Kunavo para endpoints compatíveis com OpenAI e no estilo Messages são documentação de configuração, não um teste de compatibilidade — a execução de 1º de outubro acima usou um servidor de teste local, não o Kunavo. Comece pela referência de erros para decodificar o que seu endpoint retornou e crie uma conta no Kunavo quando estiver pronto para financiar uma chave. OpenRouter vs LiteLLM é a comparação mais próxima para a decisão entre um único candidato e vários apresentada acima.
Perguntas frequentes
O ZeroClaw tenta novamente um stream que foi interrompido?
Depende inteiramente de você já ter visto uma saída. A documentação de roteamento de provedores do ZeroClaw para a v0.8.5 lançada diz que o stream é aberto uma vez e que as entradas não são trocadas depois que ele começa; portanto, nada é retomado — a recuperação, quando existe, é uma nova solicitação. Se o stream falhar antes que qualquer saída de evento imutável fique visível, o comportamento documentado é que o runtime tente novamente a chamada inteira pelo caminho sem streaming. Quando texto, raciocínio ou eventos de ferramentas pré-executadas chegam a um coletor de eventos imutável, a interrupção se torna StreamInterruptedAfterOutput e o runtime não reproduz a solicitação. Essa segunda regra é a mesma no master. Mas, executado em 1º de outubro de 2026 no cliente de terminal interativo da v0.8.5, nenhuma das duas regras apareceu conforme escrita: com um candidato, nada foi tentado novamente, antes ou depois de o texto aparecer; e, com um segundo candidato em fallback_models, o turno foi reenviado sem streaming para esse segundo modelo nos dois casos, inclusive depois que parte da resposta havia sido impressa. Os canais e o WebSocket do gateway não foram executados. Documentação verificada em 21 de setembro de 2026.
O que significa [stream interrupted] no ZeroClaw?
É o marcador visível para o usuário de um stream de transporte que morreu no meio do turno, definido no arquivo de localidade em inglês do ZeroClaw como a chave Fluent turn-stream-interrupted e exibido em todos os transportes — canais, WS, RPC, ACP e CLI. Ele é deliberadamente diferente dos marcadores [interrupted by user] e [turn cancelled via client], portanto, vê-lo indica que ninguém pressionou parar. Quando o stream morre após uma saída visível, o texto parcial é persistido como uma mensagem do assistente com o marcador anexado, mas apenas quando esse texto parcial não está vazio: um turno que produziu somente raciocínio ou somente eventos de ferramentas pré-executadas não persiste nada. Instalações em outros idiomas carregam a mesma chave com texto traduzido, portanto, não use grep para procurar a string entre colchetes em inglês nessas instalações. Lido na tag de release v0.8.5 em 21 de setembro de 2026. No cliente de terminal interativo da v0.8.5, em 1º de outubro de 2026, um stream interrompido no meio da resposta não exibiu esse marcador; o terminal mostrou um erro de falha do provedor.
É seguro simplesmente reenviar o prompt após uma interrupção de stream do ZeroClaw?
Não automaticamente, e os próprios mantenedores do ZeroClaw tratam o caso dessa forma. O runtime lê um stream até o fim, recupera as chamadas de ferramentas depois que ele termina e então as executa — portanto, as ferramentas da iteração que falhou não foram executadas. Mas um turno longo também pode falhar em iterações posteriores: um relatório upstream observa que a chamada de ferramenta anterior foi concluída com sucesso antes da falha, e o log de outro mostra a falha ocorrendo na iteração 2, com 126 mensagens na solicitação. Tudo o que uma iteração anterior já fez — um arquivo escrito, um comando executado, uma mensagem enviada — acontece novamente se você reenviar o mesmo prompt às cegas. A solicitação de recurso aberta para recuperação guiada lista como objetivos excluídos reproduzir cegamente um turno que contenha ferramentas ou aprovações e tratar todo erro do provedor como transitório. Leia primeiro o texto parcial persistido, verifique o que já teve efeito e então reenvie um prompt mais restrito, em vez do original.
Posso configurar o ZeroClaw para retomar o stream interrompido?
Não. Não há uma configuração para isso em nenhuma versão lançada, nem um nível pago que a desbloqueie — o ZeroClaw é gratuito e de código aberto, com licença dupla MIT OR Apache-2.0, sem assinatura e sem assento hospedado; portanto, o limite é de engenharia, não de plano. A regra de não reproduzir após uma saída visível está no código-fonte e é protegida por um teste de regressão cuja própria mensagem de falha diz que um erro de stream após uma saída visível deve fazer o turno falhar sem uma nova tentativa de fallback — embora, no cliente de terminal interativo da v0.8.5 em 1º de outubro de 2026, um perfil com um segundo candidato tenha reenviado a solicitação depois que o texto foi impresso; portanto, a regra não é uma garantia em todos os transportes. A recuperação guiada após um turno interrompido é a issue #10634 — aberta, com as etiquetas status:accepted e priority:p2, e encaminhada primeiro para needs design ou discussão de RFC, conforme seu estado em 21 de setembro de 2026. Accepted significa que a triagem aceitou a descrição do problema, não que o código foi escrito ou mesclado.
Meu log diz que está recorrendo ao chat sem streaming e depois o turno morre. Por quê?
Na v0.8.5 lançada, essa linha do log pode ser falsa. A issue upstream #10736, intitulada como uma falha de stream anterior à saída que ignora o fallback sem streaming anunciado, relata que o runtime registra que está recorrendo ao chat sem streaming, mas não envia a solicitação sem streaming, e o turno termina imediatamente com All model providers/models failed after 0 failure event(s). A própria declaração de impacto identifica como população afetada os usuários com um único candidato de provedor, especialmente configurações com zero novas tentativas. Zero novas tentativas não é o único caso: a reprodução define provider_retries = 0, mas a issue subsequente #10787 reproduz a mesma falha imediata com provider_retries mantido no padrão documentado de 2. A issue foi encerrada em 18 de setembro de 2026, depois que a v0.8.5 foi publicada em 5 de setembro; portanto, nenhuma versão publicada contém a correção. Ela foi reproduzida na v0.8.5 em 1º de outubro de 2026: uma solicitação com streaming, nenhum acompanhamento sem streaming e aquele erro — com provider_retries = 2, independentemente de o stream ter falhado antes ou depois de o texto aparecer. Adicionar um segundo modelo em fallback_models foi suficiente para o turno se recuperar. Depurar isso pelos logs na v0.8.5 significa interpretar um fallback que não aconteceu.
Fui cobrado pelo turno interrompido e como verifico?
Verifique o próprio registro de uso do endpoint, não o do ZeroClaw, porque a documentação da v0.8.5 diz para não confiar no valor por tentativa: ela descreve o aviso de fallback final como um aviso de sucesso, não como um livro-razão canônico de todas as tentativas, e diz para não inferir precisão de custo por tentativa a partir dele. O livro-razão por tentativa usage_by_provider que resolve isso chegou ao master por meio da pull request #8966, mesclada em 18 de setembro de 2026, depois do lançamento da v0.8.5; portanto, está em nenhuma versão lançada — e o master o limita aos caminhos de turno instrumentados por eventos. O ZeroClaw captura um instantâneo de uso em um stream interrompido, mas o campo é opcional e pode estar ausente, e ele solicita uso aos endpoints compatíveis com OpenAI em um bloco SSE final — o bloco que um stream truncado talvez nunca entregue. Este último ponto foi deduzido do código-fonte, não observado em tempo de execução. Separadamente, os próprios valores de custo do ZeroClaw vêm das tabelas de taxas [cost.rates] escritas pelo operador na sua configuração; portanto, um endpoint que você não tenha precificado ali também não é precificado pelo ZeroClaw.
Executado em 1º de outubro de 2026: o binário da versão v0.8.5 em modo de terminal interativo contra um servidor de teste local que interrompeu o stream — as quatro linhas da tabela de resultados; nada mais foi executado e nenhuma requisição foi para o Kunavo. Os estados das issues foram verificados novamente no mesmo dia (#10787 foi encerrada desde então; #10634 ainda está aberta). O código-fonte do repositório foi lido na tag de lançamento v0.8.5, a documentação foi lida no caminho /v0.8.5/ fixado na versão e os estados de issues e pull requests foram lidos em 21 de setembro de 2026; várias dessas issues estavam marcadas como em andamento e podem mudar. As tarifas de tokens do Kunavo vêm do catálogo atual, e todo valor em dólares aqui é aritmética ilustrativa de tokens, não um custo de tarefa medido.