Claude nerfado é, na prática, uma queda de confiança: a Anthropic que não reduz a capacidade do modelo para servir demanda, enquanto usuários relatam sessões piores no Claude Code. A discussão virou uma issue pública com milhares de arquivos de log analisados e uma resposta oficial que atribui tudo a um bug de exibição.
Claude nerfado: o que a Anthropic nega e o que usuários relatam
Claude nerfado descreve a percepção de que o Claude Code piorou em tarefas complexas, não uma confirmação de que a Anthropic reduziu a capacidade do modelo. A empresa nega degradar modelos para atender demanda, e atribui os números menores a um bug de exibição do raciocínio dentro do Claude Code.
O Claude Code é a ferramenta de codificação agêntica da Anthropic que roda no terminal. O relato central veio de uma issue pública, não de um benchmark controlado, e isso define o teto da evidência disponível.
A issue argumenta que o Claude Code ficou inutilizável para tarefas complexas de engenharia desde as atualizações de fevereiro. A resposta oficial tratou o caso como bug: o Claude Code mostra menos o que pensa, e por isso os números parecem menores.
Uma leitura cética do caso aceita duas coisas ao mesmo tempo. Há mudança real na forma como a ferramenta entrega resultado, e não há prova pública de que o modelo em si ficou mais fraco. As duas afirmações convivem sem contradição.
O que a issue analisou e por que a medição é frágil
A análise que sustenta o relato examinou 6.852 arquivos de log de sessão do Claude Code, 234 mil chamadas de ferramenta e 17 mil blocos de pensamento. Esses números medem registros produzidos pela própria ferramenta, não a capacidade bruta do modelo.
A Anthropic reconheceu que medir isso é difícil, e o argumento técnico tem fundamento. Se o Claude Code esconde parte do raciocínio na saída, qualquer contagem de blocos de pensamento cai sem que o desempenho caia na mesma proporção.
O próprio fluxo do agente complica a leitura. Um modelo pode ler arquivos via Bash sem gerar um bloco de pensamento visível, continuar sessões anteriores em que a leitura já ocorreu ou resolver uma tarefa com menos leituras por acaso.
Menos leitura de arquivo não prova modelo mais fraco. Isso torna a comparação entre sessões ruidosa, e explica por que o debate público travou entre relato qualitativo e negação oficial.
O horário de pico e a disputa sobre capacidade
Em janeiro de 2026, circulou a tese de que a Anthropic reduzia a qualidade em horários de pico para preservar capacidade. A alegação nunca foi comprovada publicamente, e a empresa negou a prática.
O mecanismo descrito na tese não exige trocar de modelo. Com recursos limitados, um provedor escolhe entre responder mais devagar ou entregar menos raciocínio por requisição. Como você não vê essa escolha, a experiência piora sem aviso.
A disputa virou questão de transparência quando usuários relataram sessões de 10 a 15 minutos para tarefas que antes levavam cerca de 30 segundos. Um relato de usuário é evidência de experiência, não medição independente de infraestrutura.
A Anthropic mantém a posição de que não degrada modelos para servir demanda. Sem dados de servidor auditáveis, você pode verificar apenas o que chega até você.
Confiança, preço e a decisão de trocar de ferramenta
Mudança silenciosa em produto pago afeta mais a confiança do que a velocidade. Quando o comportamento muda sem changelog, sem e-mail e sem post, o usuário perde a base para decidir se o problema está no código dele, na sessão ou no provedor.
Esse é o ponto que transforma Claude nerfado em decisão prática. A troca de ferramenta não acontece só porque a resposta ficou pior. Acontece porque você não consegue prever quando ela vai piorar.
A comparação abaixo separa o que cada opção oferece hoje. A escolha depende do seu fluxo de trabalho, não de uma nota geral.
| Aspecto | Claude Code | Alternativas citadas |
|---|---|---|
| Interface principal | Terminal (CLI) | IDE ou aplicativo com terminal integrado |
| Ponto forte | Fluxo agêntico no terminal | Gestão de múltiplas tarefas ao mesmo tempo |
| Sinal de alerta | Mudança de comportamento sem aviso | Troca de contexto entre ferramentas |
| Evidência de desempenho | Relatos qualitativos | Relatos qualitativos |
Como diferenciar bug de exibição de degradação real
Você não consegue provar degradação real só olhando a saída do Claude Code. O protocolo abaixo reduz o ruído e produz comparação mínima, ainda que não substitua um benchmark controlado.
- Fixe uma tarefa de referência com arquivos, entrada e critério de sucesso definidos.
- Registre a configuração exata da sessão, incluindo o nível de esforço escolhido.
- Rode a mesma tarefa em horários diferentes e anote o tempo até a primeira resposta útil.
- Compare o resultado final, não a contagem de blocos de pensamento exibidos.
- Guarde o log bruto, porque a saída visível pode ter sido reduzida por bug.
Esse desenho não resolve a disputa de infraestrutura. Ele responde a uma pergunta diferente e mais útil: o resultado que chega até você piorou na mesma configuração?
O que ele não faz é isolar a causa. Uma diferença de tempo entre dois horários pode vir de demanda, de rede, do tamanho do repositório ou de mudança de comportamento do agente.
Open source, calibração e os limites do que dá para verificar
O Claude Code é distribuído com parte do código visível no repositório público, mas o lado do servidor não é aberto. Toda a parametrização de atendimento, incluindo limites de esforço por requisição, permanece fora do alcance de auditoria externa.
Essa assimetria explica por que o pedido recorrente é ver o processo de decisão do servidor, e não apenas o cliente. Enquanto isso não existe, a verificação possível fica limitada ao que a ferramenta expõe na sua máquina.
Vale separar também o que é bug do que é decisão de produto. Um bug de exibição altera o que você vê. Uma política de capacidade altera o que você recebe. São diagnósticos diferentes com remédios diferentes.
Sem changelog detalhado, os dois casos ficam indistinguíveis para o usuário. Essa indistinção é o problema real, e nenhum dos lados do debate consegue eliminá-la com o material público atual.
Perguntas frequentes sobre o Claude nerfado
- O Claude nerfado é confirmado pela Anthropic?
Não. A Anthropic afirma que não degrada modelos para servir demanda e atribui os números menores a um bug de exibição no Claude Code. Existe mudança observável na experiência, não confirmação oficial de redução de capacidade.
- A issue com 6.852 arquivos prove que o modelo piorou?
Ela prova que os registros de sessão mudaram no período analisado. Como os próprios logs podem esconder raciocínio por bug, a contagem de blocos de pensamento não é medida direta de capacidade.
- Por que a medição pública é considerada frágil?
Porque o agente pode ler arquivos por Bash, continuar sessões anteriores e resolver tarefas com menos leituras visíveis. Esses fatores alteram os números sem indicar queda de desempenho.
- O que fazer se o Claude Code parecer pior?
Fixe uma tarefa de referência, registre a configuração e compare resultados em horários diferentes. Meça o resultado final, não a quantidade de raciocínio exibida.
- Vale trocar de ferramenta por causa disso?
A troca por multitarefa é decisão de fluxo de trabalho. A troca por falta de transparência é decisão de risco. As duas têm motivos diferentes.
- O que a Anthropic poderia publicar para encerrar o debate?
Registros de parametrização do lado do servidor e changelog de mudanças que afetam comportamento. Sem isso, a discussão continua presa a relatos qualitativos.
- Quais ferramentas competem com o Claude Code nesse cenário?
Codex, da OpenAI, e Cursor de código com IA, aparecem como alternativas citadas por quem relata queda de experiência. Nenhuma delas tem medição independente comparável.
- O padrão de esforço do Claude Code muda sozinho?
Não há evidência pública de alteração automática. O que existe é a suspeita de rebaixamento transparente em pico, negada pela Anthropic.
- Claude nerfado é o mesmo que modelo trocado por versão menor?
Não. Trocar o modelo por um menor é hipótese diferente de reduzir recursos ou esconder raciocínio. A Anthropic nega as duas.
- O que observar nos próximos meses?
Se aparecer changelog descrevendo mudanças de comportamento e limites por plano, o diagnóstico de bug ganha força. Se nada mudar, a desconfiança continua igual.
O mesmo raciocínio serve para outros temas técnicos densos, como os de Crazystack Typescript, onde contexto e versão mudam a resposta. Quem acompanha o Bootcamp do Dev Doido costuma ver esse padrão de perto.
O canal de Gustavo Dev Doido cobre esse tipo de decisão com exemplos concretos. Vale acompanhar quem prefere testar antes de opinar.
O que fazer com essa informação na prática
Trate Claude nerfado como sinal de risco, não como veredito técnico. A resposta pública da Anthropic nega redução de capacidade, e a medição independente disponível não fecha a questão.
O efeito prático é manter plano B. Quem depende de uma única ferramenta em tarefa crítica fica exposto a mudanças que não controla e não enxerga.
Esse é o tipo de conteúdo que o Skala Blog transforma em texto a partir de vídeos como este. Se você explica decisões técnicas em vídeo e quer que elas circulem em texto, cole a URL do YouTube, transcricione e gere o artigo no Skala Blog.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits