Guia do Claude AI: Dicas e Tutoriais Práticos

O jeito de pensar do Claude passou por uma troca de geração. O antigo pensamento estendido (extended thinking) exigia que você especificasse um orçamento de tokens em cada requisição — thinking: {"type": "enabled", "budget_tokens": N} —, mas o orçamento certo muda de tarefa para tarefa, não dá para adivinhá-lo de antemão, e alterá-lo invalida o cache de prompt. O pensamento adaptativo atual é uma única linha, type: "adaptive": pensar ou não, e com que profundidade, é decisão do próprio modelo com base em quão difícil a requisição parece. A migração foi escalonada: budget_tokens foi descontinuado no Opus 4.6 / Sonnet 4.6 e é rejeitado com erro 400 do Opus 4.7 em diante. Este artigo condensa as regras por modelo em uma tabela — o Fable 5 pensa sempre (não dá para desligar), Opus 5 e Sonnet 5 vêm com o pensamento ligado por padrão (no Opus 5, desligar só é permitido com effort high ou abaixo), Opus 4.8 / 4.7 exigem adaptive explícito, e modelos legados como Sonnet 4.5 / Haiku 4.5 ainda usam budget_tokens como único modo. O controle de profundidade passou para output_config: {"effort": ...}, com cinco níveis (padrão high), e mudar o effort estoura o cache do mesmo jeito que mudar o orçamento estourava. A visibilidade é governada por display: o padrão da nova geração é "omitted" (blocos de pensamento vazios), e você paga pelos tokens de pensamento inteiros de qualquer forma — meça com usage.output_tokens_details.thinking_tokens; nenhuma configuração devolve a cadeia de raciocínio bruta. Desligar o pensamento no Opus 5 tem efeitos colaterais documentados (chamadas de ferramenta escritas como texto comum, tags internas vazando na saída), então abaixar o effort é a alavanca de custo mais segura. O pensamento intercalado — raciocinar entre as chamadas de ferramenta — é automático no adaptativo, sem o velho header beta. E, quando a velocidade importa, o fast mode roda o mesmo Opus a cerca de 2,5x pelo dobro do preço (só Opus 5/4.8, alternado com /fast no Claude Code). Tudo se apoia na documentação oficial da Anthropic: Thinking, Extended thinking e Fast mode.

Você está no meio do trabalho e, de repente, o Claude Desktop congela e todas as sessões abertas do Claude Code param de uma vez; ao forçar o encerramento e tentar reabrir, às vezes o aplicativo não inicia mais — e, nessa hora, a última linha do log costuma ser a mesma: GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }. Este artigo organiza o que esse exitCode 101457950 (ou seja, 0x060C201E) significa. Quem cai não é o Claude Code (a CLI), e sim o processo de GPU do aplicativo desktop (Electron) que hospeda a CLI. O diagnóstico é simples: basta olhar o fim de %APPDATA%\Claude\logs\main.log, e se a linha imediatamente anterior ao reinício for GPU process gone, é este problema; se nenhum dump novo apareceu em Crashpad, não foi uma falha nativa do lado da CLI. A pergunta de por que sessões sem relação nenhuma caem junto tem resposta arquitetural: no Electron/Chromium existe um único processo de GPU por aplicativo, compartilhado por todas as janelas, abas e sessões, de modo que uma única página aberta no navegador interno pode derrubar tudo o que estava em andamento — e, por ser uma propriedade estrutural, nenhuma configuração do usuário permite isolá-los. Nas issues públicas o gatilho mais frequente é o navegador interno: a #80444 registra o processo morrendo de 15 a 36 segundos depois da detecção de recursos de WebGL/WebGPU, sempre com o mesmo 0x060C201E, e a #82967 aponta a captura de screenshot de pré-visualização (capturePreviewScreenshotIfChanged) como gatilho. Mas o navegador não é o único: a #68049 relata a mesma falha acontecendo na inicialização em um ambiente ARM64. A recuperação básica é forçar o encerramento e reabrir, mas depois de uma falha de GPU o Windows pode julgar que o pacote MSIX foi modificado (appxState=2) e recusar a inicialização; nesse caso, encerre os processos residentes e só então use o Reparar. Há também relato de que o Reparar falhava sempre e de que só a remoção completa seguida de reinstalação resolveu (#82967). Quanto aos dados, o que já foi salvo permanece, mas o trabalho em execução não volta — há relato de perda até dos resultados de subagentes que rodavam em paralelo (#81698). O que dá para fazer é apenas tornar o gatilho menos provável: --disable-gpu é recusado com acesso negado na versão MSIX, e atualizar o aplicativo não corrige necessariamente. A Anthropic não publicou nenhuma explicação oficial de causa nem anúncio de correção para esse sintoma.

