“Erro no fluxo de mensagens” no ChatGPT — causas e como resolver

Os três gestos dos primeiros 90 segundos

Regerar a resposta → recarregar a página (no celular, fechar o aplicativo por completo e abrir de novo) → sair da conta e entrar de novo. Uma queda pontual é resolvida por um desses três, e pontual é o caso normal. Se, em vez disso, parar exatamente no mesmo ponto toda vez, isso é sinal de que uma das causas específicas abaixo está agindo, e não um acaso.

Decidir primeiro se o problema é seu

Esta é a etapa que as outras listas de solução pulam, e a que mais economiza tempo. Abra status.openai.com. Se houver um incidente em andamento, nenhum ajuste local muda nada e esperar é a única saída. Se não houver nada listado, a causa é local e a etapa seguinte a delimita. Fazer essa checagem antes de mexer em configurações evita passar vinte minutos limpando cache durante uma queda.

Isolar a causa local de fora para dentro

Siga nesta ordem, porque cada camada descarta tudo o que está acima: (1) desligar VPN e proxy; (2) abrir uma janela anônima — isso remove extensões e cache de uma vez só; (3) testar outro navegador ou outro aparelho; (4) trocar de rede. A camada a partir da qual volta a funcionar é a causa. Se o erro só aparece em conversas longas, nenhuma das quatro é a culpada: leve o essencial para um chat novo.

Para desenvolvedores: a mesma queda na API

Chamando a API com stream: true, essa mesma falha chega como uma conexão Server-Sent Events que termina sem finish_reason. O status HTTP é 200 — estava tudo bem quando os cabeçalhos foram enviados —, então checar só o código de status não pega; sob carga aparecem ainda 429 e 529 overloaded_error. Três coisas tornam isso sobrevivível: (1) tratar um stream que terminou sem finish_reason como passível de nova tentativa, não como resposta completa; (2) repetir 429, 500 e 529 com backoff exponencial mais jitter; (3) se houver proxy no caminho, verificar o idle timeout dele e desligar o buffering de respostas — um proxy que bufferiza transforma um stream que funciona num travamento longo. Para delimitar, transmita primeiro sem proxy:

# Transmitir direto, sem proxy no caminho, e ver onde para.
curl -N https://api.kunavo.com/v1/chat/completions \
  -H "Authorization: Bearer $KUNAVO_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-4-6","stream":true,
       "max_tokens":300,
       "messages":[{"role":"user","content":"conte devagar de 1 a 20"}]}'

“Erro no fluxo de mensagens” é culpa minha?

Quase nunca. A mensagem diz que a conexão que levava a resposta foi cortada antes de ela terminar. O que você escreveu não provoca isso. As causas são carga do lado da OpenAI, uma rede instável, uma extensão do navegador ou sessão expirada, ou uma conversa que ficou longa a ponto de as respostas estourarem o tempo.

E se regerar não resolver?

Confira primeiro status.openai.com — durante um incidente, nada local ajuda. Se não houver incidente, abra uma janela anônima em outra rede: esse único teste remove extensões, cache e o seu link de sempre de uma vez. Se funcionar ali, recoloque cada peça até quebrar de novo. Se falhar em tudo e só numa conversa longa, leve o essencial para um chat novo.

Acontece com outras IAs também?

A redação é do ChatGPT, mas qualquer assistente que entregue respostas em streaming pode cair do mesmo jeito. O Claude mostra uma mensagem dizendo que não conseguiu gerar a resposta completa; numa chamada direta à API isso aparece como um fluxo SSE que termina sem finish_reason, ou sob carga como um 529 overloaded_error.

Por que acontece mais em conversas longas?

Cada turno reenvia o fio inteiro, então uma conversa longa significa uma geração mais longa sustentada por uma única conexão aberta. Quanto mais tempo essa conexão fica aberta, mais chances um timeout de proxy, uma troca de rede ou um soluço lá em cima têm de rompê-la. Começar um chat novo com um resumo do que importa costuma render mais do que qualquer ajuste de navegador.