Ao trabalhar por muito tempo no Claude Code, de repente a resposta começa a repetir a mesma palavra dezenas ou centenas de vezes, "court court court court…", e no final surge "API Error: Response stalled mid-stream. The response above may be incomplete." e tudo trava — você já se deparou com esse fenômeno?

Isso não é um erro do seu prompt nem do seu ambiente; na maioria das vezes ocorre porque dois defeitos distintos se encadeiam. ① O loop de repetição (degeneração), em que o modelo continua cuspindo o mesmo token, e ② o "Response stalled mid-stream", em que o stream para por causa desse volume enorme de saída ou de problemas de conexão. Ambos são defeitos conhecidos, com várias Issues abertas no repositório oficial da Anthropic. Neste artigo, organizamos a verdade sobre essas duas camadas, as condições que as provocam, como interromper na hora, como preveni-las para desenvolvedores e como distingui-las de erros parecidos, tudo com base na documentação oficial e nas Issues reais.

Dois fenômenos distintos se encadeiam
① Lado do modelo
Loop infinito de "court"

Repetição (degeneração) que repete o mesmo token sem parar. Consome todos os tokens de saída.

② Lado do stream
Response stalled mid-stream

O stream de resposta deixa de enviar dados e para. Fica no estado "interrompido no meio".

※ Às vezes só um deles ocorre. O caso típico é o descontrole do court gerar um volume enorme de saída e provocar a parada do stream.

1. O que está acontecendo — dois fenômenos distintos se encadeiam

Primeiro, é importante separar as coisas. Na tela você vê "a repetição de court" e "Response stalled mid-stream", mas são dois problemas de camadas diferentes.

  • ① Loop infinito de "court": fenômeno de repetição em que o Claude (o próprio modelo), em vez da resposta pretendida ou da chamada de ferramenta, continua gerando o mesmo token repetidamente. Correspondem a isso a Issue do GitHub #68740 (Output enters an infinite loop repeating the token "court") e a #65823 (repete uma string fixa milhares de vezes e esgota os tokens de saída), entre outras.
  • ② "Response stalled mid-stream": erro do lado da transmissão em que o stream (envio incremental) da resposta para no meio. Está descrito também na referência oficial de erros do Claude Code e foi relatado na Issue #70840.

Quando ① descontrola, gera um volume enorme de saída, que por sua vez provoca a parada do stream de ② — esse encadeamento aparece como um único fenômeno na tela do usuário. Mas a causa e o tratamento são diferentes, então entendê-los separadamente é o caminho mais rápido.

2. A verdade sobre o loop infinito de "court" — repetição (degeneração)

"court" não tem significado nenhum. Trata-se de uma variante de um modo de falha conhecido há muito tempo, a "repetição (repetition/degeneração)", em que o modelo de linguagem fica preso à mesma saída, e por acaso o ponto de fixação calhou de ser o token "court". Também pode ser outra palavra ou sequência de símbolos.

