Um plugin com nome de homem das cavernas viralizou no Hacker News — e o motivo é genial

Semana passada, um repositório chamado Caveman apareceu no topo do Hacker News com mais de 500 upvotes. O tagline? “Why use many token when few token do trick” — uma referência óbvia ao Kevin do The Office. Mas por trás da piada, tem um insight técnico que pode cortar seus custos com LLMs pela metade.

O Caveman é um skill para o Claude Code que reformata as respostas da IA eliminando artigos, advérbios desnecessários, frases de cortesia e toda aquela enrolação que a gente já se acostumou a ignorar. O resultado? 75% menos tokens na saída, sem perder nada de conteúdo técnico.

Eu confesso que quando vi o nome achei que era meme. Abri o repo esperando uma piada elaborada. Mas aí rodei no meu projeto e vi o antes e depois — e percebi que a gente aceita uma quantidade absurda de lixo linguístico nas respostas de LLM sem nem questionar.

O problema que ninguém fala em voz alta

Vamos fazer uma conta rápida. Se você usa Claude, GPT-4 ou qualquer modelo de fronteira via API, cada resposta verbosa custa dinheiro. O GPT-4o cobra $15 por milhão de tokens de saída. O Claude 3.5 Sonnet, $15 também. Se sua aplicação gera 10 mil respostas por dia com uma média de 500 tokens cada, são 5 milhões de tokens — $75 por dia só em output.

Agora imagina cortar isso para 125 tokens por resposta. Mesma informação, menos gordura. Seus $75 viram $18,75. Em um mês, a diferença passa de $2.000.

E não é só custo. Token a mais significa latência a mais. Cada token que o modelo gera é um passo sequencial no processo de inferência. Menos tokens = resposta mais rápida. O Caveman reporta respostas 3x mais rápidas em média.

A pergunta incômoda: por que estamos pagando para a IA ser educada?

Como o Caveman funciona na prática

A mecânica é surpreendentemente simples. O Caveman não comprime prompts — ele atua na saída do modelo. É um skill que injeta instruções no system prompt do Claude Code, dizendo basicamente: “responda de forma concisa, elimine artigos, preposições desnecessárias e frases de cortesia.”

Ativa com /caveman ou simplesmente dizendo “talk like caveman”. Desativa com “normal mode”. Pronto.

Veja a diferença real. Pergunta: “Por que meu componente React re-renderiza toda hora?”

Resposta normal (69 tokens):

“I’d be happy to help you understand why your React component is re-rendering frequently. The most common cause is that you’re passing a new object reference as a prop on each render. When you create an inline object in JSX, React sees it as a new reference every time and triggers a re-render. You should wrap it in useMemo to maintain reference stability.”

Resposta Caveman (19 tokens):

“New object ref each render. Inline object prop = new ref = re-render. Wrap useMemo.”

São 19 tokens contra 69. A informação técnica é idêntica. O que sumiu? “I’d be happy to help”, “The most common cause is that”, “You should” — puro ruído linguístico.

O que o Caveman preserva:

• Blocos de código (intactos, com sintaxe correta)
• Terminologia técnica
• Mensagens de erro (citadas exatamente)
• Números e dados concretos
• Commits git e PRs (formato padrão)

O que ele elimina:

• Artigos (a, an, the)
• Cumprimentos (“I’d be happy to help”)
• Hedging (“it might be worth considering”)
• Transições (“Now, let’s move on to…”)
• Resumos redundantes

A ciência por trás: menos palavras, mais precisão

Parece contraintuitivo, mas tem pesquisa mostrando que respostas mais curtas podem ser mais precisas. Um paper de 2026 encontrou que restringir LLMs a respostas breves melhorou a acurácia em benchmarks específicos. A hipótese? Quando o modelo tem que ser conciso, ele é forçado a priorizar a informação mais relevante em vez de diluir a resposta com qualificadores.

Faz sentido quando você pensa como attention mechanisms funcionam. Quanto mais tokens o modelo gera, mais “distante” fica o contexto original. Uma resposta de 500 tokens onde a informação crucial está no token 400 é objetivamente pior do que uma de 50 tokens onde tudo é essencial.

