API Error: The response stopped arriving — o que significa e como resolver quando os dados da resposta do Claude Code param no meio

“API Error: The response stopped arriving” é o aviso de que, no meio de uma resposta, os dados pararam de chegar embora a conexão continuasse aberta, e o próprio temporizador de monitoramento do Claude Code encerrou essa conexão. A saída concluída até ali continua na tela. Em uma sessão interativa, basta responder continue para retomar a partir do último ponto concluído.

API Error: The response stopped arriving. The response above may be incomplete.

Antes da v2.1.227, essa mesma mensagem aparecia como Response stalled mid-stream. A referência oficial de erros registra a mudança de nome, e o que acontece é exatamente o mesmo. Ao procurar informações ou relatos de bugs escritos com a mensagem antiga, pesquise pelas duas formas.

1. O que a mensagem significa: não é queda, é “silêncio”

A referência oficial de erros do Claude Code explica que essa mensagem aparece quando a conexão continuou aberta, mas deixou de entregar dados, e por isso o monitor de inatividade do streaming (idle watchdog) a encerrou. Não é o corpo de um erro devolvido pela API: é uma nota que o próprio Claude Code, que estava recebendo a resposta, acrescenta.

Mesmo quando a resposta “para no meio”, o Claude Code usa textos diferentes conforme a causa. A documentação oficial lista as quatro mensagens abaixo, todas terminando com “The response above may be incomplete.” (a resposta acima pode estar incompleta).

API Error: Server error mid-response. The response above may be incomplete.
API Error: Connection lost mid-response. The response above may be incomplete.
API Error: Your computer went to sleep mid-response. The response above may be incomplete.
API Error: The response stopped arriving. The response above may be incomplete.

A primeira linha corresponde ao servidor devolver sobrecarga ou um erro 5xx no meio da resposta; a segunda, à queda da conexão; a terceira, ao computador entrar em suspensão durante a resposta. Só a quarta, a mensagem deste artigo, indica que os dados pararam de chegar sem que houvesse erro nem queda.

Quem encerra são quatro temporizadores de monitoramento

Segundo a documentação oficial de configuração de rede, o Claude Code tem quatro temporizadores que encerram streams que ficaram em silêncio. Eles existem para que uma conexão morta não fique travada para sempre e possa ser tratada como falha. Depois que a resposta começa a fluir, os que valem são os três primeiros da tabela abaixo.

Com conexão direta à API da Anthropic, a referência é o monitor em nível de bytes, de 180 segundos. Ou seja, até essa mensagem aparecer, a tela parece parada por alguns minutos. Segundo a documentação oficial, quando a requisição continua viva mas passa 20 segundos sem receber dados, antes aparece o aviso abaixo. Ele significa “ainda não falhou”, e a contagem regressiva vai até o momento do encerramento (antes da v2.1.185, eram 10 segundos e o texto era outro).

Waiting for API response · will retry in … · check your network

Se os dados voltarem, o aviso some sozinho. A mensagem deste artigo aparece quando ele não some, o encerramento acontece, e parte da saída já estava concluída.

2. Renomeada de “Response stalled mid-stream” na v2.1.227

Logo depois de explicar as quatro mensagens, a referência oficial de erros diz que, antes da v2.1.227, Connection lost mid-response aparecia como Connection closed mid-response e The response stopped arriving aparecia como Response stalled mid-stream. Na mesma versão, a mensagem de antes do início da saída também foi trocada.

Casos em que a mensagem antiga, Response stalled mid-stream, apareceu junto com o modelo repetindo a mesma palavra sem parar estão reunidos no artigo sobre Response stalled mid-stream e o loop infinito de “court”. Do lado da conexão que cai, os relatos da época da mensagem antiga estão no artigo sobre Connection closed mid-response, e a mensagem renomeada é explicada no artigo sobre Connection lost mid-response.

3. Diferenças em relação a mensagens parecidas

A mensagem exibida depende de até onde a resposta tinha avançado quando parou. Organizando a explicação oficial de “Automatic retries” na ordem em que a resposta avança, fica assim:

O motivo de não reenviar no caso ③ também está na documentação oficial: reenviar a requisição depois de concluir um bloco de texto ou uma chamada de ferramenta poderia executar a mesma chamada de ferramenta duas vezes. Por isso o Claude Code mantém o que foi concluído e, em vez de descartar o turno, acrescenta a nota.

A diferença para Connection lost mid-response: “queda ou silêncio”

As duas aparecem depois de parte da saída já ter saído, e têm em comum a saída que permanece e a retomada com continue. O que muda é a forma como a resposta parou. lost significa que a conexão foi perdida: suspeite de uma queda momentânea da sua rede, de uma reconexão da VPN ou de um equipamento no caminho cortando a conexão. stopped arriving significa que a conexão continua, mas nenhum conteúdo passa por ela, e o encerramento só acontece depois de esperar o tempo do temporizador de monitoramento. Por isso, o ajuste dos temporizadores da seção 6 só tem chance de ajudar no caso de stopped arriving.

A diferença para Streaming response ended…: “parou ou terminou vazia”

Segundo a documentação oficial, Streaming response ended before any complete data was received é um aviso de que a resposta terminou sem entregar nenhum dado utilizável. O Claude Code deixa de usar streaming, reenvia a mesma requisição e continua o turno. O aviso aparece só uma vez por sessão, em sessões interativas (antes da v2.1.239, o reenvio era silencioso). A documentação oficial aponta como causa comum um proxy ou gateway no caminho que consome ou transforma o corpo da resposta. Já stopped arriving é uma resposta que chegou até certo ponto e parou, e ela não é reenviada automaticamente.

4. O que acontece com o trabalho feito até ali

Pela explicação oficial, o Claude Code mantém todos os blocos concluídos e, no fim do turno, descarta o último bloco que estava pela metade. É por isso que as últimas frases na tela, ou a última chamada de ferramenta, podem estar faltando. As chamadas de ferramenta que tinham sido concluídas são executadas, e o turno continua a partir dos resultados delas. O que acontece depois da parada varia conforme o ambiente de execução.

A saída ao parar com -p e como continuar

Na saída de texto padrão do modo não interativo, o Claude Code imprime o último bloco de texto concluído naquele turno e, em seguida, esta mensagem (antes da v2.1.219, só a mensagem aparecia e a resposta era descartada). Mas, se não sobrar nenhum texto concluído, por exemplo quando a conversa foi compactada no meio do turno e esse texto sumiu, só a mensagem é impressa (acrescentado em 26 de setembro de 2026, após conferir a referência oficial de erros). Com --output-format json ou stream-json, a mensagem vai no campo result. O procedimento oficial é esperar a conexão estabilizar, retomar a sessão e enviar continue.

# Continuar a conversa mais recente
claude -p "continue" --continue

# Continuar indicando o ID da sessão
claude -p "continue" --resume "$session_id"

Sobre a retomada automática por hooks, o autor da Issue #87972 escreve que “na época da mensagem antiga, o hook Stop era executado e dava para continuar automaticamente, mas isso parou de funcionar mais ou menos quando a mensagem foi renomeada”. É uma observação do autor, e a documentação oficial não diz se o comportamento anterior era intencional. Pela documentação oficial atual, um hook pode registrar ou notificar, mas não consegue retomar o turno.

5. Causas: o que a documentação oficial diz e o que foi relatado

Essa mensagem só informa o resultado, “os dados pararam de chegar”; por que pararam não dá para saber pela mensagem. Separamos as informações por grau de certeza.

A documentação oficial coloca essa mensagem na seção “Server errors” da referência de erros. O início da seção diz que a maioria vem do lado do provedor de inferência, como os serviços da Anthropic, mas, sobre esta mensagem específica, a explicação oficial vai só até o mecanismo acima. A documentação oficial não identifica se a parada acontece na sua rede, em um equipamento no caminho ou no servidor.

#88900 e #90005 dizem que a resposta parou sem que houvesse problema aparente na rede local. Mesmo assim, isso não basta para concluir que a causa está no servidor. Como o próprio autor de #90005 escreve, testes de comunicação curtos não reproduzem a situação de “uma conexão que fica aberta por vários minutos e silencia no meio”.

6. O que fazer quando a resposta para

A ordem vai do que dá menos trabalho e mais resultado para o resto. Se aconteceu só uma vez, a etapa 2 resolve.

Exemplo em ~/.claude/settings.json (monitor em nível de bytes com 10 minutos):

{
  "env": {
    "CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS": "600000"
  }
}

7. Como confirmar que resolveu

Não dê como resolvido só porque a mensagem não apareceu uma vez. Rode um trabalho do mesmo tamanho e observe estes quatro pontos.

# Verificar a versão
claude --version

# Iniciar gravando o log de depuração
claude --debug

# Contar os arquivos de log de conversa que contêm a mensagem (macOS e Linux)
grep -rl "The response stopped arriving" ~/.claude/projects/ | wc -l

# Da mesma forma, contar as linhas que contêm a mensagem (PowerShell)
Get-ChildItem "$HOME\.claude\projects" -Recurse -Filter *.jsonl | Select-String -SimpleMatch "The response stopped arriving" | Measure-Object

