Claude Code: o que o nível de Esforço realmente faz

O problema

No Claude Code (a ferramenta de linha de comando que usamos para conversar com a Inteligência Artificial), existe uma opção de configuração chamada Effort (Esforço), também conhecida como Thinking Budget (ou “orçamento de pensamento”). Na prática, é um botão onde você escolhe entre quatro níveis: Low (Baixo), Medium (Médio), High (Alto) e Max (Máximo). A promessa dessa opção é simples: quanto maior o nível, mais a IA “pensa” antes de te dar uma resposta.

Eu estava usando o Claude Code conectado ao serviço de IA da Zhipu por meio de uma ferramenta chamada LiteLLM (que funciona como um “tradutor” ou intermediário entre diferentes sistemas de IA). Naturalmente, imaginei que colocar o Effort no Max deixaria as respostas bem melhores para resolver tarefas difíceis.

No entanto, passei um dia inteiro com o Effort configurado em Max para tudo e não vi diferença nenhuma na qualidade — a única coisa que mudou foi o meu limite de uso (a cota) acabando mais rápido. Fiquei desconfiado e fui investigar.

A descoberta? No meu setup, a configuração de Effort estava sendo descartada no meio do caminho, em silêncio, e nunca chegava até a IA de fato. Escrevi este artigo para te contar exatamente o que descobri, evitando que você também gaste cota achando que a IA está “pensando mais”.

O que o Effort realmente é

Para entender o problema, vale explicar o que é o modo “Thinking” (raciocínio). Quando ele está ativado, a IA gera “tokens de pensamento” — que são como um rascunho invisível. Ela resolve o problema passo a passo nessa “rascunheira” interna antes de escrever a resposta final para você.

Quando você seleciona um nível no Claude Code, o programa converte essa sua escolha em um número exato de “fichas de processamento”, chamadas de budget_tokens, e envia isso para a API (o sistema da IA). A relação funciona mais ou menos assim:

Nível (Claude CLI)	`budget_tokens`	Uso indicado
Low / nenhum	0 a 1.024	Refatorações simples, dúvidas rápidas
Medium	2.048 a 4.096	Criar funções novas, ler logs
High	8.192 a 16.384	Componentes complexos do zero, refatorar arquitetura
Max	32.000+	Projetos inteiros, debugging profundo

Essa lógica funciona perfeitamente quando você está se comunicando diretamente com a Anthropic (a criadora do Claude). O problema surge quando colocamos um proxy (um ponte ou intermediário) no meio dessa conversa.

O paradoxo da tradução: Zhipu + LiteLLM

É aqui que as coisas se complicam. O Claude Code envia um pedido contendo esta instrução técnica: "thinking": {"budget_tokens": 8192}. Porém, quando o destino final é a Zhipu (que usa os modelos chamados GLM), ela simplesmente não entende essa linguagem da Anthropic — o sistema dela não sabe o que fazer com a instrução budget_tokens.

E como o LiteLLM (nosso “tradutor”) reage a isso? Depende de como ele foi configurado. No meu arquivo de configuração config.yaml, eu tinha ativado a opção drop_params: true — que é exatamente o que recomendamos no artigo sobre o proxy. Essa regra diz ao LiteLLM o seguinte: “se chegar algum parâmetro que o sistema de destino não suporta, apenas jogue-o fora em silêncio e siga em frente”.

Resultado: o bloco thinking era jogado no lixo. A requisição chegava pura para a Zhipu, sem o budget_tokens. A IA respondia do jeito normal de sempre — tornando a escolha de Effort totalmente irrelevante.

“Quer dizer que o modo Thinking não funciona com a Zhipu?”

Sim e não. A Zhipu possui modelos capazes de raciocinar (como o GLM-4-Plus e outros futuros), mas a forma de ligar o raciocínio profundo neles não é usando o budget_tokens da Anthropic. Isso é controlado pelo nome do modelo que você escolhe (ou por configurações específicas da Zhipu, como a temperature).