Isso me lembra algo que todo senior dev sabe: código verboso não é código claro. Clareza vem de precisão, não de volume.

Caveman Compression: a versão séria do conceito

Se o Caveman original é um skill para Claude Code (focado no output), o projeto Caveman Compression do @wilpel leva a ideia para o lado do input. É uma biblioteca Python que comprime prompts e contextos antes de enviar ao LLM.

O princípio é elegante: LLMs são excepcionalmente bons em preencher lacunas linguísticas. Se você remove um “the” ou um “however”, o modelo entende perfeitamente o que você quis dizer. Então por que gastar tokens com palavras que o modelo reconstruiria sozinho?

A biblioteca oferece três métodos de compressão:

# Método 1: Via LLM (40-58% de redução)
from caveman_compression import compress_llm
result = compress_llm(text, api_key="sk-...")

# Método 2: Via Masked Language Model (20-30%)
from caveman_compression import compress_mlm
result = compress_mlm(text)  # Usa RoBERTa, roda offline

# Método 3: Via NLP rule-based (15-30%)
from caveman_compression import compress_nlp
result = compress_nlp(text)  # SpaCy, <100ms

Cada método tem seu trade-off:

O mais impressionante? Nos testes automatizados, 13 de 13 fatos foram preservados — zero perda semântica. A compressão é “lossless” no que importa.

Exemplos reais de compressão:

System prompt original (171 tokens):

“You are a helpful AI assistant specialized in software engineering. When answering questions, you should provide detailed explanations that are easy to understand. If the user asks about code, provide working examples with comments explaining each step…”

Comprimido (72 tokens):

“AI assistant. Software engineering specialist. Detailed explanations, easy understand. Code questions: working examples, commented steps…”

58% de redução. E qualquer LLM que receba esse system prompt vai se comportar exatamente da mesma forma.

The Token Company: quando a compressão vira startup

Se o Caveman é um projeto open-source e o Caveman Compression é uma biblioteca, a The Token Company é a versão enterprise do conceito — e a Y Combinator apostou nela no batch W26.

Fundada pelo finlandês Otso Veisterä (que tem 18 anos, diga-se de passagem), a startup oferece uma API de compressão drop-in. Você troca uma linha de código e seus prompts passam por um modelo proprietário chamado bear-1.1 antes de chegar ao LLM.

Os números são convincentes:

• Até 66% de redução de tokens no input
• 100k tokens comprimidos em menos de 100ms
• Custo 3x menor por request
• Num blind test A/B, requests comprimidos tiveram maior preferência dos usuários — e aumentaram compras em 5%

Esse último dado é o mais surpreendente. Não é só mais barato — é melhor. Menos contexto irrelevante significa que o modelo foca no que importa.

# Antes: request direto ao LLM
curl https://api.openai.com/v1/chat/completions \
  -d '{"messages": [{"role": "user", "content": "PROMPT_GIGANTE_AQUI"}]}'

# Depois: mesma request, via Token Company
curl https://api.thetokencompany.com/v1/compress \
  -d '{"text": "PROMPT_GIGANTE_AQUI", "model": "bear-1.1"}'
# Retorna o prompt comprimido → envia ao LLM

5 técnicas que você pode aplicar hoje (sem instalar nada)

Não precisa de plugin nem de startup para reduzir seus tokens. Aqui vão técnicas que eu uso no dia a dia:

1. Peça formato estruturado

Em vez de pedir uma “explicação detalhada”, peça JSON, tabela ou lista com bullet points. Respostas estruturadas são naturalmente mais concisas.

# Ruim (gera 500+ tokens de prosa)
"Explique as diferenças entre REST e GraphQL"

# Bom (gera ~150 tokens organizados)
"Compare REST vs GraphQL. Formato: tabela com colunas
[Critério | REST | GraphQL]. Critérios: performance,
flexibilidade, caching, learning curve, tooling."

2. Defina max_tokens agressivamente

Se você sabe que a resposta deveria caber em 200 tokens, não deixe o modelo gerar 2000. Use max_tokens na API e inclua na instrução: “Responda em no máximo 3 frases.”

3. Comprima o contexto de RAG