O Dispatch é o recurso em que você manda uma instrução pelo celular e o Claude executa o trabalho no seu próprio computador (beta, planos Pro e Max). Ele não roda na nuvem; é a sua máquina real que se mexe, e esse fato único produz tanto o valor quanto o perigo. A ajuda oficial diz que você pode mandar uma mensagem ao Claude pelo celular e fazer com que ele trabalhe no seu computador de mesa, usando os mesmos conectores, plugins e acesso a arquivos que você já configurou no Cowork, dentro do que a Anthropic enquadra como uma conversa contínua acessível a partir de qualquer um dos aparelhos. Para funcionar, ele exige o PC acordado e com o aplicativo de desktop aberto, e o uso do computador tem suporte apenas em macOS e Windows, sem uso do computador no Linux. Mecanicamente ele desce por três níveis de prioridade: um conector, se houver um disponível; navegação no navegador, se não houver; e interação direta com a tela como último recurso, com capturas de tela tiradas pelo caminho para entender o que está exibido. A avaliação começa depois disso. Os lugares em que ele para são projetados: o uso do computador vem desligado por padrão e é habilitado em Settings, General; a permissão é pedida para cada novo aplicativo; excluir um arquivo em definitivo exige permissão explícita; e plataformas de investimento e negociação e aplicativos de criptomoedas estão fora de alcance por padrão. Mas há lugares em que ele não para. Ações individuais dentro de um aplicativo já aprovado não são confirmadas com você, e o texto oficial diz que o Claude clica, digita e navega na sua tela diretamente, sem as verificações de permissão que controlam as outras ferramentas do Cowork. A documentação acrescenta que não há sandbox entre o Claude e o que está na sua tela, e que ações tomadas em um aplicativo podem impactar outros aplicativos. O maior risco é a injeção de prompt, que a Anthropic descreve com as próprias palavras: o conteúdo da web é um vetor primário de ataques de injeção de prompt, e uma instrução manipulada, um comando inesperado ou um link de phishing aberto no seu navegador podem desencadear ações difíceis ou impossíveis de desfazer. A Anthropic diz que examina as ativações do modelo para detectar esse tipo de comportamento, mas isso reduz as chances em vez de eliminar a necessidade de você traçar uma linha, e a orientação continua mandando mudar para aprovação manual sempre que uma tarefa tocar arquivos, contas ou sites sensíveis. A Anthropic nomeia o limite sem meias-palavras: não dê à permissão de uso do computador acesso a aplicativos sensíveis, como os de bancos, saúde e governo, e evite contas financeiras, documentos jurídicos, informações médicas e dados pessoais. O artigo também cobre o lado do celular. O que vaza se você perder o aparelho não são os dados guardados nele, e sim a prerrogativa de instruir o seu PC, mais o conteúdo da conversa contínua — e a ajuda oficial do Dispatch não documenta desemparelhamento nem o que fazer com um aparelho perdido, então os remédios vêm do lado da conta: encerrar a sessão individual em Settings, Account, Active sessions; desconectar todas as sessões pelo claude.ai (o que não está disponível nos aplicativos móveis e portanto exige um navegador web); ou simplesmente cortar o lado do PC fechando o aplicativo de desktop ou deixando a máquina suspender, o que é de fato o mais rápido, já que o Dispatch precisa do PC acordado e do aplicativo aberto. Ele encerra separando o Dispatch do uso do computador como dois interruptores distintos, distinguindo ambos do agent view do Claude Code (que a documentação oficial também chama de dispatch) e traçando uma linha prática: comece por trabalho que dá para desfazer.

