Por cerca de cinco semanas no início de 2026, Claude Code foi enviado com seu nível de esforço de raciocínio padrão reduzido silenciosamente, e desenvolvedores notaram antes da Anthropic explicar. Um executivo da AMD analisou 6.852 de suas próprias sessões e mediu uma queda de 67% no raciocínio do modelo. O episódio deixou para trás um monte de folclore de configuração, e a maioria dele agora está obsoleta ou sutilmente errada.
As configurações do Claude Code que realmente valem sua atenção em 2026 são quatro: nível de esforço, regras de permissão, hooks do sistema de arquivos e higiene MCP. Tudo neste post é verificado contra a documentação oficial da Anthropic e sua postmortem de 23 de abril, com links, para que você possa verificar por conta própria.
O que realmente aconteceu com Claude Code no início de 2026?
Claude Code piorou mensuralmente por um tempo, e Anthropic documentou exatamente por quê. Em 4 de março de 2026, eles alteraram o nível de esforço de raciocínio padrão de alto para médio no Sonnet 4.6 e Opus 4.6, porque alguns usuários em esforço alto viram tempos de pensamento longos o suficiente para fazer a UI parecer congelada.
Após reação sustentada da comunidade, Anthropic chamou isso de tradeoff errado, reverteu o padrão em 7 de abril e publicou uma postmortem em 23 de abril cobrindo isso e outras duas regressões do mesmo período. O problema foi reconhecido e corrigido dentro de semanas, enquanto tutoriais ensinando pessoas a lutar contra isso continuaram sendo publicados por meses.
O ecossistema de conselhos ao redor de ferramentas de IA se move mais lentamente que a própria ferramenta, o que significa que um tutorial bem escrito de dez semanas atrás pode confidentemente dizer para você lutar contra um problema que não existe mais, usando uma variável que nunca existiu. Passei duas décadas lendo changelogs antes de confiar em tutoriais, e esse ciclo tornou esse hábito obrigatório novamente.
Sempre verifique a documentação. Depois comece a configurar o sistema.
Como você realmente controla o nível de esforço?
Existem três formas legítimas de definir o esforço de raciocínio, e nenhuma delas é o export CLAUDE_CODE_DEFAULT_EFFORT que você pode ter visto circulando. Dentro de uma sessão, digite /effort e escolha um nível. Para persistir, adicione "effortLevel" ao seu settings.json, ou exporte a variável de ambiente que realmente existe:
export CLAUDE_CODE_EFFORT_LEVEL=high
De acordo com a referência de variáveis de ambiente da Anthropic, CLAUDE_CODE_EFFORT_LEVEL sobrescreve o que você definiu com /effort, então trate o export como um padrão global e o comando de barra como a exceção para uma sessão.
Forçar alto ainda vale a pena? Desde a reversão de abril, modelos atuais padrão para níveis de esforço sensatos fora da caixa, então o ritual "sempre forçar alto" principalmente queima tokens em tarefas que nunca precisavam. Os docs recomendam corresponder esforço à tarefa: baixo ou médio para edições limitadas e pesquisas rápidas, alto para trabalho de codificação real em múltiplas etapas. Em faturamento baseado em uso, esforço alto pode gerar várias vezes os tokens de um nível inferior no mesmo prompt, porque o modelo lê mais arquivos e executa mais passes de verificação antes de responder.
A mesma obsolescência se aplica a CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING. A variável é real e documentada, mas afeta apenas Opus 4.6 e Sonnet 4.6, onde volta para um orçamento fixo via MAX_THINKING_TOKENS. A partir de Claude Code v2.1.111, não afeta modelos mais novos, que sempre usam raciocínio adaptativo.
Quais configurações de permissão valem a pena mudar?
Permissões são as configurações que eu corrigiria antes de mexer em qualquer outra coisa, porque resolvem ambos os problemas diários reais: fadiga de aprovação e Claude lendo coisas que nunca deveria ler. A instalação padrão pergunta antes da maioria das chamadas de ferramentas. Em um repositório em que você confia, mude o modo padrão e codifique suas limitações em settings.json:
{
"permissions": {
"defaultMode": "acceptEdits",
"allow": ["Bash(git status)", "Bash(npm run *)"],
"deny": ["Read(**/.env*)", "Read(**/.ssh/**)", "Bash(sudo *)"]
}
}
Com acceptEdits, edições de arquivo e comandos comuns do sistema de arquivos no diretório de trabalho são aprovados automaticamente enquanto outras ferramentas ainda perguntam. Para um codebase desconhecido, o modo plan deixa Claude ler e explorar sem editar nada. As regras de deny são a parte que as pessoas pulam, e são a parte que importa. Um agente com acesso a shell e sem limitações explícitas eventualmente lerá seu arquivo .env por uma razão perfeitamente lógica. Escrevi sobre esse modo de falha em profundidade em quando seu agente de IA tem as chaves de tudo, e a versão curta é que controle de acesso pertence a configuração, não a prompts.
Esta é a mesma lição que apliquei no Green Hat, muito antes de agentes. Em mais de 30 projetos de clientes, desenvolvedores tinham acesso total ao dev, acesso limitado a staging e zero acesso a produção, com cada deploy de produção passando por um PR que aprovei. Ninguém debateu permissões no momento porque as limitações foram definidas com antecedência.
Agentes merecem o mesmo tratamento que humanos receberam. Defina as regras uma vez, em um arquivo, onde não podem ser argumentadas para sair.
Hooks substituem formatação manual?
Sim, e hooks são onde a maioria dos tutoriais aponta na direção certa com sintaxe errada. Um exemplo quebrado comum usa um matcher como "Write(*.ts)", o que não é como matchers funcionam. De acordo com o guia oficial de hooks, o matcher alveja nomes de ferramentas (como regex como Edit|Write), e seu comando lê a entrada da ferramenta como JSON de stdin para obter o caminho do arquivo:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
}
]
}
]
}
}
Esse hook único remove toda a categoria de trabalho tedioso "Claude escreveu o arquivo, agora executo o formatador". Um hook PreToolUse em Bash pode fazer o trabalho inverso como um guarda: inspecione o comando prestes a ser executado e saia com código 2 para bloqueá-lo. Se você copiar a sintaxe de matcher quebrada, o hook simplesmente nunca dispara, e você passará uma tarde se perguntando por quê.
Para o lado WordPress do meu trabalho, o mesmo padrão executa phpcs contra arquivos de plugin editados, que é como mantenho Claude Code dentro de workflows WordPress sem deixar os padrões de codificação derivarem.
O overhead de token MCP ainda é um problema?
O overhead anterior era genuinamente ruim: a escrita de engenharia própria da Anthropic mediu uma configuração de cinco servidores consumindo aproximadamente 55.000 tokens em definições de ferramentas antes da conversa mesmo começar, com um servidor pesado único como Jira comendo cerca de 17.000 por conta própria. Essas figuras alimentaram uma onda de conselho "desconecte tudo".
Depois a Anthropic enviou busca de ferramenta MCP, habilitada por padrão, que retém definições de ferramenta do contexto e carrega apenas o que Claude precisa por turno, cortando o overhead em torno de 85%. Desconectar servidores que você não toca há semanas ainda vale a pena, se apenas porque menos ferramentas com nomes similares significa menos seleções erradas de ferramentas. Mas se moveu de triagem de emergência para higiene rotineira, e qualquer artigo citando um custo fixo por servidor de tokens está descrevendo o mundo antes da busca de ferramentas existir.
A conclusão
Se você configurar apenas quatro coisas, que sejam estas: defina effortLevel deliberadamente em vez de deixar ao folclore, defina regras de permissão allow e deny com .env e .ssh explicitamente negados, adicione um hook PostToolUse de formatação com a sintaxe correta de matcher, e podas servidores MCP que você não usa mais. Pule qualquer coisa que prometa reverter um nerf, e verifique a data na postmortem antes de verificar a data no tutorial.
O hábito mais profundo é tratar a configuração do seu agente da forma que você trata infraestrutura de produção. Versionado e revisado como qualquer outro código, com reclamações verificadas contra fontes primárias em vez de tutoriais, porque a ferramenta agora muda mais rápido que o conteúdo escrito sobre ela. Meu guia de configuração do Claude Code para macOS cobre a instalação de baseline em que este post se constrói, e PACREF cobre o lado de prompting uma vez que o ambiente está saudável.
Seu ambiente é engenhado ou herdado de um tutorial aleatório. Qual é o seu?
Se sua equipe adotou Claude Code há seis meses e ninguém auditou as configurações, permissões ou hooks desde então, essa revisão é exatamente o tipo de consultoria que faço. Entre em contato.