Ponytail gain: como saber se o Ponytail economizou algo de verdade no seu projeto?

"Ficou mais enxuto" é impressão, não medição

E decidir manter uma camada no seu fluxo por impressão é o jeito mais rápido de carregar peso morto por meses sem perceber

O ponytail é uma camada de regra anti over-engineering pro Claude Code, distribuída como plugin e com o código aberto no GitHub

A ideia é simples de entender: em vez de deixar o agente construir o palácio, a regra empurra ele pro mínimo que resolve

A pergunta prática é outra, e é essa que o post responde: isso paga o que promete no SEU projeto? 🤔

De onde vêm os números que o placar mostra

O comando /ponytail-gain exibe um placar compacto com o impacto medido do ponytail: menos código, menos custo, mais velocidade

Mas se liga nisso, porque é aqui que muita gente se engana: esse placar sai das medianas do benchmark do projeto

É uma exibição pontual, não um modo persistente, e não é um número calculado a partir do seu repositório

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Como o benchmark foi montado:

O benchmark agêntico rodou 12 tarefas de feature num repositório FastAPI + React

Cada célula é uma sessão headless real do Claude Code editando uma base de código semeada, avaliada pelos arquivos que ela deixa

Modelo: Haiku 4.5, com n=4

A baseline é o Claude Code fazendo o trabalho normalmente, sem a skill

O que o README publica como resultado:

• 54% menos código
• 22% menos tokens
• 20% menos custo
• 27% mais rápido
• 100% da segurança mantida

Número bonito, né?

Só que ele é a mediana de OUTRO repositório, com OUTRA stack, com OUTRO modelo e OUTRO conjunto de tarefas

Isso é referência, não previsão do seu caso

Linhas de código, tokens, custo e tempo: o que cada métrica realmente diz

Aqui mora o erro central de quem mede: escolher UMA métrica e declarar vitória

O problema é que elas se movem em direções opostas com uma facilidade absurda

E isso não é teoria

Numa medição independente registrada na issue #121 do repositório, o padrão mais comum foi justamente esse: com o ponytail ligado houve mais exploração, mais chamadas de ferramenta e mais tokens, com custo estimado maior, porém saída mais enxuta em linhas

Ou seja: você pode gastar MAIS pra escrever menos

As exceções registradas foram Claude Opus 4.8 (ligado ficou levemente mais barato e mais rápido) e GPT-5.5 High

Por isso a régua honesta é sempre um par: linhas contra custo

Como montar uma comparação honesta no seu projeto, passo a passo

Bora montar isso na prática, usando só o que dá pra verificar

A lógica é a de qualquer experimento decente: muda UMA coisa por vez e repete

1. Instale o ponytail no Claude Code. São dois comandos digitados dentro do próprio Claude Code: /plugin marketplace add DietrichGebert/ponytail e depois /plugin install ponytail@ponytail. Rode /ponytail-gain só pra ver a referência que o projeto publica, e trate esse placar como ponto de partida da conversa, nunca como resultado seu. O erro comum deste passo: sair contando o número do placar como se fosse economia medida no seu repo
2. Isole as execuções em worktrees git separados. Um worktree com a regra do ponytail ativa, outro sem, alternando apenas o arquivo de regra, exatamente como foi feito na medição independente da issue #121. O erro comum deste passo: rodar os dois lados na mesma pasta, com o repositório já sujo do teste anterior, e comparar um estado que não existe mais
3. Rode a MESMA tarefa dos dois lados e leia o placar da sessão com /cost. No Claude Code, o /cost mostra o custo estimado e o uso de tokens da sessão atual, com quebra por modelo entre input, output, leitura e escrita de cache, além da duração e das linhas de código adicionadas e removidas. É praticamente o painel completo que você precisa, tudo num comando só. A mesma régua vale pra camada de baixo: medir a produtividade com Claude Code também começa por tarefa idêntica dos dois lados. O erro comum deste passo: comparar tarefas diferentes, ou trocar de modelo no meio, e achar que a diferença veio da camada
4. Repita a tarefa mais de uma vez. Sessão de agente varia, e uma execução única não sustenta veredito nenhum. O próprio benchmark do projeto roda com n=4 por célula, e a medição independente da issue #121 fechou com 10 execuções concluídas em junho de 2026. O erro comum deste passo: medir uma vez, ver um corte enorme e sair anunciando isso pro time
5. Se quiser ir mais fundo, reproduza o benchmark do repositório localmente. Dá pra rodar com o promptfoo a partir da pasta benchmarks do projeto. O erro comum deste passo: confundir o resultado do benchmark do projeto com o resultado do seu código, porque a base de código semeada não é a sua