Ou seja: no seu Claude CLI você pode até selecionar “Max Effort”, mas se o LiteLLM apagar essa instrução antes de entregar a mensagem para a Zhipu, a IA não vai “pensar mais”. Ela vai responder exatamente da mesma forma que responderia se você tivesse deixado no Low.

Nesse tipo de estrutura, a forma real de controlar o “esforço” não é pelo botão do Claude Code, mas sim escolhendo o modelo adequado dentro do config.yaml. Se você quer trabalho pesado, escolhe o modelo GLM-4-Plus com Deep Thinking ativado; se quer trabalho simples e mecânico, escolhe o GLM-Turbo. O seletor de Effort vira um botão de enfeite quando o parâmetro é descartado.

A exceção: DeepSeek

Com o DeepSeek a história é bem diferente. A API do DeepSeek suporta nativamente um conceito de modo de raciocínio muito parecido com o da Anthropic. O LiteLLM consegue traduzir o budget_tokens do formato Anthropic para o formato equivalente que a API do DeepSeek espera receber.

Neste cenário específico, escolher “High” no Claude Code realmente funciona: faz o DeepSeek rascunhar por mais de 8 mil tokens antes de começar a gerar o código final. Aí sim, o Effort deixa de ser um efeito placebo e passa a ser um custo real de processamento.

A regra que fixei

Depois de investigar e entender todo esse caminho, criei uma regra prática para o meu dia a dia:

Usando Zhipu GLM via proxy com drop_params: true: mantenha o Effort no nível baixo ou simplesmente ignore-o. Esse parâmetro será ignorado de qualquer forma. Controle a “força” da IA escolhendo o modelo correto no arquivo YAML (use GLM-4-Plus para tarefas complexas e GLM-Turbo para coisas mecânicas).
Usando DeepSeek via proxy: aqui o Effort muda diretamente o quanto você paga. Usar Max consome sua cota diária muito rápido. Use High apenas para tarefas bem difíceis e Medium para o uso diário.

O teste definitivo é simples: se o provedor final entende o comando budget_tokens, o Effort funciona; se ele não entende, o Effort é placebo. Para descobrir isso, basta dar uma olhada no seu config.yaml (procurando pela instrução drop_params) e checar a documentação da IA que você está usando.

Como eu confirmei que era placebo

Como eu desconfiava que o Effort não estava fazendo nada, fui buscar provas concretas. O LiteLLM registra em texto (logs) tudo o que entra e sai. Então, rodei o proxy salvando esses registros em um arquivo e pedi para a IA fazer exatamente a mesma tarefa três vezes: uma no Effort Low, uma no Medium e uma no Max.

Ao olhar o arquivo de log, veio a confirmação: nas três tentativas, a instrução thinking tinha sido descartada por causa do drop_params. As três mensagens chegaram idênticas para a Zhipu, e as respostas foram equivalentes. Estava provado: o ajuste de Effort nem sequer chegava até a IA.

Esse é o tipo de detalhe técnico que a gente só descobre quando investiga a fundo. Se eu não tivesse olhado os logs, continuaria acreditando no efeito placebo.

O que aprendi

A grande lição que fica para além deste caso é: qualquer configuração que precise passar por um “tradutor” (proxy) deve ser vista com desconfiança até que você prove que ela funciona. O botão de Effort parecia estar funcionando porque a ferramenta (CLI) não mostrava nenhum erro — só que “não dar erro” não significa que a mensagem chegou ao destino final. Agora, sempre que monto um proxy (seja LiteLLM ou outro), faço um teste com os logs abertos para ter certeza de que as instruções estão realmente sendo entregues.

E a segunda lição, mais geral: “fazer a IA pensar mais” não é um botão universal. Cada família de modelo de IA tem a sua própria maneira de ativar o raciocínio profundo — algumas usam parâmetros, outras exigem a escolha de um modelo específico, e outras dependem do jeito que você escreve a instrução (prompt). Achar que o botão da Anthropic vai funcionar em qualquer lugar é tentar encaixar a tomada de um aparelho na tomada de outro. Eu fui checar e vi que o botão era placebo no meu caso. Se não tivesse testado, estaria jogando cota fora em um botão que não faz absolutamente nada.