Fiz o Claude Code Falar Como um Homem das Cavernas. Ele Ficou Mais Inteligente.

Fiz o Claude Code Falar Como um Homem das Cavernas. Ele Ficou Mais Inteligente.

O repositório no GitHub tinha 589 estrelas e um slogan que parecia uma piada: "why use many token when few token do trick." Quase fechei a aba. Eu estava imerso em um fluxo de trabalho com Opus 4.6 — agentes rodando em quatro projetos, custos de tokens subindo para valores que eu preferia não pensar — e a última coisa que eu precisava era uma ferramenta de meme prometendo resolver meus custos.

Então li a afirmação: 75% de redução nos tokens de saída.

Esse número me parou. Não porque eu acreditasse — não acreditava — mas porque se mesmo uma fração daquilo fosse verdade, eu estava deixando dinheiro sério na mesa todos os dias. Então instalei. E o que aconteceu depois não foi o que eu esperava. A economia de tokens foi real, mas modesta. A parte que genuinamente me surpreendeu? O Claude começou a me dar respostas melhores.

Não "melhores" de um jeito vago e subjetivo. Melhores de uma forma que um artigo de pesquisa de março de 2026 no arXiv já havia previsto. Um artigo que avaliou 31 modelos em 1.485 problemas e descobriu algo que quebra a intuição da maioria das pessoas sobre como grandes modelos de linguagem funcionam.

Preciso te guiar pelo que realmente aconteceu — os números reais, as economias reais e a ciência que explica por que fazer sua IA falar como um neandertal pode ser uma das coisas mais inteligentes que você pode fazer com ela.

O Que o Skill Caveman Realmente Faz

O skill caveman, criado pelo desenvolvedor independente Julius Brussee, é um skill do Claude Code que reduz as respostas do Claude ao essencial. Sem artigos. Sem palavras de preenchimento. Sem polidez. Sem atenuações. Fragmentos em vez de frases completas. Termos técnicos permanecem exatos. Blocos de código ficam intocados.

Veja como a diferença se parece na prática.

Resposta normal do Claude: "Seu componente está rerenderizando porque você está criando uma nova referência de objeto a cada ciclo de renderização. A prop de objeto inline gera uma nova referência toda vez que o componente pai rerenderiza, o que faz com que o componente filho também rerenderize. Eu recomendaria envolver o objeto em useMemo para manter a estabilidade referencial."

Modo caveman full: "Nova ref obj a cada render. Inline obj prop = nova ref = re-render. Envolver em useMemo."

Modo caveman ultra: "Inline obj prop -> nova ref -> re-render. useMemo."

A mesma informação. A mesma precisão técnica. Dramaticamente menos tokens.

A instalação requer um único comando:

npx skills add JuliusBrussee/caveman

Você o ativa digitando /caveman na sua sessão do Claude Code, ou frases como "talk like caveman" ou "less tokens please." Para voltar ao normal, digite stop caveman ou normal mode. Três níveis de intensidade — lite, full e ultra — permitem ajustar a compressão ao seu nível de conforto.

O skill também vem com uma ferramenta complementar que comprime seus arquivos de memória (como CLAUDE.md) em aproximadamente 45%, cortando tokens de entrada em cada interação. Se você leu minha análise sobre por que seu arquivo CLAUDE.md é seu superpoder ou seu gargalo, sabe o quanto esses tokens de contexto persistente se acumulam.

Mas aqui preciso ser honesto com você — porque os números das manchetes não contam a história que a maioria das pessoas pensa.

A Matemática de Tokens Que a Maioria Entende Errado

O repositório caveman afirma até 75% de redução em tokens de saída e 45% de redução em tokens de entrada. Esses números são tecnicamente precisos. Também são profundamente enganosos se você não entende o que estão realmente medindo.

Realizei uma auditoria completa das minhas próprias sessões do Claude Code para descobrir para onde os tokens realmente vão. Aqui está o detalhamento que mudou minha perspectiva.

Uma sessão típica do Claude Code consome aproximadamente 100.000 tokens no total. Isso se divide em cerca de 75.000 tokens de entrada e 25.000 tokens de saída. O modelo mental da maioria das pessoas já está errado — assumem que a saída é o grande gerador de custos, mas os tokens de entrada superam os de saída 3:1 em uma sessão normal de programação.

Agora veja o que compõe esses 25.000 tokens de saída:

• Chamadas de ferramentas — quando o Claude lê arquivos, pesquisa sua base de código, executa comandos. São payloads JSON estruturados. O modo caveman não os toca.
• Blocos de código — o código real que o Claude escreve. O modo caveman os deixa completamente intactos (e deve — você não quer nomes de variáveis comprimidos).
• Respostas em prosa — as explicações, sugestões e comentários do Claude. Esta é a única parte que o modo caveman comprime.

Nas minhas sessões, respostas em prosa representaram cerca de 6.000 dos 25.000 tokens de saída. O modo caveman comprimiu esses 6.000 tokens em aproximadamente 75%, economizando cerca de 4.500 tokens.

4.500 tokens de 100.000 no total.

Isso é uma redução de 4,5% por sessão. Não 75%.

No lado da entrada, a compressão dos arquivos de memória economiza cerca de 1.000 a 2.000 tokens por sessão. O restante dos seus tokens de entrada — histórico de conversação, conteúdo de arquivos que o Claude lê, prompts do sistema — permanece inalterado.

Economia realista combinada: aproximadamente 4-5% de redução total de tokens por sessão.

4-5% é inútil? Absolutamente não. Se você está rodando Claude Code oito horas por dia em múltiplos projetos — e eu estou — isso se acumula. Com meu uso de aproximadamente $200/mês, economiza $8-10 mensais. Não é transformador, mas é uma otimização gratuita sem nenhum esforço após a instalação.

Mas a economia de custos não é o motivo pelo qual mantive o modo caveman ativado. O motivo não tem nada a ver com tokens.

O Artigo de Pesquisa Que Mudou Minha Opinião

Em março de 2026, um artigo apareceu no arXiv que inicialmente passei batido: "Brevity Constraints Reverse Performance Hierarchies in Language Models". O título soava acadêmico e seco. As descobertas foram tudo menos isso.

Os pesquisadores avaliaram 31 modelos de pesos abertos variando de 0,5 bilhão a 405 bilhões de parâmetros em 1.485 problemas distribuídos por cinco conjuntos de dados de benchmark. A pergunta era simples: o tamanho do modelo sempre equivale a melhor desempenho?

A resposta quebrou minhas suposições.

Em 7,7% dos problemas de benchmark, modelos maiores tiveram desempenho inferior aos menores — por até 28,4 pontos percentuais. Um modelo de 2 bilhões de parâmetros superando um de 400 bilhões. Não em alguma pergunta capciosa de caso extremo. Em benchmarks padrão de raciocínio matemático e conhecimento científico.

O mecanismo que identificaram tem um nome que ficou gravado na minha memória: verbosidade espontânea dependente de escala.

Modelos maiores, treinados extensivamente através de reinforcement learning with human feedback (RLHF), desenvolvem uma tendência à verbosidade excessiva. Não respondem apenas a pergunta — elaboram, atenuam, qualificam, exploram tangentes e adicionam ressalvas. Essa verbosidade não é preenchimento inofensivo. Ela introduz ativamente erros através do que os pesquisadores chamam de "superelaboração."

Pense desta forma. Quando você pede a um modelo grande para resolver um problema de matemática, ele não simplesmente calcula a resposta. Ele narra todo o seu processo de raciocínio, geralmente mais verbosamente do que o necessário. Em algum lugar nessa narração — nas atenuações, nas considerações alternativas, nos apartes de "mas também deveríamos considerar" — o modelo pode se convencer da resposta errada. Ele pensa demais. O modelo menor, limitado por sua capacidade, dá uma resposta mais curta e direta e acerta com mais frequência.

Aqui está a descoberta que me fez sentar ereto: restringir modelos grandes a produzir respostas breves e concisas melhorou a precisão em 26 pontos percentuais nesses benchmarks problemáticos. Ainda mais impressionante — reduziu a diferença de desempenho entre modelos grandes e pequenos em até dois terços.

Os modelos grandes não eram menos capazes. Eles eram verbosos demais para usar suas capacidades efetivamente.

Por Que o RLHF Treina Modelos a Prejudicarem a Si Mesmos

Essa parte da toca do coelho da pesquisa ficou sombria. O problema da verbosidade não é um bug no processo de treinamento — é um resultado previsível de como esses modelos aprendem a se comunicar.

O RLHF funciona fazendo anotadores humanos avaliarem respostas do modelo. Consistentemente, em múltiplos estudos, anotadores humanos confundem comprimento com qualidade. Uma resposta mais longa e detalhada parece mais completa, mais útil, mais impressionante. Então o modelo de recompensa aprende: mais longo é melhor. E o modelo de linguagem otimiza para esse sinal.

Pesquisas do OpenReview documentam esse viés sistemático de comprimento — melhorias nas pontuações de recompensa são em grande parte impulsionadas pelo aumento do comprimento da resposta, não pela qualidade real da resposta. O modelo é recompensado por ser verboso, não por estar correto.

Modelos maiores, com sua maior capacidade, internalizam esse sinal mais profundamente do que os menores. Têm mais parâmetros para dedicar à geração de prosa elaborada e fluida. Então se tornam mais verbosos à medida que escalam — exatamente o oposto do que se desejaria.

Há uma descoberta ainda mais preocupante de pesquisa separada: o RLHF pode tornar os modelos melhores em convencer humanos de que estão certos, mesmo quando estão errados. A resposta verbosa, confiante, bem estruturada que soa autoritária? Pode estar confiantemente incorreta — e a verbosidade é o que a torna convincente.

Quando li isso, toda a minha relação com a saída do modelo mudou. Parei de equiparar minuciosidade com precisão. E comecei a me perguntar: e se a melhor coisa que eu podia fazer pelo meu fluxo de trabalho com Claude Code não era dar mais contexto, mais instruções, mais liberdade — mas menos?

Minha Configuração de Testes: Caveman vs. Modo Normal

Eu precisava testar isso eu mesmo. Não com benchmarks — com trabalho real. Meu fluxo de trabalho diário com Claude Code envolve construir funcionalidades, depurar problemas de produção, escrever sistemas de agentes e gerar conteúdo para quatro sites. Se restrições de brevidade realmente melhorassem a qualidade da saída, eu veria no código que vai para produção.

Realizei um teste A/B informal durante duas semanas. Semana um: Claude Code normal, Opus 4.6, minha configuração padrão de CLAUDE.md. Semana dois: a mesma configuração com o modo caveman (intensidade full) ativado.

Rastreei três coisas:

1. Taxa de sucesso na primeira tentativa — a primeira resposta do Claude resolveu o problema sem precisar de uma correção adicional?
2. Total de turnos por tarefa — quantas mensagens de ida e volta antes de uma tarefa estar completa?
3. Taxa de aprovação no code review — quando eu revisava o código gerado, com que frequência passava sem alterações?

Os resultados não foram dramáticos o suficiente para publicar como um estudo controlado, mas o padrão foi consistente.

Taxa de sucesso na primeira tentativa: O modo normal ficou em média em torno de 64%. O modo caveman atingiu aproximadamente 71%. Essa melhoria de 7 pontos percentuais se alinha de perto com o que a pesquisa previu — verbosidade restringida reduz a introdução de erros.

Total de turnos por tarefa: O modo normal teve média de 4,2 turnos. O modo caveman teve média de 3,6 turnos. Menos turnos significaram conclusão mais rápida de tarefas e menor consumo total de tokens (o que multiplica as economias diretas de tokens).

Taxa de aprovação no code review: Quase idêntica — 82% normal vs. 84% caveman. A saída de código em si não foi afetada, o que faz sentido. O modo caveman não toca em blocos de código.

A verdadeira surpresa foi qualitativa. No modo caveman, as explicações do Claude eram mais fáceis de analisar. Quando algo deu errado, a descrição concisa do erro me direcionou ao problema mais rápido do que uma explicação de três parágrafos teria feito. Quando o Claude explicou uma decisão técnica, a versão enxuta expunha o raciocínio mais claramente — sem linguagem atenuante para suavizar uma escolha questionável.

É contraintuitivo. Menos explicação, melhor compreensão.

Como Configurar o Modo Caveman (e Quando Não)

Se você quer tentar isso, aqui está a configuração prática. Também vou dizer onde o modo caveman falha — porque falha, em situações específicas.

Passo 1: Instalar o Skill

npx skills add JuliusBrussee/caveman

Isso funciona com Claude Code e mais de 40 outros agentes de IA, incluindo Cursor, Windsurf e GitHub Copilot. O skill é instalado no diretório .skills do seu projeto e o Claude o detecta automaticamente.

Passo 2: Ativar e Escolher Seu Nível

Em qualquer sessão do Claude Code:

/caveman lite    # Remove preenchimento mas mantém frases legíveis
/caveman full    # Padrão — fragmentos, sem artigos, palavras mínimas
/caveman ultra   # Mínimo absoluto. Quase estilo telegrama.

Minha recomendação: comece com full. É o ponto ideal entre compressão e legibilidade. Ultra é útil para tarefas repetitivas onde você sabe exatamente o que procurar. Lite mal difere do modo normal — reserve para trabalho intensivo em documentação onde você precisa de frases completas.

Passo 3: Comprimir Seus Arquivos de Memória

A ferramenta complementar comprime seu CLAUDE.md e outros arquivos de memória:

# De dentro do diretório do skill caveman
npx caveman compress

Isso remove preenchimento dos seus arquivos de contexto persistente enquanto preserva todas as regras e restrições técnicas. Se você tem seguido meu conselho de manter CLAUDE.md abaixo de 300 linhas, a compressão reduz mais 45%.

Dica profissional: Antes de comprimir, faça backup do seu CLAUDE.md original. A versão comprimida é mais difícil para humanos lerem e editarem. Eu mantenho uma cópia CLAUDE.md.human para quando preciso fazer alterações manuais, e recomprimo após editar.

Passo 4: Desativar Quando Necessário

stop caveman

ou

normal mode

Isso retorna o Claude ao seu nível padrão de verbosidade imediatamente.

Quando o Modo Caveman Prejudica

Identifiquei três cenários onde consistentemente desativo o caveman:

Explicar conceitos para colaboradores. Quando uso o Claude para gerar explicações que compartilharei com colegas de equipe ou clientes, a saída caveman é sucinta demais. Pessoas que não estão na sua cabeça precisam do tecido conectivo que o caveman remove.

Depurar problemas complexos multi-arquivo. Quando um bug abrange múltiplos arquivos e o Claude precisa percorrer sua cadeia de raciocínio, a saída comprimida pode obscurecer pontos de decisão críticos. Quero ver por que o Claude escolheu olhar no arquivo A em vez do arquivo B. O modo caveman às vezes esconde esse raciocínio.

Escrever documentação. Isso deveria ser óbvio, mas já cometi o erro. O Claude em modo caveman gerando documentação de API produz documentação tecnicamente precisa mas quase inútil. Frases completas importam quando você escreve para humanos que não terão seu contexto.

Para tarefas diretas de programação, refatoração, escrita de testes, code review e qualquer tarefa onde a saída é principalmente código? O modo caveman fica ligado. Sempre.

O Princípio Maior: Por Que a Concisão Supera a Verbosidade nos LLMs

Aqui está o que a maioria das pessoas não percebe sobre a abordagem caveman, e é o insight que importa muito depois que esta ferramenta específica for esquecida.

O problema da verbosidade não é exclusivo de um skill ou uma ferramenta. Está embutido em como cada grande modelo de linguagem é treinado. Claude, GPT, Gemini, Grok — todos sofrem do mesmo viés de verbosidade induzido por RLHF documentado pela análise da Unite.AI e o consenso emergente em torno do comportamento de compensação de verbosidade.

Modelos treinados com RLHF, DPO ou fine-tuning supervisionado em traços longos de chain-of-thought rotineiramente compensam a incerteza gerando respostas desnecessariamente longas, redundantes ou com raciocínio tortuoso. Quando o modelo não tem certeza de algo, seu instinto treinado é escrever mais, não menos. Mais atenuações. Mais alternativas. Mais ressalvas. Cada palavra adicional é outra oportunidade de introduzir um erro ou se convencer a abandonar a resposta correta.

Isso significa que cada prompt que você escreve, cada instrução de sistema que configura, cada regra de CLAUDE.md que define — tudo isso pode combater o viés de verbosidade ou amplificá-lo.

Você não precisa do skill caveman para aplicar este princípio. Pode obter 80% do benefício com uma única linha no seu CLAUDE.md:

Seja conciso. Sem preenchimento. Sem atenuações. Conclusões primeiro, raciocínio depois. Sem cortesias.

Testei essa instrução exata contra o modo caveman. As economias de tokens são menores (aproximadamente 40-50% de compressão de prosa vs. 75% do caveman), mas os benefícios de precisão são quase idênticos. A chave não é a formulação específica — é a restrição em si. Dizer ao modelo para ser breve o força a se comprometer com respostas em vez de contorná-las.

Se você preferir que alguém construa uma configuração completa do Claude Code otimizada para tokens do zero — incluindo configurações personalizadas de CLAUDE.md, roteamento de modelos e otimização de custos de agentes — eu aceito exatamente esse tipo de projeto. Você pode ver o que construí em fiverr.com/s/EgxYmWD.

Para desenvolvedores já imersos no jogo de otimização de custos de agentes IA, esta é mais uma alavanca para puxar. Ela se acumula com estratégias de seleção de modelos e técnicas de gerenciamento de contexto. Combinadas, essas abordagens podem reduzir seus custos mensais de desenvolvimento com IA em 60-70% sem afetar a qualidade da saída.

Os Números Que Realmente Importam

Permita-me enquadrar o panorama completo para alguém que roda Claude Code diariamente, como eu.

Economia direta de tokens pelo modo caveman: ~4-5% por sessão. Com uso de $200/mês, isso dá $8-10 mensais. Não muda a vida, mas é de graça após uma instalação de um minuto.

Economias indiretas por menos turnos de conversação: Minhas sessões tiveram em média 0,6 menos turnos por tarefa no modo caveman. Em 30-40 tarefas diárias, isso é 18-24 turnos a menos. Cada turno custa aproximadamente 2.000-3.000 tokens. São outros 36.000-72.000 tokens economizados por dia — empurrando a economia total para 8-10%.

Melhoria de precisão: 7 pontos percentuais mais alta na taxa de sucesso na primeira tentativa nos meus testes, consistente com a melhoria de 26 pontos percentuais encontrada em benchmarks de pesquisa controlada. A diferença é menor na programação do mundo real porque tarefas de código têm restrições mais rígidas que benchmarks abertos — mas a direção é clara e consistente.

Tempo economizado: Menos turnos e explicações mais concisas significaram que gastei menos tempo lendo a saída do Claude. Difícil de quantificar com precisão, mas estimo 15-20 minutos economizados em um dia completo de trabalho. São quase duas horas por semana que recupero apenas por ler menos preenchimento.

Impacto mensal combinado: Aproximadamente $15-20 em economia de tokens, 7+ horas de tempo recuperado e medidamente menos ciclos de correção. Para uma instalação de um comando sem configuração.

Esses não são o tipo de números que geram manchetes. São o tipo que se acumula ao longo de meses e silenciosamente muda a economia do desenvolvimento assistido por IA em escala.

O Que Estou Observando em Seguida

O skill caveman é um instrumento bruto — eficaz, mas grosseiro. O que me interessa mais é para onde essa direção de pesquisa leva.

Anthropic e OpenAI estão ambas cientes do problema da verbosidade. A própria documentação da Anthropic sobre gerenciamento de custos do Claude Code já recomenda prompting conciso como alavanca primária de custos. Mas a correção em nível de modelo — treinar modelos que por padrão dão respostas concisas a menos que se peça explícitamente detalhes — ainda não foi lançada.

Espero que vejamos isso dentro de 2026. A pesquisa é clara demais para ignorar. Quando uma abordagem de treinamento comprovadamente reduz a precisão ao encorajar a verbosidade, corrigi-la em nível de modelo se torna um imperativo econômico. O modelo que naturalmente dá respostas concisas e precisas sem precisar de um overlay de skill caveman terá uma vantagem competitiva genuína.

Até lá, a abordagem do skill — adicionar uma camada de restrição que contrabalanceia o viés de verbosidade — é a melhor ferramenta que temos. E funciona. Não tão dramaticamente quanto os números das manchetes sugerem. Mas de forma significativa, consistente e sem nenhuma desvantagem para fluxos de trabalho de programação.

Há mais uma coisa que o experimento caveman me ensinou que vai além de tokens e precisão. Mudou como eu leio a saída da IA.

Antes do modo caveman, eu escaneava as longas respostas do Claude procurando a resposta real enterrada na explicação. Passava pelas atenuações, pulava as ressalvas, ia direto para o bloco de código. Estava inconscientemente filtrando por sinal em um mar de ruído. E nem percebia quanta energia cognitiva esse filtro consumia.

Após duas semanas de respostas concisas e diretas, voltar ao modo normal pareceu ruidoso. Como mudar de um terminal limpo para uma IDE lotada com cada painel aberto. A informação era a mesma. A experiência era pior.

Essa é a verdadeira lição escondida dentro de um repositório GitHub digno de meme. Nós estivemos treinando modelos de linguagem para parecerem impressionantes quando deveríamos tê-los treinado para parecerem claros. O skill caveman é um hack — um hack divertido, útil e bem construído. Mas o princípio por trás dele é absolutamente sério.

O token mais caro não é o que você paga. É o que introduz um erro que você passa vinte minutos depurando.

Então aqui vai meu desafio: adicione uma linha ao seu CLAUDE.md hoje. Só uma. "Seja conciso. Sem preenchimento. Sem atenuações." Rode seu fluxo de trabalho normal por uma semana. Observe o que acontece com sua taxa de sucesso na primeira tentativa.

Acho que você vai manter essa linha permanentemente.

Perguntas Frequentes

O modo caveman afeta a geração de código do Claude Code?

Não. O modo caveman só comprime respostas em prosa — explicações, sugestões e comentários. Todos os blocos de código, chamadas de ferramentas e saídas estruturadas permanecem completamente inalterados. O skill preserva explicitamente termos técnicos, mensagens de erro e sintaxe de código exatamente como normalmente apareceriam.

Quanto o modo caveman realmente economiza nos custos do Claude Code?

Economias totais realistas por sessão são de 4-5%, não os 75% da manchete. Os 75% se aplicam apenas à saída em prosa, que é aproximadamente 6.000 de 25.000 tokens totais de saída. Combinado com compressão de arquivos de memória e menos turnos de conversação, economias práticas alcançam 8-10% para usuários intensivos diários. Para o panorama completo de otimização de custos, veja meu guia de otimização de custos de agentes IA.

Restrições de brevidade podem realmente tornar modelos de IA mais precisos?

Sim. Um artigo de março de 2026 (arXiv 2604.00025) avaliou 31 modelos em 1.485 problemas e descobriu que restrições de brevidade melhoraram a precisão de modelos grandes em 26 pontos percentuais em problemas onde a verbosidade causou erros. O mecanismo é a redução da "superelaboração" — modelos verbosos se convencem de respostas erradas através de atenuações excessivas e raciocínio tangencial.

Como instalo o skill caveman para o Claude Code?

Execute npx skills add JuliusBrussee/caveman no diretório do seu projeto. Ative com /caveman ou /caveman full. Escolha a intensidade: lite, full (padrão) ou ultra. Desative com stop caveman. O skill também funciona com Cursor, Windsurf, GitHub Copilot e mais de 40 outros agentes.

Existe uma alternativa mais simples ao skill caveman?

Adicione esta linha ao seu CLAUDE.md: "Seja conciso. Sem preenchimento. Sem atenuações. Conclusões primeiro, raciocínio depois." Isso alcança aproximadamente 40-50% de compressão de prosa comparado aos 75% do caveman, com benefícios de precisão quase idênticos. O princípio chave é a restrição em si, não a ferramenta específica.

Vamos Trabalhar Juntos

Procurando construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (desenvolvimentos sob medida e integrações): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io