Características relatadas (#68740 e outras):

  • Ocorre com modelos como claude-opus-4-8, na extensão do VS Code / CLI do Claude Code.
  • Começa no meio da sessão e reincide várias vezes dentro da mesma sessão (depende do estado).
  • Há relatos de que é provocado com mais facilidade quando o modelo gera texto em japonês ou outro idioma logo antes de uma chamada de ferramenta (Edit etc.).
  • Quando descontrola, consome uma grande quantidade de tokens de saída (#65823) e há casos em que a sessão trava (#66950).

A label atribuída é area:model (comportamento do modelo), classificando-o como um problema de geração do lado do modelo, e não do harness (Claude Code). Ou seja, corrigir comandos ou configurações não erradica o problema, e a abordagem básica passa a ser "quando acontecer, interromper e fugir".

3. A verdade sobre "Response stalled mid-stream" — parada do stream

O outro caso, "API Error: Response stalled mid-stream. The response above may be incomplete.", é um erro do lado da transmissão que aparece quando o stream de resposta deixa de enviar dados no meio. Assim como diz o aviso "a resposta acima pode estar incompleta", o que já foi transmitido até ali não se perde — só faltam as últimas frases ou a chamada de ferramenta.

Fatores relatados e apontados como principais:

  • Respostas longas: ocorre com mais facilidade quando a geração se prolonga, como ler vários arquivos grandes e produzir um relatório estruturado. O volume enorme de saída causado pelo descontrole do court também se enquadra aqui.
  • Instabilidade de rede/conexão: conexões internacionais, redes domésticas, uso através de sessões tmux etc. aumentam a probabilidade.
  • Falta de timeout de leitura: há a observação de que, quando a API upstream para de enviar pacotes e o cliente fica esperando indefinidamente, ocorre a falha (Issue #70840).

Vale notar que o muito parecido "Connection closed mid-response (a conexão foi fechada no meio da resposta)" (#69415) é um erro diferente, em que o stream não "para", mas é "cortado". Os sintomas são próximos, mas esse pende mais para a desconexão.

4. É diferente do "vazamento de tag court/invoke" — como distinguir

É fácil confundir, mas o fenômeno deste artigo, "court entra em loop infinito", e o fenômeno de "court vazar na tela junto com a tag invoke" são coisas diferentes. O segundo é detalhado em outro artigo deste site.

AspectoEste artigo: loop infinito de court → stallOutro artigo: vazamento de tag court/invoke
Sintoma visívelRepete "court" dezenas a centenas de vezes / termina com stalled"court" ou a tag <invoke> crua vazam algumas poucas vezes
NaturezaRepetição (degeneração) + parada do streamCorrupção na geração das tags de controle da chamada de ferramenta
Chamada de ferramentaFica presa na geração e não avançaA tag quebra e a chamada não dispara
EncerramentoResponse stalled mid-stream / travaA tag é exibida como texto e para

O tipo em que "court" vaza junto com a tag e a chamada de ferramenta não dispara está descrito em Causas e soluções do erro em que o Claude Code emite "court" ou tags invoke. A causa e a solução são em parte diferentes.

5. Condições que provocam o erro

Nenhum dos fenômenos tem uma condição de reprodução que "sempre ocorra", mas os relatos revelam fatores em comum que aumentam a probabilidade.

🕒 Longa duração e contexto grande

Sessões contínuas de horas a vários dias, contextos pesados de centenas de milhares a cerca de 1 milhão de tokens. Quanto mais estado se acumula, mais provável.

🔧 Geração de texto logo antes da chamada de ferramenta

Há relatos de que entrar em loop é mais fácil quando o modelo escreve um texto introdutório em japonês ou outro idioma logo antes de um Edit etc.

📡 Conexão instável

Conexões internacionais, redes domésticas, uso através de tmux etc. aumentam a probabilidade de parada do stream.

📄 Saída longa

Tarefas em que a geração se prolonga, como ler vários arquivos grandes e produzir um relatório extenso.

6. Resolva agora mesmo (para usuários)

Como a repetição do lado do modelo não pode ser erradicada por configuração, o mais confiável é "interromper rápido e reiniciar o estado". A ordem de prioridade é a seguinte.

  1. Interrompa na hora (Esc): ao perceber o loop ou a travada, interrompa a geração com Esc. Assim você para o desperdício de tokens de saída.
  2. Fuja para uma nova sessão: como é um defeito que depende do estado, iniciar uma nova sessão costuma resolver. Tentar de novo na mesma sessão tende a fazer reincidir.
  3. Reinicie o contexto com /clear: se quiser continuar a sessão, limpe o contexto para aliviar o estado (/compact preserva o estado, então a resolução é incerta).
  4. Chame a ferramenta sem texto introdutório: há relatos de que instruir a chamar a ferramenta com zero introdução, sem escrever um texto longo logo antes de um Edit etc., ajuda a evitar o loop.
  5. Divida a tarefa em sessões curtas: fazer 1 tarefa = 1 sessão, mantendo o tempo de geração e o contexto curtos, reduz tanto a repetição quanto a parada do stream.
  6. Estabilize a conexão: se o stalled for frequente, revise a estabilidade da linha ou da rota do proxy. O conteúdo já transmitido permanece, então basta instruir de novo a partir da continuação.

✅ Ponto-chave: "errou duas vezes, não insista, vá para uma nova sessão". Se você tentar de novo com o mesmo estado corrompido, o modelo imita a repetição anterior e tende a reincidir.

7. Para desenvolvedores — prevenir via API/SDK

Se você implementa por conta própria com a Messages API ou o SDK, as medidas a seguir reduzem os danos.

  • Defina um timeout de leitura no streaming: se não chegarem pacotes por um certo tempo, encerre e tente de novo. Evita a espera infinita (medida contra a raiz do stalled).
  • Guarda de detecção de repetição: se, na saída recente, o mesmo token / string curta se repetir um número anormal de vezes, encerre a geração. Evita o consumo descontrolado de tokens de saída.
  • Retry de respostas incompletas: verifique o stop_reason e, se terminou no meio, refaça sem deixar a saída corrompida no histórico (o histórico corrompido provoca a repetição no próximo turno).
  • Defina um limite de max_tokens: para que, mesmo que descontrole, haja um teto de custo e de tempo.
  • Mantenha curtos os argumentos da ferramenta e a introdução: argumentos longos e introduções extensas podem ser condições que provocam o problema.

8. Como distinguir de erros parecidos

Sintoma/mensagemNaturezaPrincipal tratamento
Repete court dezenas de vezes → stalledLoop de repetição + parada do stream (este artigo)Parar com Esc → nova sessão //clear
court ou a tag invoke crua vazam algumas vezesCorrupção na geração da tag da chamada de ferramenta (outro artigo)Errou duas vezes, nova sessão
Connection closed mid-responseO stream é "cortado" (#69415)Revisar conexão, retry
Prompt is too longA entrada excedeu o limite de contextoReduzir contexto, /clear
usage limit / 429Limite de uso ou de taxaEsperar um tempo, verificar o plano
Output blocked by content filtering policyFiltro de segurança do lado da saída (outro artigo)Reformular evitando cópia literal

9. Situação oficial

Organizamos a situação de julho de 2026, deixando explícito o grau de certeza.

  • Reconhecido como defeito conhecido: tanto a repetição do court quanto o stalled têm várias Issues abertas no repositório oficial da Anthropic, e a repetição do court recebeu as labels area:model e bug.
  • 🟡 Correção definitiva não confirmada: até a redação deste texto, não foi possível confirmar uma correção oficial da qual se possa afirmar "isto resolveu". Como pode melhorar com atualizações de versão, convém manter o Claude Code na versão mais recente.
  • 🟡 A causa depende do estado e do ambiente: vários fatores se combinam — longa duração, contexto grande, qualidade da conexão etc. — e não foi identificado um único procedimento de reprodução.

※ A situação pode mudar. Para o mais recente, consulte a lista de Issues do Claude Code e a referência oficial de erros.

FAQ

Q1. "court" tem algum significado?

Não tem. É a "repetição (degeneração)" em que o modelo de linguagem fica preso à mesma saída, e por acaso o ponto de fixação calhou de ser o token "court". Também pode ser outra palavra ou sequência de símbolos. Não é um problema do seu prompt ou dos seus dados.

Q2. Quando aparece "Response stalled mid-stream", a saída parcial some?

Não some. Como diz a mensagem, "a resposta acima pode estar incompleta" — apenas isso, e o conteúdo transmitido até ali permanece. Como podem faltar as últimas frases ou a chamada de ferramenta, basta instruir de novo a partir da continuação.

Q3. Tentar de novo resolve na hora?

Nos casos leves às vezes resolve, mas tentar de novo na mesma sessão tende a fazer reincidir. Isso porque o modelo acaba imitando a saída corrompida (a repetição) anterior. Errou duas vezes, o certo é não insistir e mudar para uma nova sessão.

Q4. Fazer /compact resolve?

É incerto. O /compact resume o contexto e preserva o estado, então a causa da repetição pode permanecer. Se quiser reiniciar o estado, o /clear ou uma nova sessão são mais confiáveis.

Q5. Este é o mesmo defeito do "vazamento de tag court/invoke" do artigo?

Estão relacionados, mas são coisas diferentes. Este artigo é do tipo repetição + parada do stream, "court entra em loop infinito e no final para com stalled". O tipo de vazamento de tag é "court ou a tag invoke crua vazam algumas vezes e a chamada de ferramenta não dispara"; para detalhes, consulte o outro artigo.

Q6. Como prevenir de forma definitiva, como desenvolvedor?

São três pontos eficazes: definir um timeout de leitura no streaming, encerrar repetições anormais com detecção de repetição e, quando terminar no meio, refazer o retry sem deixar a saída corrompida no histórico. Um limite de max_tokens também evita o descontrole de custo e tempo.

Q7. Em que situações é mais provável ocorrer?

A probabilidade aumenta em sessões contínuas de horas ou vários dias, contextos pesados de centenas de milhares a cerca de 1 milhão de tokens, geração de texto longo logo antes de uma chamada de ferramenta, conexões instáveis internacionais/domésticas/através de tmux e tarefas de saída extensa. Manter tudo curto com 1 tarefa = 1 sessão é uma prevenção.

Artigos relacionados