Effort no Claude Code: quando usar cada nível
O effort no Claude Code define quanto trabalho o modelo investe em uma tarefa antes de devolver o resultado para você. Neste artigo, analisamos os testes e os dados do Terminal-Bench 3.0 publicados pela própria equipe do Claude Code para entender quando cada nível compensa.
O tema ganhou força com o Opus 5.5 e o Fable 5.1, porque esses modelos respondem às mudanças de nível sem quebrar o cache de prompt. Assim, trocar o nível no meio de uma sessão deixou de ser caro e passou a ser uma decisão tática do dia a dia.
O que é effort no Claude Code
Em termos simples, o effort no Claude Code é uma aproximação de quanto processamento você quer que o modelo gaste. Ele se relaciona com a sua própria estimativa de dificuldade da tarefa.
O autor do artigo original usa uma analogia útil. Se alguém pede uma tarefa com 12 horas de prazo, você entende que precisa caprichar ao máximo.
Por outro lado, se o prazo é de apenas 1 hora, você entrega a melhor versão possível naquele tempo e espera iterar depois. Em alguns casos, você ainda pode avisar que a tarefa exige pelo menos 3 horas e trabalhar esse tempo mínimo.
O effort no Claude Code segue a mesma lógica. O Claude sempre tenta resolver o pedido de forma razoável, mas um nível maior faz o modelo agir com mais autonomia para julgar e verificar o próprio trabalho.
Na prática, o effort não deixa o modelo mais inteligente. Em vez disso, ele controla quanto o Claude testa, revisa e explora casos de borda antes de responder.
Como o effort funciona na prática
Os níveis de effort no Claude Code vão de low até max, passando por medium, high e xhigh. Cada degrau aumenta tanto a taxa de acerto quanto o consumo de tokens.
Com pouco esforço, o modelo faz menos chamadas de ferramenta e parte direto para a ação. Com mais esforço, ele planeja, executa testes, lê código de dependências e revisa hipóteses.
Por isso, o effort no Claude Code funciona como um sinal de comportamento, e não como um orçamento rígido. Mesmo no nível low, o Claude ainda pensa quando encontra um problema difícil, só que pensa menos.
Além disso, um nível alto tende a gerar mais decisões tomadas pelo próprio modelo. Isso ajuda em tarefas autônomas, mas pode atrapalhar quando você quer participar de cada escolha.
Curvas de effort no Claude Code com Opus 5.5 e Fable 5.1
Segundo a equipe da Anthropic, as curvas de effort no Claude Code com Fable 5.1 e Opus 5.5 são as melhores até agora. Em cada nível existe um ganho de acerto no benchmark e um aumento proporcional de tokens.
O gráfico original compara quatro modelos no Terminal-Bench 3.0: Fable 5, Opus 5, Fable 5.1 e Opus 5.5. O teste usa as mesmas 70 tarefas para todos e deixa de fora as 4 tarefas que dependem de GPU.
O destaque fica com o Opus 5.5, que atinge a mesma pontuação de modelos anteriores gastando cerca de metade dos tokens. Em outras palavras, cada token rende mais trabalho útil do que antes.
Vale notar um detalhe metodológico. O Opus 5.5 rodou cerca de três semanas depois dos demais, com respostas limitadas a 128 mil tokens e sem acesso ao GitHub ou ao PyPI.
Se o custo também pesa na sua escolha, vale ler o nosso artigo sobre por que o Claude Opus 5.5 custa menos em sessões longas. Lá explicamos como proteger o cache e reduzir o consumo de tokens.
Testes de effort no Claude Code com tarefas reais
Para entender o comportamento do modelo, o autor executou as mesmas tarefas em vários níveis de effort no Claude Code com o Opus 5.5. Ele testou trabalhos variados, mas ilustrou o resultado com três exemplos simples.
Cada exemplo muda o grau de especificação do pedido, o que revela o papel do effort no Claude Code. Dessa forma, fica mais fácil perceber como o nível de esforço interage com a qualidade do prompt.
Tarefa de construção pouco especificada
No primeiro teste, o pedido foi apenas criar um app pessoal de acompanhamento de treinos. Nesse caso, o nível de esforço mudou drasticamente o quanto o app ficou completo.
No nível low, o resultado foi um registro de exercícios com um gráfico simples. Já nos níveis mais altos, o app ganhou volume semanal, recordes pessoais com estimativa de carga máxima e histórico detalhado.
No nível max, o Claude ainda adicionou um mapa de calor da atividade. Porém, cada recurso extra também representa uma decisão que o modelo tomou sozinho.
Portanto, o low serve quando você quer uma base simples para iterar. O max serve quando você quer a melhor tentativa única do Claude.
Tarefa de design levemente especificada
O segundo teste pediu um redesenho do menu de configurações do próprio Claude Code. Todas as execuções chegaram à mesma ideia central, com submenus e uma busca melhor.
No nível low, a tarefa levou cerca de 1 minuto e gerou um esboço interativo que transmitia a ideia, mas não lembrava muito a interface real. No nível max, o processo levou 28 minutos e entregou um mockup fiel, acompanhado de vários fluxos de navegação.
Para iterar e dar feedback, o low chega lá muito mais rápido. Ainda assim, o max entrega algo bem mais polido logo na primeira resposta.
O autor conta que, nessa tarefa específica, prefere o low para entender a visão do Claude antes de investir tempo.
Tarefa com especificação detalhada
No terceiro teste, o autor pediu que o Claude o entrevistasse em profundidade sobre o app de treinos. Em seguida, entregou essa especificação para modelos diferentes em níveis diferentes.
Com a especificação em mãos, os modelos se comportaram de forma muito parecida. Os designs e as implementações ficaram semelhantes, mudando apenas detalhes.
Curiosamente, no nível max o Claude dedicou tempo a simplificar alguns pontos da solução. Ou seja, uma boa especificação reduz a diferença entre os níveis em tarefas comuns.
Esse resultado conversa diretamente com a prática de spec driven development, em que a especificação guia toda a implementação.
O fluxo de trabalho recomendado
Para engenharia de software do dia a dia, a escolha do effort no Claude Code depende muito de quanto você quer participar do processo. O low responde rápido com um ponto de partida, enquanto os níveis altos fazem mais trabalho e assumem mais coisas por você.
A partir dos testes, o autor descreve um ciclo que tem funcionado bem para novas funcionalidades:
- Entregue uma especificação ao Claude e peça que ele entreviste você sobre os detalhes que faltam.
- Implemente a funcionalidade com effort low.
- Revise se o Claude entendeu a essência e itere em low quando necessário.
- Por fim, verifique e teste com effort high.
Esse fluxo combina o melhor dos dois mundos. Primeiro você mantém o controle das decisões com respostas rápidas, depois deixa o modelo caçar falhas com calma.
Effort no Claude Code em tarefas difíceis
Os exemplos anteriores são simples, porque o Claude consegue concluí-los em qualquer nível. A pergunta mais interessante surge quando o effort no Claude Code decide se a tarefa termina com sucesso ou não.
Para encontrar problemas desse tipo, o autor recorreu ao Terminal-Bench 3.0, um benchmark mantido pela comunidade. As tarefas se dividem em categorias como segurança, hardware, ML, ciência, software, operações e mídia.
O escopo das tarefas impressiona, porque elas vão muito além do trabalho comum de um desenvolvedor. Por exemplo, o benchmark inclui:
- Construir um console de videogame de 8 bits em Verilog que caiba em um FPGA pequeno.
- Provar formalmente o teorema de imersão de Takens em Lean 4.
- Unir 16 fragmentos de um checkpoint de mistura de especialistas em um único arquivo.
- Executar de ponta a ponta uma declaração mensal de estatísticas de comércio da União Europeia.
- Recriar um pôster como um arquivo de layout editável.
Casos de borda decidem o resultado
A principal conclusão do autor é que um effort alto no Claude Code rende mais em tarefas com muitos casos de borda escondidos. Um exemplo claro é a tarefa html-js-filter, que pede um sanitizador de HTML capaz de bloquear qualquer forma de injetar JavaScript.
Nessa tarefa, o Fable 5.1 passou de 1 acerto em 5 tentativas no low para 5 em 5 no xhigh. A diferença está no processo, e não na inteligência.
No low, cada tentativa levou cerca de 2 minutos. O modelo escreveu o filtro em uma única passada e testou contra uma página criada à mão.
No high, a execução levou cerca de 33 minutos. Durante esse tempo, o Claude revisou o primeiro rascunho de forma adversarial, leu o código do parser instalado, rodou uma suíte padrão de testes de XSS e ainda criou um fuzzer de documentos aleatórios.
Além disso, o autor analisou todas as falhas do benchmark. O aumento de esforço reduz as falhas por casos de borda esquecidos, mas não corrige quando o modelo escolhe a abordagem errada.
Com o Fable 5.1, por exemplo, os bugs que os próprios testes deixaram passar caíram de 40 para 14 entre o low e o max. Já as falhas por interpretar o problema do jeito errado subiram de 25 para 47.
Áreas que mais se beneficiam do effort
Outro achado interessante é que algumas áreas ganham bem mais com o esforço extra do que outras. A tabela abaixo resume a taxa de acerto do Fable 5.1 entre o esforço mais baixo e o mais alto.
| Categoria | Effort baixo | Effort alto |
|---|---|---|
| Segurança | 64% | 87% |
| Hardware | 34% | 75% |
| ML | 54% | 73% |
| Ciência | 41% | 61% |
| Software | 43% | 56% |
| Mídia | 18% | 30% |
| Operações | 12% | 22% |
Hardware mais que dobrou a taxa de acerto, enquanto segurança chegou perto de 90%. Por outro lado, tarefas de operações, que seguem regras de negócio extensas, continuam com resultados baixos mesmo no nível máximo.
Na prática, isso mostra que o effort no Claude Code ajuda quando verificar compensa. Quando o problema exige conhecimento de domínio que o modelo não tem, mais esforço não resolve.
Três exemplos do Terminal-Bench 3.0
O autor escolheu três tarefas em que o Opus 5.5 falhou no low e acertou nos níveis altos. Em todas elas, a vitória veio de testar e cobrir casos de borda.
A primeira, mvcc-lsm-compaction, pede a correção de um bug em um motor de armazenamento a partir do relatório de falha. O Opus 5.5 saiu de 0 em 5 no low para 4 em 5 no xhigh.
No low, o Claude editava o código antes mesmo de compilar ou reproduzir o erro. No xhigh, ele reproduziu a falha primeiro, criou testes aleatórios contra uma referência e confirmou que os testes falhavam com correções incompletas.
A segunda, cli-2ph-simplex, pede um solucionador de programação linear em Python. Nesse caso, o modelo foi de 0 em 5 no low para 5 em 5 no high.
As tentativas em low escreveram o solucionador de uma vez e testaram poucos problemas pequenos. Já no high, o Claude comparou o resultado com um solucionador de força bruta, mediu problemas maiores, encontrou travamentos e reescreveu a busca.
A terceira, gsea-proteomics, pede uma análise de enriquecimento de conjuntos de genes sobre dados de proteômica. O Opus 5.5 subiu de 0 em 5 para 4 em 5.
No low, o Claude escolheu uma forma razoável de preparar os dados e reportou o resultado. No high, ele testou duas preparações, percebeu que a lista de tratamentos mudava e investigou o motivo antes de decidir.
Com um usuário acompanhando, o Claude talvez perguntasse qual preparação usar. Sem ninguém no loop, porém, o nível alto se sai melhor.
Quando usar cada nível de effort no Claude Code
Com base em todos esses testes, o autor propõe uma regra prática para escolher o effort no Claude Code:
- Low: para respostas rápidas com você no loop, como brainstorming, esboços e mudanças fáceis.
- Medium: para a maior parte do trabalho regular de engenharia, como a implementação de novas funcionalidades.
- High: para trabalhos em que a verificação importa ou há casos de borda, como corrigir um bug em um código legado.
- Max: para quando o Claude precisa operar de forma autônoma em problemas difíceis, como construir e validar um app inteiro ou procurar vulnerabilidades em software crítico.
Repare que o medium aparece como padrão para o trabalho comum. Assim, você só precisa mexer no nível quando a tarefa foge do normal.
Também vale lembrar que mais esforço significa mais tempo de espera e mais tokens. Por isso, deixar tudo em max por precaução costuma desperdiçar recursos sem ganho real.
Como alterar o effort no Claude Code
A forma mais direta de mudar o effort no Claude Code é usar o comando /effort dentro da sessão. Você pode trocar o nível a qualquer momento, inclusive no meio da conversa.
# Abre o seletor de nível dentro da sessão
/effort
# Define o nível diretamente
/effort low
/effort high
# Inicia uma nova sessão já com um nível específico
claude --effort medium
Com o Opus 5.5 e o Fable 5.1, essa troca não invalida o cache de prompt. Portanto, você pode implementar em low e mudar para high na hora de verificar sem pagar caro por isso.
Se você gosta de personalizar a ferramenta, também pode explorar os Claude Code mods para exibir informações da sessão direto no terminal.
Conclusão
O effort no Claude Code não torna o modelo mais esperto, mas muda o quanto ele verifica, testa e decide sozinho. Essa diferença parece pequena em tarefas simples e se torna decisiva em problemas cheios de casos de borda.
Para o trabalho diário com o effort no Claude Code, a combinação de especificação clara, implementação em low e verificação em high entrega um ótimo equilíbrio. Enquanto isso, o max fica reservado para tarefas autônomas e críticas, como revisões de segurança.
Em resumo, escolha o nível pensando em quanto você quer participar do processo. Quanto mais você estiver no loop, menor o esforço necessário.
FAQ
O effort deixa o Claude mais inteligente?
Não. O effort controla quanto o Claude testa, revisa e verifica o próprio trabalho, sem alterar o conhecimento do modelo.
Qual nível de effort usar no dia a dia?
O medium atende a maior parte do trabalho regular de engenharia. Use low para esboços rápidos e high quando a verificação for importante.
Trocar o effort no meio da sessão quebra o cache?
Com o Opus 5.5 e o Fable 5.1, não. Esses modelos respondem à mudança de nível sem invalidar o cache de prompt.
Vale a pena deixar o effort sempre no max?
Na maioria dos casos, não. O max consome muito mais tempo e tokens e só compensa em tarefas autônomas e difíceis.
Em quais áreas o effort alto faz mais diferença?
Segurança, hardware e ML mostraram os maiores ganhos no Terminal-Bench 3.0. Operações e mídia ganharam pouco.