O agent view do Claude Code, aberto com claude agents, é o recurso para iniciar sessões independentes em segundo plano uma atrás da outra e gerenciá-las a partir de uma única tela. A documentação oficial chama de dispatch a operação que você executa ali, o que colide com o recurso homônimo e separado do aplicativo de desktop, então a primeira tarefa é distinguir os dois. A documentação descreve o agent view como o recurso que permite despachar e gerenciar muitas sessões do Claude Code a partir de uma só tela, e ele é um research preview que exige a v2.1.139 ou posterior. Este artigo fica no mecanismo e no modelo de segurança. A primeira surpresa é que cada prompt digitado na caixa de entrada inicia uma nova sessão própria: digite um segundo e você ganha uma segunda sessão ao lado da primeira, não uma instrução extra somada a ela. Instruções adicionais passam pelo painel de espiada, aberto com Space, que mostra a saída mais recente ou a pergunta pela qual a sessão está esperando em vez da transcrição inteira. O coração do modelo de segurança é o isolamento por worktree. Antes de editar qualquer arquivo, uma sessão em segundo plano se muda para um git worktree isolado dentro de .claude/worktrees/, de modo que sessões paralelas leem o mesmo checkout mas cada uma escreve no seu — leituras compartilhadas, escritas separadas. Tudo o que alcançaria o checkout principal é cortado por três verificações: edições de arquivo via Edit, Write e NotebookEdit; diretórios de trabalho de comandos que resolvem para o checkout principal ou que não dá para verificar que ficam fora dele; e tentativas de redirecionar o git via git -C, --git-dir, GIT_DIR, GIT_WORK_TREE ou um cd colocado antes da chamada do git. A decisão é deliberadamente tomada pelo lado seguro, recusando o que não pode ser verificado, e a mesma proteção é herdada por todo subagente que a sessão gerar. Não é um muro no nível do sistema operacional, porém: arquivos fora do repositório e a rede estão fora do escopo, e comandos do PowerShell recebem apenas a verificação do diretório de trabalho. As permissões também não são escolhidas na hora do dispatch; elas são herdadas do defaultMode daquele diretório, ou do permissionMode no frontmatter de um subagente despachado, o que significa que quanto mais frouxa for a sua configuração habitual, mais sessões sem supervisão e com permissões frouxas você cria de uma vez. Três coisas então vazam do isolamento. Escolher "Sim, não pergunte de novo" salva a regra no .claude/settings.local.json do checkout principal, então ela vale no checkout principal e em todos os outros worktrees e sobrevive à remoção do worktree em que foi criada. Excluir uma sessão no agent view exclui junto o worktree criado pelo Claude, de modo que trabalho não commitado desaparece — e o Ctrl+X para no primeiro toque e exclui no segundo. E o .worktreeinclude copia arquivos ignorados pelo git, como o .env, para todo worktree novo, multiplicando as suas credenciais pelo número de sessões que você despacha. Além disso, a cota se esgota em proporção ao paralelismo (dez agentes a consomem cerca de dez vezes mais rápido), e as sessões rodam localmente, sobrevivendo à suspensão mas parando quando a máquina é desligada. O artigo encerra situando o agent view entre as quatro formas oficiais de paralelizar, ao lado dos subagentes, dos agent teams e dos fluxos de trabalho dinâmicos, e dá uma rotina concreta para antes, durante e depois de um dispatch.

Muita gente aperta o /compact do Claude Code seguindo uma regra do tipo "a cada 30 minutos" ou "quando o contexto passar de 70%", mas o que a documentação oficial recomenda não é nem relógio nem porcentagem: é uma pausa no trabalho. Rode o /compact em um ponto de corte natural, por exemplo entre tarefas, em vez de esperar o auto-compact disparar no meio de uma tarefa. Este artigo toma a documentação do Claude Code em 8 de agosto de 2026 (versão mais recente v2.1.226) como fonte primária e resolve a questão da compactação manual a partir da especificação. Ele começa pela maquinaria: a compactação roda em três estágios, a saber, o descarte de saídas antigas de ferramentas, o auto-compact e o /compact manual que você aperta. O segundo e o terceiro são o mesmo processamento, então apertá-lo você mesmo compra exatamente duas coisas, escolher o momento e especificar o que manter. Apertar com mais frequência não economiza contexto extra. Em seguida vem uma tabela do que sobrevive. O CLAUDE.md da raiz do projeto e a sua memória automática são reinjetados do disco, enquanto regras com paths: e arquivos CLAUDE.md aninhados em subdiretórios são perdidos até que um arquivo correspondente seja lido de novo, e os corpos das skills que você invocou são reinjetados sob um teto de 5.000 tokens por skill e 25.000 no total, descartando os mais antigos primeiro. Sobre custo, o preço de uma compactação é definido não pelo tamanho do contexto, e sim pelo cache de prompt estar quente ou não. Aperte no meio da sessão e o prefixo é lido do cache, o que sai barato; aperte depois de uma pausa mais longa que a vida útil do cache (uma hora em assinatura, cinco minutos por padrão via chave de API) e todo o histórico é reprocessado sem cache, o que é o mais caro que esse comando chega a ser. Daí em diante o artigo cobre como escolher entre /compact, /clear, /rewind, /recap e /context, como o /autocompact a partir da v2.1.221 move o ponto de disparo automático de 100K a 1M tokens e qual a precedência dos quatro lugares de onde a configuração pode vir, a armadilha de só a variável de ambiente aceitar um inteiro simples, e o significado e os passos de recuperação das duas mensagens "Not enough messages to compact." e "Autocompact is thrashing: the context refilled to the limit...".

