Por umas cinco semanas no começo de 2026, o Claude Code saiu com o nível de esforço de raciocínio padrão rebaixado sem aviso, e os desenvolvedores perceberam antes de a Anthropic explicar. Um executivo da AMD analisou 6.852 das próprias sessões e mediu uma queda de 67% no raciocínio do modelo. O episódio deixou pra trás um monte de folclore de configuração, e quase tudo já está velho ou sutilmente errado.
As configurações do Claude Code que merecem a sua atenção em 2026 são quatro: nível de esforço, regras de permissão, hooks do sistema de arquivos e higiene de MCP. Tudo neste post foi conferido na documentação oficial da Anthropic e no post-mortem de 23 de abril, com links, pra você conferir por conta própria.
O que aconteceu com o Claude Code no começo de 2026?
O Claude Code ficou mensuravelmente pior por um tempo, e a Anthropic documentou exatamente por quê. Em 4 de março de 2026, ela baixou o nível de esforço padrão de alto pra médio no Sonnet 4.6 e no Opus 4.6, porque alguns usuários no esforço alto viam o modelo pensar por tanto tempo que a interface parecia travada.
Depois de muita reclamação da comunidade, a Anthropic admitiu que a troca tinha sido errada, desfez a mudança em 7 de abril e publicou um post-mortem em 23 de abril cobrindo esse e outros dois problemas do mesmo período. O problema foi reconhecido e corrigido em semanas, e os tutoriais ensinando a brigar com ele continuaram saindo por meses.
O ecossistema de conselhos em volta das ferramentas de IA anda mais devagar que a própria ferramenta, o que quer dizer que um tutorial bem escrito de dez semanas atrás pode, com toda a confiança, te mandar brigar com um problema que não existe mais, usando uma variável que nunca existiu. Passei duas décadas lendo changelog antes de confiar em tutorial, e esse ciclo tornou o hábito obrigatório de novo.
Confira sempre a documentação. Depois configure.
Como controlar o nível de esforço de verdade?
Existem três jeitos legítimos de definir o esforço de raciocínio, e nenhum deles é o export CLAUDE_CODE_DEFAULT_EFFORT que você talvez tenha visto por aí. Dentro da sessão, digite /effort e escolha um nível. Pra deixar fixo, acrescente "effortLevel" no settings.json, ou exporte a variável de ambiente que existe de verdade:
export CLAUDE_CODE_EFFORT_LEVEL=high
Segundo a referência de variáveis de ambiente da Anthropic, a CLAUDE_CODE_EFFORT_LEVEL tem prioridade sobre o que você definiu com /effort, então trate o export como padrão global e o comando de barra como exceção pra uma sessão.
Ainda vale forçar o alto? Desde que a mudança foi desfeita em abril, os modelos atuais já vêm com níveis de esforço sensatos, então o ritual de "sempre forçar o alto" mais queima token em tarefas que nunca precisaram dele. A documentação recomenda casar o esforço com a tarefa: baixo ou médio pra edição pontual e busca rápida, alto pra trabalho de programação de verdade, em várias etapas. Na cobrança por uso, o esforço alto pode gerar várias vezes mais tokens que um nível abaixo no mesmo prompt, porque o modelo lê mais arquivos e faz mais rodadas de verificação antes de responder.
A mesma data de validade vale pra CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING. A variável é real e documentada, mas só afeta o Opus 4.6 e o Sonnet 4.6, que voltam a um orçamento fixo via MAX_THINKING_TOKENS. A partir do Claude Code v2.1.111, ela não afeta os modelos mais novos, que sempre usam raciocínio adaptativo.
Quais configurações de permissão valem a pena mudar?
Permissão é a primeira coisa que eu arrumaria, antes de mexer em qualquer outra, porque resolve os dois problemas reais do dia a dia: cansaço de aprovar tudo e o Claude lendo coisa que nunca deveria ler. A instalação padrão pergunta antes da maioria das chamadas de ferramenta. Num repositório em que você confia, mude o modo padrão e escreva os seus limites no settings.json:
{
"permissions": {
"defaultMode": "acceptEdits",
"allow": ["Bash(git status)", "Bash(npm run *)"],
"deny": ["Read(**/.env*)", "Read(**/.ssh/**)", "Bash(sudo *)"]
}
}
Com acceptEdits, as edições de arquivo e os comandos comuns de sistema de arquivos dentro da pasta de trabalho são aprovados sozinhos, e as outras ferramentas continuam perguntando. Num código que você não conhece, o modo plan deixa o Claude ler e explorar sem editar nada. As regras de deny são a parte que as pessoas pulam, e são a que importa: é a mesma definição de limites de onde parte a arquitetura de segurança de agentes nos sistemas de clientes. Um agente com acesso ao shell e sem limite explícito vai, uma hora, ler o seu .env por um motivo perfeitamente lógico. Escrevi sobre essa falha em detalhe em quando seu agente de IA tem as chaves de tudo, e o resumo é que controle de acesso é coisa de configuração, e não de prompt.
É a mesma lição que apliquei na Green Hat, muito antes dos agentes. Em mais de 30 projetos de clientes, os desenvolvedores tinham acesso total ao desenvolvimento, acesso limitado ao staging e nenhum acesso à produção, e todo deploy em produção passava por um PR que eu aprovava. Ninguém discutia permissão na hora, porque os limites tinham sido definidos antes.
Agente merece o mesmo tratamento que gente recebeu. Defina as regras uma vez, num arquivo, onde ninguém consegue argumentar pra contorná-las.
Hooks substituem a formatação manual?
Sim, e é nos hooks que a maioria dos tutoriais aponta pra direção certa com a sintaxe errada. Um exemplo quebrado comum usa um matcher tipo "Write(*.ts)", e não é assim que matcher funciona. Segundo o guia oficial de hooks, o matcher mira nomes de ferramenta (com regex, como Edit|Write), e o seu comando lê a entrada da ferramenta como JSON pelo stdin pra pegar 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 sozinho elimina a categoria inteira de trabalho chato do tipo "o Claude escreveu o arquivo, agora eu rodo o formatador". Um hook PreToolUse no Bash faz o contrário, como guarda: olha o comando que está pra rodar e sai com código 2 pra bloquear. Se você copiar a sintaxe de matcher quebrada, o hook simplesmente nunca dispara, e você passa uma tarde se perguntando por quê.
No lado WordPress do meu trabalho, o mesmo padrão roda o phpcs nos arquivos de plugin editados, e é assim que eu mantenho o Claude Code dentro dos fluxos de WordPress sem deixar o padrão de código escorregar.
O custo de tokens do MCP ainda é problema?
O custo antigo era ruim de verdade: o texto de engenharia da própria Anthropic mediu uma configuração com cinco servidores gastando uns 55.000 tokens em definições de ferramenta antes de a conversa começar, com um servidor pesado como o do Jira comendo uns 17.000 sozinho. Esses números alimentaram uma onda de conselhos do tipo "desconecte tudo".
Depois a Anthropic lançou a busca de ferramentas MCP, ligada por padrão, que tira as definições de ferramenta do contexto e carrega só o que o Claude precisa em cada turno, cortando o custo em torno de 85%. Desconectar servidor que você não usa há semanas ainda vale a pena, nem que seja porque menos ferramentas com nomes parecidos quer dizer menos escolha errada de ferramenta. Mas isso passou de socorro de emergência a higiene de rotina, e qualquer artigo que cite um custo fixo de tokens por servidor está descrevendo o mundo de antes da busca de ferramentas.
Resumindo
Se você for configurar só quatro coisas, que sejam estas: defina o effortLevel de propósito, em vez de deixar pro folclore; crie regras de permissão allow e deny, com .env e .ssh negados explicitamente; acrescente um hook PostToolUse de formatação com a sintaxe certa de matcher; e corte os servidores MCP que você não usa mais. Ignore qualquer coisa que prometa desfazer um nerf, e olhe a data do post-mortem antes de olhar a data do tutorial.
O hábito mais importante é tratar a configuração do seu agente como você trata infraestrutura de produção. Versionada e revisada como qualquer código, com as afirmações conferidas na fonte primária e não em tutorial, porque a ferramenta agora muda mais rápido do que o que se escreve sobre ela. O meu guia de configuração do Claude Code no macOS cobre a instalação de base sobre a qual este post se apoia, e o PACREF cobre o lado dos prompts depois que o ambiente está saudável.
O seu ambiente ou foi projetado, ou foi herdado de algum tutorial aleatório. Qual é o seu caso?
Se o seu time adotou o Claude Code há seis meses e ninguém revisou as configurações, as permissões ou os hooks desde então, essa revisão é a menor versão possível de um projeto de arquitetura de IA. Me manda o seu arquivo de settings.