Os comandos, na ordem:

# dentro do Claude Code
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail
/ponytail-gain
/cost

# no terminal, a partir da raiz do projeto ponytail
npx promptfoo eval -c benchmarks/promptfooconfig.yaml

Em que tipo de tarefa o ganho aparece (e onde ele fica perto de zero)

Esse ponto é o que separa quem mede de quem torce

O ganho NÃO é uniforme

No benchmark agêntico o corte é bem maior em tarefas onde o agente costuma super-construir, o caso do date picker, e fica perto de zero quando o código já é mínimo

Faz todo sentido, né? Onde não tem gordura, não tem o que cortar

Então a escolha das tarefas de teste importa MUITO

Pegue duas tarefas representativas do seu backlog real, uma daquelas que sempre viram um componentzão cheio de opção, e outra bem pequena e direta

Se você só medir tarefa pequena, o resultado vai parecer inútil

Se você só medir tarefa grande, o resultado vai parecer milagre

Os comandos que geram evidência qualitativa junto:

O plugin registra 6 comandos: /ponytail, /ponytail-review, /ponytail-audit, /ponytail-debt, /ponytail-gain e /ponytail-help

Três deles ajudam a explicar o número em vez de só olhar pra ele:

• /ponytail-audit varre a árvore inteira do repositório (não o diff) procurando over-engineering, uma linha por achado, ranqueado pelos maiores cortes primeiro, usando as tags delete, stdlib, native, yagni e shrink
• /ponytail-review faz a revisão de over-engineering no nível do diff, ou seja, no que você acabou de mexer
• /ponytail-debt reúne os comentários ponytail deixados no código num ledger de dívida

Junte isso com o /cost e você para de discutir sensação: passa a discutir onde estava a gordura e quanto custou tirar ela

Quando manter a camada e quando ela não se paga

Agora as ressalvas, e elas são importantes

O benchmark original do projeto foi CORRIGIDO depois que um contribuidor apontou a falha

Aquela faixa viral de 80% a 94% menos código vinha de uma baseline conversacional, onde o modelo puro enche a resposta de prosa e de opções

Essa faixa foi oficialmente rotulada como artefato de medição e substituída pelo número agêntico de 54%

Isso, na real, é um ponto A FAVOR do projeto: corrigir o próprio número quando alguém aponta o erro é raro nesse mundo de hype

Mas é também o aviso mais claro possível de que baseline errada gera número lindo e falso

Soma a isso o que a issue #121 achou: custo estimado maior com o ponytail ligado na maioria dos casos

E mais um detalhe curioso da mesma análise: o índice de inicialização do SDK reportava cerca de 36 a 44 skills disponíveis no workspace, mas o stream mostrou apenas 1 a 4 arquivos SKILL.md realmente lidos por execução

Ou seja, o que está disponível e o que é efetivamente lido são coisas bem diferentes

O veredito é de método, não de fé: decida pelo par "linhas x custo" medido no SEU repositório, com a mesma tarefa dos dois lados, e não pelo placar do README

Se a saída ficou bem menor e o custo ficou parecido ou menor, mantém

Se a saída encolheu pouco e o custo subiu de forma consistente, a camada não está se pagando no seu contexto, e tudo bem admitir isso

Conclusão

O /ponytail-gain é uma referência boa pra você entender o que a camada se propõe a fazer, não a prova de que ela funcionou no seu projeto

O próximo passo é bem concreto:

1. rode /ponytail-gain pra ver a referência
2. escolha duas tarefas reais do backlog, uma gorda e uma pequena
3. compare com /cost em worktrees separados, repetindo mais de uma vez
4. só então decida

E vale repetir a medição de tempos em tempos, porque o projeto segue em movimento: a versão publicada nas releases é a v4.8.4 ("lazy in Hermes now"), e a v4.8.3 já tinha passado a injetar o ruleset em subagents por meio de um hook SubagentStart

Coisa que muda o comportamento muda o número, sempre

Medir uma vez e nunca mais é quase tão ruim quanto não medir…

até o próximo post! 😀