Você tenta abrir o Claude Desktop no Windows e, no lugar do aplicativo, aparece uma caixa de diálogo com o título "Não é possível abrir este aplicativo", dizendo que é preciso ir às opções avançadas do Claude e selecionar Reparar — e fazer exatamente o que a mensagem manda funciona. Sem desinstalar e sem o Redefinir, que joga os seus dados fora. Existe, porém, um degrau no meio do caminho onde as pessoas realmente travam, e ele é o centro deste artigo. Ao clicar em Reparar, você pode receber uma mensagem dizendo que o aplicativo ainda está em execução, mesmo sem nenhuma janela do Claude aberta em lugar nenhum. A causa é que o Claude Desktop continua rodando na bandeja do sistema depois que você fecha a janela, e, enquanto esse processo residente segura os arquivos do pacote, o reparo não passa. A solução é simples: encerre os processos explicitamente e só então clique em Reparar. E esse fato aponta para a causa da própria falha — o mesmo processo quebrou a atualização e depois bloqueou o reparo. O artigo também responde à pergunta que quase todo mundo faz primeiro: as sessões são apagadas? A resposta se divide em três. O histórico de conversas do claude.ai fica nos servidores da Anthropic e não é tocado. As sessões do Claude Code ficam em %USERPROFILE%\.claude\projects\, fora do pacote do aplicativo, então sobrevivem a um reparo, a uma redefinição e até a uma desinstalação (uma máquina real guardava 2.977 arquivos, cerca de 3,0GB, em 52 projetos). A única coisa em risco são as configurações do lado do aplicativo em %APPDATA%\Claude, e nem essas o Reparar remove — o próprio Windows explica a diferença na tela, avisando que o Reparar não afeta os dados do aplicativo e que o Redefinir os exclui. A partir daí, o texto cobre a verificação de estado somente leitura no PowerShell, uma rotina de backup, uma escalada em etapas para quando o aplicativo ainda não abre (conferir se vmcompute e hns estão em execução, reinstalar com -PreserveApplicationData), a causa deduzida de um MSIX registrado pela metade junto com as issues do GitHub (#55465, em que a instalação foi bem-sucedida mas nenhum ponto de entrada foi criado, além de #50285 e #48437 — todas closed as not planned e sem correção oficial), como reduzir as chances de repetição e uma comparação com a versão antiga do instalador, em que tanto a versão MSIX mais recente quanto a máquina no formato antigo mediram 1.24012.9.

O Claude Code para no meio de uma resposta com "API Error: Connection closed mid-response. The response above may be incomplete." Isso não é um problema de prompting: a conexão que carregava a resposta em streaming foi fechada enquanto a resposta ainda chegava. Este artigo se baseia apenas na referência de erros oficial, no changelog oficial e em relatos apoiados por capturas de pacotes. Começa pelas definições oficiais: Connection closed significa que o enlace foi cortado, Response stalled que ficou em silêncio e Server error que um 5xx chegou no meio do stream; e explica por que a saída parcial é mantida de propósito (reenviar poderia executar duas vezes as mesmas chamadas de ferramenta) e que o passo de recuperação documentado é responder continue. Depois separa as três camadas de onde o fechamento pode partir (sua máquina e a suspensão, um corte por inatividade em proxy ou VPN, ou um fechamento iniciado pelo servidor) e apresenta as medições publicadas por quem reportou a issue #67766: os dez incidentes foram fechamentos limpos do servidor, o erro apareceu entre 3 e 105 ms após o FIN, de 7 a 20 KB da resposta já tinham sido entregues, o corpo da requisição tinha de 1 a 2,5 MB, uma conexão nova funcionou em cerca de 20 ms e apareceram 200 erros em 171 incidentes ao longo de 23 dias de transcrições, 87 deles a menos de cinco segundos da chamada anterior. O núcleo prático é uma cronologia de entradas reais do changelog — 2.1.179 preserva o parcial, 2.1.185 move o aviso de estagnação de 10 para 20 segundos, 2.1.198 repete quedas transitórias com backoff, 2.1.199 mantém o parcial em erros de servidor no meio do stream e 2.1.214 desativa o pool keep-alive após um erro de conexão obsoleta — comparada com as versões dos relatos (2.1.173, 2.1.181 e 2.1.183), todas anteriores à 2.1.198. Fecha com as condições que aumentam a probabilidade, um checklist de oito passos, seis diretrizes para desenvolvedores, como diferenciar de Unable to connect e Prompt is too long, e uma separação clara entre o que está confirmado oficialmente e o que não está.

A Anthropic lançou o Claude Opus 5 em 24 de julho de 2026, e a própria documentação o descreve como uma mudança de patamar, e não uma melhoria incremental sobre o Opus 4.8 — mesmo assim o preço não muda: $5 de entrada / $25 de saída por milhão de tokens, exatamente metade do carro-chefe Fable 5 ($10 / $50). Este artigo confronta o anúncio oficial e a documentação com várias reportagens e organiza as especificações principais (claude-opus-5, contexto de 1M que é ao mesmo tempo padrão e máximo, saída máxima de 128K, corte de conhecimento em maio de 2026), o preço incluindo taxas de cache e o modo rápido (cerca de 2,5x a velocidade pelo dobro do preço, somente na Claude API), os benchmarks (a Anthropic afirma no próprio texto que o Frontier-Bench é mais que o dobro do Opus 4.8, que o CursorBench 3.2 fica dentro de 0,5% do Fable 5, que o ARC-AGI 3 é três vezes o segundo colocado e que o OSWorld 2.0 supera o Fable 5 por cerca de um terço do custo; entre os números lidos nos gráficos pela imprensa estão Frontier-Bench 43,3%, ARC-AGI-3 30,2%, GDPval-AA 1.861 e OSWorld 70,6%) e também os pontos em que ele ainda perde (68,8% contra 72,7% do GPT-5.6 Sol no DeepSWE v1.1, segurança ofensiva e pesquisa biológica de longo prazo onde o Mythos 5 lidera, e cenários em que o effort max pontua abaixo de níveis mais baixos). Em seguida cobre as duas breaking changes da API (o thinking vem ligado por padrão, então orçamentos apertados de max_tokens acabam truncados; desligar o thinking só é permitido com effort high ou abaixo, e xhigh ou max devolve erro 400), como escolher entre os cinco níveis de effort, as novidades como troca de ferramentas no meio da conversa, cache mínimo de 512 tokens e modo de fallback padrão, a mudança de personalidade rumo a respostas mais longas, mais narração, mais delegação e autoverificação espontânea — com a regra de migração de que se remove texto do prompt em vez de acrescentar — e, por fim, quem deve migrar agora, além de um checklist de migração em seis passos.

Você abre o Hugging Face para rodar um LLM local e o mesmo modelo traz uma parede de arquivos (Q4_K_M, Q5_K_S, GPTQ, AWQ, IQ3_M) e você congela. Este artigo responde, na prática, qual arquivo quantizado você baixa para conseguir rodar, deixando o conceito de o que é quantização para outro artigo e focando em escolher o formato. A escolha são dois passos: qual formato (= em qual engine você roda), depois qual profundidade de bits. O fato mais importante é que um arquivo quantizado só roda em engines que suportam seu formato. GGUF é o único formato faz-tudo local que roda em CPU, Mac e GPU parcial (llama.cpp/Ollama); GPTQ/AWQ/EXL2 são focados em GPU (vLLM/TGI); bitsandbytes quantiza no carregamento no Transformers sem calibração. O nome GGUF Q4_K_M tem três partes: Q4 (4-bit nominal, maior = melhor e maior), K (K-quant sobre super-blocos; sem sufixo/_0/_1 são legados), M (S/M/L = quanto alguns tensores importantes são promovidos; os bits efetivos ficam acima do rótulo, Q4_K cerca de 4.5 bpw). A família IQ (I-quants) vai ainda menor nos mesmos bits, mas é mais pesada na inferência e precisa de um imatrix (uma matriz de importância da calibração que protege os pesos que importam). GPTQ minimiza o erro camada a camada; AWQ protege pesos importantes via ativações (nenhum é universalmente melhor). Para a profundidade de bits, na dúvida escolha Q4_K_M (padrão do Ollama para muitos modelos), suba para Q5_K_M/Q6_K com VRAM sobrando, Q8_0 é quase sem perdas mas não recomendado, e IQ2/IQ3 só para espremer um modelo grande. Cerca de 4.5 a 5 bpw é a faixa saborosa (uma heurística). Encontre arquivos via library=gguf, bartowski/mradermacher (atividade varia) ou tags do Ollama model:size-variant-quant. Os números são aproximados e variam conforme o modelo e o build.

Agora que "é só perguntar à IA" e "deixa a IA escrever tudo" são o padrão, a pergunta oposta é a que tem valor: esta é realmente uma situação em que eu deveria usar IA? Este artigo não é ser contra a IA; trata-se de manter o "não usar" como uma opção justamente para que você tire o máximo proveito da IA. A IA não é algo que se usa por padrão, mas uma ferramenta que se escolhe de propósito, e usar bem e escolher não usar são um par. Seis situações em que dispensá-la vence: 1. aprendizado que constrói fundamentos (o processo de escrever para pensar é o objetivo), 2. inserir dados confidenciais ou pessoais (não cole sem checar termos e retenção), 3. decisões finais fatais-se-erradas (medicina, direito, segurança, dinheiro não devem ser delegados sem verificação), 4. tarefas leves que não valem o custo, 5. trabalho em que a confiança ou criatividade humana é o centro (desculpas, contratação, autoria), 6. quando você não quer adicionar um ponto único de falha (continuidade do negócio). Decida rápido com três perguntas: você consegue verificar a saída, são apenas dados que pode compartilhar e o processo é algo que deveria estar treinando agora. Se consegue verificar, os dados são compartilháveis e não precisa treinar, use IA; caso contrário, dispense-a ou insira uma verificação humana. As desvantagens do uso excessivo (descarga cognitiva, aceitar erros plausíveis, dependência) são apresentadas como pontos de discussão, não números rígidos. Dispensar a IA de propósito não é um freio, mas a habilidade do outro lado que permite ir com tudo onde ela se encaixa, e uma proteção contra a dependência excessiva da IA.

Logo depois de atualizar o Claude Desktop (Windows), ao abrir o aplicativo surge "Há um outro programa usando este arquivo no momento" e ele não inicia — e continua quebrado até você reiniciar o PC. Esse é um bug conhecido na versão da Microsoft Store (MSIX) (GitHub #53247 e outros). O ponto principal: um reinício completo do PC não é necessariamente preciso — em muitos casos, apenas sair do Windows e entrar de novo já recupera (não é reiniciar o PC, nem sair da conta do Claude), porque o handle órfão por trás disso persiste por sessão de usuário do Windows. Parar o CoworkVMService ou reregistrar o pacote é relatado como algo que NÃO funciona. Apesar do texto da caixa de diálogo, está verificado que não há bloqueio de arquivo no espaço do usuário (handle.exe / Process Explorer): a falha real está na camada de contêiner do AppX/Desktop Bridge, na conversão de Job Object → Silo (0x80070020 = ERROR_SHARING_VIOLATION, eventos 215/208). O gatilho tem duas explicações sem definição — o serviço segurando o Job Object (#57221) vs. uma falha na inicialização deixando a limpeza por fazer (#53247) — e nenhuma correção oficial foi lançada. A solução permanente é migrar para a versão Squirrel (instalador). Baseado em uma única máquina (Windows 11 Home 10.0.26200) cruzada com issues do GitHub; com rótulos de confiança ao longo do texto.

Ao trabalhar por muito tempo no Claude Code, a resposta pode repetir "court" dezenas ou centenas de vezes e travar com "API Error: Response stalled mid-stream. The response above may be incomplete.". Não é erro do seu prompt: são dois defeitos conhecidos que se encadeiam — o loop de repetição (degeneração) do lado do modelo, com label area:model e bug, e a parada do stream do lado da transmissão. Este artigo explica a natureza das duas camadas, as condições que as provocam, como interromper na hora (Esc → nova sessão, /clear), como preveni-las via API/SDK e como distingui-las do bug de vazamento de tag court/invoke, tudo com base na documentação oficial e nas Issues reais do GitHub.