Use a contagem como referência. O autor de #90005 conta que, em certo intervalo de 85 minutos, a tela parou 15 vezes, mas só 1 registro ficou no log de conversas. Mesmo que o log de conversas mostre 0, é mais seguro anotar você mesmo quantas vezes a tela parou.

8. Informações para guardar ao relatar

A referência oficial de erros indica quatro canais para quando o problema não se resolve:

• Execute /feedback dentro do Claude Code. A transcrição da conversa e a sua descrição são enviadas à Anthropic, e também é possível abrir uma issue no GitHub já preenchida. Em provedores como Bedrock e Vertex, em vez de enviar, o conteúdo é salvo localmente
• Execute claude doctor no shell e veja o diagnóstico da instalação, somente leitura
• Consulte instabilidades em status.claude.com
• Procure nas issues existentes no GitHub, pesquisando pela mensagem nova e pela antiga

9. O que está confirmado e o que não está

10. Resumo

“API Error: The response stopped arriving” indica que, depois de parte da resposta ter chegado, os dados pararam com a conexão ainda aberta e o temporizador de monitoramento do Claude Code a encerrou. É a mesma coisa que Response stalled mid-stream, de antes da v2.1.227, e a saída concluída permanece. Primeiro confira o estado do trabalho e depois responda continue.

Se a mensagem se repetir, tente nesta ordem: atualizar a versão, isolar VPN, proxy e gateway, e encurtar cada resposta. Só em ambientes em que o caminho fica em silêncio por muito tempo vale aumentar o tempo do monitor em nível de bytes. O lugar onde procurar a causa é diferente do de Connection lost mid-response, em que a própria conexão cai, então compare primeiro o texto das mensagens. Outros erros estão reunidos em Erros comuns do Claude Code e como resolvê-los.

FAQ

P. O que significa “API Error: The response stopped arriving”?
R. Significa que, no meio da resposta, os dados pararam de chegar embora a conexão continuasse aberta, e o temporizador de monitoramento do Claude Code encerrou essa conexão. É a mensagem para quando a parada acontece depois de concluir um bloco de texto ou uma chamada de ferramenta, e a saída até ali permanece.

P. É um erro diferente de “Response stalled mid-stream”?
R. É o mesmo. A referência oficial de erros deixa claro que, antes da v2.1.227, esta mensagem aparecia como Response stalled mid-stream. Só o texto mudou; não surgiu um novo tipo de falha.

P. O que respondo para continuar de onde parou?
R. Responda continue. O trabalho segue a partir do último bloco concluído. Se a parada foi no meio de uma operação com arquivos ou de um comando, é mais seguro conferir antes o estado real com git status ou algo parecido.

P. Aumentar o número de novas tentativas faz a mensagem sumir?
R. Não. Nesta situação, o Claude Code foi projetado para nunca reenviar, para não executar a mesma chamada de ferramenta duas vezes. CLAUDE_CODE_MAX_RETRIES vale para falhas que acontecem antes de a saída começar.

P. Qual é a diferença para “Connection lost mid-response”?
R. lost significa que a própria conexão caiu; stopped arriving significa que a conexão continuou, mas os dados pararam de chegar. Nos dois casos a saída concluída permanece e dá para retomar com continue, mas o ajuste do tempo do monitor só tem chance de ajudar no caso de stopped arriving.

Fontes primárias consultadas

• Claude Code — Error reference (documentação oficial): as quatro mensagens de The response above may be incomplete e a mudança de nome na v2.1.227, os falsos alarmes antes da v2.1.222, Automatic retries, o aviso de espera, No response from API, Streaming response ended before any complete data was received, Report an error
• Claude Code — Enterprise network configuration (documentação oficial): os quatro temporizadores de monitoramento e seus tempos padrão, as variáveis de ambiente de configuração, o log de depuração e como passar configurações aos agentes em segundo plano
• Claude Code — Environment variables (documentação oficial): explicação de CLAUDE_STREAM_IDLE_TIMEOUT_MS, CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS e API_FORCE_IDLE_TIMEOUT
• Claude Code — Hooks reference (documentação oficial): StopFailure em turnos que terminam com erro da API
• Claude Code — Run Claude Code programmatically (documentação oficial): retomada com --continue e --resume
• anthropics/claude-code — CHANGELOG (oficial): entradas da v2.1.222, v2.1.227, v2.1.229, v2.1.232, v2.1.246 e v2.1.257
• Issues no GitHub: #88900, #90005, #89027, #87246, #87972 (todas relatos de usuários; verificadas em 22 de setembro de 2026)