Se sua pipeline de RAG injeta 10 documentos no prompt, a maioria deles provavelmente é ruído. Use um reranker (como o Cohere Rerank ou o BGE Reranker) para filtrar para 2-3 documentos mais relevantes antes de mandar ao LLM.

4. Cache semântico

Ferramentas como o Redis Semantic Cache armazenam pares request-response e retornam o cache quando uma query semanticamente similar aparece. Para workloads com padrões repetitivos, AWS reporta economia de 3x a 10x.

5. Prefixe com “Be concise”

Sério. Duas palavras no system prompt — “Be concise” ou “Be terse” — já reduzem o output em 30-40% sem nenhuma perda mensurável de qualidade. É estúpidamente simples e funciona.

Caso real: compressão em pipelines de agentes

Onde a otimização de tokens realmente brilha é em agentes autônomos. Um agente que executa 20 tool calls numa tarefa acumula um contexto enorme — cada chamada adiciona input e output ao histórico. Sem compressão, é comum estourar a context window antes de terminar o trabalho.

Eu já vi pipelines de agentes onde 80% do contexto era log de ferramentas anteriores que o modelo nem precisava mais consultar. Aplicar compressão seletiva — manter os resultados recentes intactos e comprimir os anteriores — é a diferença entre um agente que completa a tarefa e um que trava no meio.

# Exemplo: comprimindo histórico de agente
context_history = agent.get_full_context()

# Mantém as últimas 3 interações intactas
recent = context_history[-3:]
old = context_history[:-3]

# Comprime o histórico antigo
compressed_old = compress_nlp("\n".join(old))

# Reconstrói o contexto otimizado
optimized = compressed_old + "\n".join(recent)
# Resultado: 60% menos tokens, agente continua funcionando

A lógica é parecida com como sistemas operacionais gerenciam memória: dados quentes ficam na RAM, dados frios vão pro disco. Aqui, contexto recente fica em tokens completos, contexto antigo fica comprimido.

O elefante na sala: por que LLMs são tão verbosos?

A verbosidade dos LLMs não é um bug — é consequência direta do treinamento. Modelos são treinados com RLHF (Reinforcement Learning from Human Feedback) onde avaliadores humanos consistentemente preferem respostas mais longas e detalhadas. Isso cria um viés sistemático: o modelo aprende que “mais texto = mais aprovação”.

O problema é que o que funciona numa demo do ChatGPT não funciona num sistema de produção. Quando você tem mil requests por segundo, cada token a mais é custo, latência e potencial de alucinação.

É por isso que projetos como o Caveman são mais do que uma piada. Eles expõem uma ineficiência fundamental na forma como interagimos com LLMs. A gente aceita que a IA “fale bonito” porque é o default — mas ninguém perguntou se precisava ser assim.

O que o mercado está dizendo

O ecossistema de otimização de tokens está explodindo em 2026:

• LLMLingua (Microsoft Research) consegue compressão de até 20x em prompts com perda mínima de performance
• Morph oferece otimização multi-camada: modelo (quantização INT4), sistema (PagedAttention, speculative decoding) e aplicação (compressão de contexto)
• Redis lançou módulos específicos para semantic caching de LLMs
• Databricks publicou um guia de best practices para inferência que dedica uma seção inteira à redução de tokens

Organizações que implementam essas estratégias em conjunto reportam reduções de 60-70% no tamanho do contexto e aumento de 2-3x na capacidade efetiva da context window.

A mensagem é clara: a era de “manda tudo pro modelo e deixa ele resolver” está acabando. Token efficiency é o novo performance engineering.

Pra onde isso vai

Eu aposto que em 12 meses, compressão de tokens vai ser tão padrão quanto CDN é pra web. Ninguém serve imagens sem otimizar — por que estamos servindo prompts sem comprimir?

O Caveman começou como piada. A Token Company virou uma empresa financiada pela YC. O LLMLingua virou paper com centenas de citações. A tendência é clara: quem não otimizar tokens em 2026 vai estar jogando dinheiro fora em 2027.

E se você quer começar hoje, o caminho mais fácil é literalmente instalar um plugin e dizer: “talk like caveman.”

Fonte de inspiração: Caveman — GitHub (546 upvotes no Hacker News)