🧭 Escolher o modelo certo pra cada tarefa
O uso mais direto da régua: casar o perfil do modelo com a tarefa. O Sonnet 4.6 pensa antes de agir só 10% das vezes e usa poucas ferramentas (2,23 por turno) — perfeito para o que é rápido, mecânico e barato. Já Opus 4.8 (pensa 54%) e Fable 5 (pensa 85%, testa após editar 41%) brilham no trabalho que exige planejar e fechar o loop.
| Modelo | Perfil (números canônicos) | Melhor uso |
|---|---|---|
| Sonnet 4.6 | pensa 10% · 2,23 ferramentas/turno · enxuto | tarefas rápidas, mecânicas e baratas |
| Opus 4.8 | pensa 54% · testa 2% · 7,96 ferramentas/turno | trabalho que exige planejar antes |
| Fable 5 | pensa 85% · testa 41% · 10,45 ferramentas/turno | trabalho que exige planejar + testar (fechar o loop) |
💡 Exemplo prático
Renomear um campo em 30 arquivos? Sonnet — é mecânico, e gastar Fable nisso é desperdício. Refatorar um módulo com migração de schema e suíte de testes? Fable ou Opus — você QUER que ele planeje e rode o teste. A régua diz qual perfil cabe; Fable não é "econômico": ele faz MAIS ferramentas/turno de propósito.
🩺 Diagnosticar o SEU modelo
A régua não serve só para comparar modelos famosos — ela mede você. Rode-a no seu próprio histórico e veja onde a sua sessão tropeça. Se o seu Opus testa após editar só 2% das vezes, a maior alavanca não é "pensar mais": é fechar o loop. O número aponta o gargalo real, não o que você imagina ser.
Meça, não adivinhe
Rode o medidor nos seus ~/.claude/projects. Olhe pensar-antes, testar-depois e ferramentas/turno — os seus, não os do dataset.
Ataque a alavanca certa
Testar 2% é o teto que mais segura você. Injetar "rode o teste depois de editar" rende muito mais que pedir "pense mais".
💡 Exemplo prático
Você acha que seu agente "não pensa o suficiente". Mede e descobre que ele pensa em 60% — mas só testa em 3%. A foto muda a prescrição: o problema não era reflexão, era não fechar o loop. Diagnóstico antes de remédio.
👥 Onboarding de equipe
O ritmo bom não deveria depender de cada dev lembrar. Você injeta o pensar-antes + testar-depois por default —
via hook SessionStart ou um CLAUDE.md versionado no repo — e
toda sessão da equipe já começa com o playbook ligado. O novato herda o ritmo no primeiro dia, sem treino.
hook SessionStart ou CLAUDE.md no repo
todo dev, desde o dia 1
pensar-antes + testar-depois por default
✓ Com o playbook injetado
- ✓Ritmo padronizado entre todos os devs.
- ✓Versionado no repo: muda uma vez, vale pra todos.
- ✓Não depende de ninguém lembrar do bom hábito.
✗ Sem nada injetado
- ✗Cada dev com um ritmo, qualidade irregular.
- ✗O bom hábito morre quando a pessoa esquece.
- ✗Onboarding vira documento que ninguém lê.
📈 Provar que uma mudança funcionou
"Acho que melhorou" não é evidência. A régua transforma palpite em número: salve um baseline datado ANTES, aplique o playbook, e meça DEPOIS com amostra suficiente. O delta vira prova. Só cuidado com a diluição: se você joga as sessões novas no mesmo balde das antigas, o sinal some — isole as sessões novas.
| Passo | O que fazer | Cuidado |
|---|---|---|
| 1. Antes | baseline datado em lugar durável (não /tmp) | amostra grande o bastante pra ser estável |
| 2. Mudança | aplique o playbook (hook/skill/CLAUDE.md) | mude uma coisa por vez |
| 3. Depois | meça de novo e compare o delta | isole sessões novas — não dilua no histórico |
🔎 Exemplo prático
Baseline de junho: testar-depois em 5%. Você injeta a regra de fechar o loop e roda duas semanas. Mede SÓ as sessões novas: 38%. Aí sim você tem um número para defender — não "parece melhor", mas +33pp medido, no recorte certo.
🌐 Vale além de Fable/Opus
O método não é exclusivo do par Fable/Opus. Funciona com Codex e modelos open-source — basta ter os logs
no formato de eventos (passos com ferramenta, pensamento, edição). A chave é o campo
model: é por ele que você separa quem é quem e mede cada um com a mesma régua.
# o que importa é o formato de eventos + o campo model { "model": "claude-opus-4-8", "type": "tool_use", "name": "Edit" } { "model": "gpt-5-codex", "type": "thinking" } { "model": "qwen-2.5-coder", "type": "tool_use", "name": "Bash" } # mesma régua, agrupando por model: python compare_models.py --a codex --b opus
Codex, open-source
logs em eventos
campo model
a mesma de sempre
💡 Exemplo prático
Quer comparar um modelo local (Qwen Coder) com o Codex no SEU fluxo? Rode os dois nas mesmas tarefas, colete os eventos, agrupe por model e meça pensar-antes / testar-depois. A régua é agnóstica de fornecedor — só precisa do formato.
🛡️ Antídoto contra hype
O uso mais valioso de todos: a régua é antídoto contra hype. Antes de acreditar em qualquer "modelo X é melhor que Y", exija amostra grande. Foi exatamente assim que derrubamos o +45pp: o número saiu de 7 sessões (99% vs 54%) e, em amostra grande do HF (4.892 passos), virou 85% vs 54% (+31pp) — sólido, defensável, sem ilusão.
✗ O que o hype faz
- ✗Conclui de 7 sessões: "+45pp, modelo X arrasa".
- ✗Compara amostras de tamanhos diferentes.
- ✗Confunde presença de "thinking" com qualidade do conteúdo.
✓ O que a régua exige
- ✓Amostra grande dos dois lados antes de crer (4.892 passos).
- ✓Tamanhos equilibrados — capar pelo nº de passos (~950).
- ✓Mede presença, não conteúdo (o raciocínio vem cifrado).
⚠️ A amostra pequena engana nas DUAS direções
Ela inflou o "pensar" (99 → 85) E escondeu o "testar após editar" (o recorte local dava 0%, o real é 41%). Por isso a régua não é só para baixar número inflado — é para descobrir o que a amostra pequena tinha apagado.
🔎 Exemplo prático
Apareceu um post: "modelo Z pensa 99% das vezes!". Você pergunta: quantas sessões? Os dois lados têm a mesma amostra? Se a resposta é "7 sessões", você já sabe — peça a amostra grande antes de mudar qualquer coisa. A régua é o seu filtro de hype.
🧰 Resumo do Módulo
model.Fim da trilha:
Você fechou o ciclo inteiro do Fable Lite: os logs são ouro (T1), a mão na massa extrai o delta (T2), o delta vira playbook injetado (T3), e a prova real mede sem se enganar (T4). A régua não é um truque de comparação — é o seu hábito de exigir número antes de acreditar. Escolha o modelo, diagnostique o seu, padronize a equipe, prove a mudança e fure o hype. O método é seu; rode no seu histórico e itere.