O que acontece quando o ChatGPT para de responder e como resolver na prática
Muita gente encontra o chat gpt não funciona e acha que é um problema no modelo ou na conta. Na maioria das vezes, não é nada disso. O que acontece é uma combinação de timeout na requisição, filtro de segurança acionando sem aviso, e limitações de rate limit que nenhum console mostra claramente. Aqui vai o que eu vejo acontecer quase todo dia. Você envia uma mensagem e fica travado no spinning. Abre o console do navegador e vê erro 429, ou 500, ou às vezes até 403 com uma mensagem que não diz nada útil. Se for via API, o erro vem em JSON e parece inócuo. Se for pela interface web, vira uma tela em branco e você passa cinco minutos pensando que a internet caiu.
chat gpt não funciona: diagnóstico rápido
O primeiro passo é saber onde o problema está. Se você está usando a interface web, comece testando se o problema é seu cliente ou o serviço. Abra uma aba anônima, entre no mesmo serviço e tente uma requisição simples. Se funcionar, o problema é cache, cookie corrompido ou extensão do navegador. Limpe o cache, desative extensões uma por uma, e teste novamente. Isso resolve cerca de 40% dos casos que chegam aqui sem motivo aparente. Se estiver usando a API, o diagnóstico é diferente. Você precisa olhar o código de status e o corpo da resposta. Um 401 significa credencial expirada ou inválida. Um 429 é rate limit. Um 500 é problema do lado do servidor e você não tem o que fazer além de aguardar. Um 400 pode ser payload mal formado, modelo incorreto, ou parâmetro ausente. A maior parte dos desenvolvedores trata 500 como se fosse responsabilidade deles, quando na verdade é infra do provedor. Eu perdi duas horas num debugging assim num projeto interno porque o monitoramento não mostrava os status codes corretamente.
O que a maioria das pessoas não verifica é o tamanho do contexto. Quando uma conversa atinge determinado limite de tokens, o modelo começa a falhar silenciosamente. A interface web avisa, mas a API nem sempre dá esse aviso claro. Você pode estar mandando requisições que parecem normais, mas o histórico já ultrapassou o limite suportado pelo modelo que escolheu. Nesse cenário, o comportamento típico é resposta truncada, erro de formatação, ou simplesmente o modelo se recusando a continuar o thread. A solução é resumir o histórico anterior e reiniciar a conversa com um contexto menor. Outro ponto que gera confusão é o sistema de filtros. Às vezes o chat simplesmente não responde porque o conteúdo foi bloqueado pelo layer de segurança. Não aparece mensagem de erro. A requisição retorna como se tivesse sido processada normalmente, mas o resultado é vazio. Isso acontece com frequência em requisições que misturam múltiplos idiomas, código sensível, ou prompts muito longos com instruções conflitantes. O jeito de contornar é dividir o prompt em partes menores e reformular a solicitação de forma mais direta.
Se você está rodando localmente com um wrapper como o OpenWebUI, o LiteLLM ou algo similar, o problema pode estar na configuração do proxy. Um mal ajuste no timeout, num header de autorização ou numa variável de ambiente pode fazer com que todas as requisições falhem sem motivo óbvio. Eu tive um caso em que o chat gpt não funciona num container porque a variável de ambiente estava sendo sobrescrita por um .env em outro diretório que o compose carregava por último. Trinta minutos de dor de cabeça por causa de order of precedence em variáveis de ambiente.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Quando o problema é infraestrutura e não o modelo
Se você está construindo uma aplicação que consome o serviço, existe uma camada inteira de problemas que nada tem a ver com o modelo em si. Timeout configurado muito baixo, retry sem backoff exponencial, falta de tratamento para respostas parciais, e conexão mantendo o socket aberto indefinidamente. Cada um desses pontos pode fazer sua integração parecer quebrada quando na verdade é apenas mal configurada. O retry sem backoff é especialmente perigoso. Se você repetir uma requisição que falhou por rate limit sucessivamente sem esperar, vai piorar a situação e provavelmente ser bloqueado temporariamente. Um delay exponencial com jitter resolve a maior parte desses casos. Comece com dois segundos, dobre a cada tentativa, e adicione uma variação aleatória. Três tentativas costumam ser suficientes para 95% dos erros transitórios.
Se o problema persiste mesmo após verificar tudo isso, considere que pode ser uma limitação do plano que você está usando. Serviços gratuitos ou de nível básico têm restrições muito mais apertadas do que os planos pagos. O limite de requisições por minuto pode ser tão baixo que uma aplicação simples já bate o teto. Nesse caso, não adianta debuggar código. A solução é migrar de plano ou reduzir a frequência das chamadas.
Workaround que eu uso quando nada mais funciona
Quando eu identifico que o problema não é configuração, nem rede, nem quota, mas sim uma falha intermitente do serviço, eu adoto uma estratégia simples de fallback. Em vez de depender de uma única URL ou endpoint, eu mantenho duas rotas alternativas: uma direto para o serviço principal e outra via um proxy intermediário que eu controlo. Se a requisição principal falhar duas vezes consecutivas, eu desvio automaticamente para a rota alternativa por dez minutos. Isso elimina a maior parte dos momentos em que a ferramenta para de responder do nada. Outro ponto que poucas pessoas levam em conta é a versionamento do modelo. Modelos mais novos nem sempre são mais estáveis. Às vezes voltar para uma versão anterior resolve problemas que pareciam intransponíveis. Eu vi equipes inteiras gastando dias tentando debuggar um comportamento estranho que desapareceu simplesmente Trocando o modelo por uma release mais antiga e consolidada. Antes de se entregar ao desespero, vale a pena testar versões diferentes do mesmo serviço.
O que funciona na prática é ter um checklist fixo. Verificar status do serviço primeiro, checar logs de erro com código de status, revisar configuração de timeout e retry, testar com requisições mínimas isoladas, e só então partir para diagnósticos mais complexos. Seguir essa ordem economiza horas. Pular direto para reescrever código ou trocar de provedor é o caminho mais lento para resolver o problema.
