🧠 Destilação: recuperar o cérebro
Esta é a história que dá alma ao curso. Um modelo bom apareceu por alguns dias — e foi embora. Você nunca terá os pesos dele. Mas tem os logs: cada conversa gravada, turno a turno. E nos logs há comportamento suficiente para reconstruir a disposição — o jeito de trabalhar — sem a mente. Este módulo destila o "cérebro do Fable" de volta: dos arquivos JSONL crus a um guia de comportamento reutilizável.
Conteúdo detalhado
A premissa: sem os pesos, mas com os logs
Por alguns dias, um modelo excepcional esteve disponível. Quem o usou sentiu a diferença — não no que ele sabia, mas em como trabalhava: raciocinava antes de agir, lia antes de mexer, verificava o que mudava. Depois ele saiu de cena. Você nunca terá os pesos que faziam aquilo funcionar. Mas há uma pergunta melhor que "como recupero os pesos?": como recupero a disposição sem eles?
🧠 A ideia em uma frase
Você não tem os pesos do modelo — mas tem os logs. Toda sessão do Claude Code grava um arquivo JSONL com, por turno: timestamp, o prompt do usuário, a resposta do modelo, as chamadas de ferramenta, os resultados e — o detalhe que destrava tudo — o model ID por turno. Há comportamento suficiente ali para reconstruir a disposição do agente.
A grande distinção do módulo: pesos ≠ disposição. Os pesos são a mente, fechada e irrecuperável. A disposição é o jeito de trabalhar — e o jeito de trabalhar deixa rastro observável. Rastro a gente lê.
O que é
Destilação comportamental: o processo de transformar sessões reais de um agente num guia de disposição reutilizável. Você observa o comportamento gravado, nomeia o padrão e o converte em instrução. Não copia a mente — extrai o método. Funciona para qualquer agente cujo log você tenha, não só o Fable.
Por que aprender
Porque é o método para fabricar o método. Todo o resto do curso ensina a ler prompts de laboratório de fora. Este tópico vira a câmera para dentro: você gera os seus próprios dados toda vez que conversa com um agente, e está jogando esse ouro fora. Quem domina a destilação não depende de um modelo continuar disponível — guarda o comportamento dele num arquivo de texto e o aponta para a próxima sessão.
✗ O que se perde com o modelo
- ✗Os pesos — a mente, fechada e irrecuperável
- ✗A densidade de raciocínio intrínseca ao modelo
- ✗O acesso direto ("god mode") àquela cadência
✓ O que se guarda dos logs
- ✓A disposição — a ordem em que ele faz as coisas
- ✓O decision loop explícito, em texto reutilizável
- ✓Números medidos que viram metas para a sua sessão
O log já está acontecendo
Você não precisa começar a coletar dados. A coleta já roda há semanas, em silêncio, no seu disco. Cada conversa boa que você teve com um agente é uma amostra arquivada do comportamento dele. A destilação não é um experimento que você monta do zero — é a leitura de um registro que já existe e que quase ninguém olha.
Achar os JSONL — onde mora o registro
Antes de analisar qualquer coisa, você precisa localizar a fonte. Os logs não estão num servidor distante nem trancados — estão na sua máquina, num diretório previsível. Cada projeto que você tocou com o Claude Code tem a sua própria pasta de sessões, e cada sessão é um arquivo .jsonl com uma linha por evento.
~/.claude/projects/<projeto>/*.jsonl
Uma pasta por projeto; um arquivo por sessão. Cada linha do arquivo é um evento JSON — e dentro do blob de metadados está o ouro: o que você digitou, o que o modelo respondeu, as ferramentas que ele chamou, e o model ID por turno.
🗂️ O que cada turno registra
O model ID por turno é o que torna a destilação possível. Sem ele, você teria um amontoado de conversas misturadas. Com ele, você pode rastrear exatamente quais turnos vieram do agente que quer estudar — e separar o Fable de tudo o que não é Fable.
✓ O sinal que você quer
- ✓Sequência de ferramentas por turno (abre com Bash? grep?)
- ✓Presença de blocos de raciocínio antes da 1ª ação
- ✓Se rodou um check depois de editar
- ✓O model ID, para filtrar o agente-alvo
✗ O ruído que você descarta
- ✗UUIDs, hashes internos, campos de transporte
- ✗Listas de MCP servers e skills repetidas a cada turno
- ✗Conteúdo gigante de resultado de ferramenta (logs dentro do log)
- ✗Tudo o que não diz como o agente decidiu
Confirme o estado antes de processar
Fiel ao próprio método que você está destilando: fundamente-se na realidade primeiro. Liste o diretório, conte os arquivos, veja quais projetos têm sessões antes de pedir qualquer script. Você não quer descobrir no meio da análise que estava apontando para a pasta errada. Ground, então reason — começa aqui.
Reduzir o ruído — o script, não o contexto
Aqui está a decisão técnica que define se a destilação é viável ou um desperdício caro. O JSONL cru é enorme e cheio de metadados inúteis. A tentação do iniciante é colar o arquivo inteiro no contexto e pedir "analise isso". Não faça isso. Você incha a janela, gasta tokens à toa e afoga o sinal no ruído. A jogada certa é processar fora: peça ao próprio Claude Code para escrever um script Python que extraia só os campos úteis.
🐍 A regra: o código processa, o contexto recebe o resumo
O movimento elegante é meta: peça ao agente que escreva o extrator. Não foi a pessoa que abriu o JSONL e copiou campos à mão — foi o Claude Code que gerou um arquivo Python para fazer isso. O script lê os arquivos crus, joga fora o ruído e devolve algo enxuto: cinco campos por turno, ainda meio "blob", mas legível e barato.
Princípio geral, que vale muito além desta tarefa: não jogue dados grandes e crus no contexto. Faça o código reduzir primeiro. O contexto é precioso; gaste-o com o sinal destilado, não com o despejo bruto.
# para cada turno em ~/.claude/projects/<projeto>/*.jsonl
registro = {
"timestamp": turno["timestamp"],
"project": turno["cwd"],
"session": turno["sessionId"],
"model": turno["message"]["model"], # ← a chave do filtro
"user_msg": extrai_texto_usuario(turno),
"assistant_msg": extrai_texto_assistente(turno),
}
# descarta: UUIDs, hashes, lista de MCP/skills, blobs de resultado
Cinco campos. É o suficiente para perfilar comportamento sem afogar o contexto. O arquivo de saída ainda parece um blob, mas agora cada registro cabe na cabeça — e o conjunto inteiro cabe no orçamento.
✗ Jogar o JSONL cru no contexto
- ✗Incha a janela com metadados inúteis
- ✗Custa caro e degrada a atenção do modelo
- ✗O sinal se perde no meio do ruído
- ✗Não escala para dezenas de sessões
✓ Deixar o script processar fora
- ✓O código lê o cru; o contexto recebe o enxuto
- ✓5 campos por turno, baratos de carregar
- ✓Escala para todos os projetos de uma vez
- ✓O agente escreve o extrator — você só pede
A meta-lição
Repare no detalhe poético: você está usando o sucessor do Fable para reconstruir o Fable. O modelo atual escreve o script, roda a análise, monta o guia — e depois passa a ser guiado pelo comportamento do antecessor. A ferramenta de destilação e o objeto destilado convivem na mesma sessão. É reflexivo, e é o que torna a técnica acessível: você não precisa de infra, só de pedir certo.
Filtrar pelo agente-alvo
Os logs reduzidos contêm conversas de vários modelos misturadas — Opus 4.8, 4.6, 4.5, e o Fable. Para perfilar o Fable, você precisa de um conjunto que seja só Fable. É aqui que o model ID por turno paga seu preço: você filtra os registros mantendo apenas os turnos onde model == fable, e descarta todo o resto.
turnos_fable = [
r for r in registros
if "fable" in r["model"]
]
# de dezenas de sessões e milhares de turnos…
# …sobram exatamente os 429 turnos do Fable
Trocar o critério do filtro troca o alvo da destilação. "fable" hoje; amanhã pode ser o próximo modelo que você quiser estudar. O pipeline é o mesmo — muda só a string.
Tudo, misturado
Dezenas de sessões ao longo de uma janela de quatro dias, com respostas de todos os modelos usados no período. Um conjunto rico, mas heterogêneo — não dá para concluir nada sobre um agente específico daqui.
Filtra model == fable
Uma linha de código separa o joio do trigo. Note a intencionalidade prática: o uso do Fable foi front-loaded de propósito — quem sabia que o modelo era poderoso concentrou nele os trabalhos pesados, gerando uma amostra densa justamente do agente que importa.
Sobram 429 turnos puros
Um corpus limpo, homogêneo, mensurável — só Fable. É a base sobre a qual o perfil comportamental do próximo tópico vai ser construído. Não é uma sessão; é o conjunto de respostas do modelo, contadas turno a turno.
A amostra é tão boa quanto o filtro
Se o filtro estiver frouxo (pegar turnos de outro modelo por engano), o perfil mistura comportamentos e a conclusão fica contaminada. Confirme o que sobrou antes de perfilar: conte os turnos, confira que todos os model IDs batem com o alvo. Um corpus impuro produz um guia que descreve um agente que nunca existiu.
Perfilar o comportamento — os números
Com o corpus puro em mãos, você pede a análise: quantitativa e qualitativa. O resultado é o perfil comportamental do Fable 5 ao longo dos 429 turnos — um agente disciplinado, raciocínio-primeiro, autônomo, com amplo alcance dinâmico. O turno típico é compacto; mas, quando autorizado, ele sustenta builds autônomos enormes num único turno. E o melhor: tudo isso vira número, comparável com a linha de base.
📊 O perfil em números — Fable 5, 429 turnos reais
Janela de quatro dias, com comparação na mesma janela contra a baseline que o modelo deveria elevar.
| Hábito | Fable (fonte) | Baseline | Leitura |
|---|---|---|---|
| turnos contendo raciocínio | 97% | 80% | raciocina em quase todo turno |
| raciocina antes da 1ª ação | 84% | 73% | o plano precede a ação |
| reavalia após um resultado | 87% | 80% | o loop observar → decidir |
| lê o arquivo antes da 1ª edição | 48% | 52% | fracos os dois → mirar ~100% |
| roda check real após editar | 23% | 19% | o ponto cego comum → corrigir |
| taxa de erro de ferramenta | 3,3% | 3,0% | baixa; recuperação é metódica |
| abandona um turno após erro | quase nunca | quase nunca | diagnostica, não desiste |
🧭 Os números não são troféus — são metas
As três primeiras linhas (raciocínio, plano-antes, reavaliação) são onde o Fable brilha e bate a baseline com folga — é o coração da disposição. As duas seguintes (ler-antes-de-editar e check-após-editar) são onde ele falha — e a baseline também. Isso não é detalhe: é a instrução mais importante do módulo.
Você não está copiando um herói perfeito. Você está herdando os pontos fortes e mirando explicitamente além dos pontos fracos. O guia que você sintetiza no próximo tópico deve dizer: "raciocine como ele" e "verifique melhor que ele".
Medir torna a disposição auditável
"O Fable raciocinava bem" é uma impressão. "97% dos turnos continham raciocínio, contra 80% da baseline" é um fato verificável e uma meta acionável. Transformar o vago no medível é o que separa elogiar um modelo de reconstruir um modelo. O número é a ponte entre admiração e método.
Sintetizar o guia — o decision loop, apontado
O último passo fecha o ciclo: você pede para o agente comparar o perfil com o seu modelo atual (Opus 4.8) e produzir um guia de disposição — um playbook que destila o comportamento num decision loop explícito. Depois, você aponta a sessão nova para esse guia. O sucessor passa a operar informado pelo método do antecessor. Perdemos o Fable; ficamos com o loop.
GROUND estabeleça o estado real (git, grep, read, run-state)
│
REASON diga objetivo + hipótese + plano antes de agir
│
ACT dê o próximo passo; agrupe o que é independente
│
OBSERVE leia de verdade o que voltou
│
RE-EVALUATE atualize o plano a partir do resultado, não o contrário
│ (repita ACT..RE-EVALUATE até a meta)
VERIFY rode o check real no que você mudou
│
NARRATE relate o que aconteceu, com honestidade
O ciclo interno apertado é ACT → OBSERVE → RE-EVALUATE. Pular o OBSERVE é como bons planos produzem resultados errados. Note os dois últimos passos em ciano: VERIFY e NARRATE são exatamente onde a fonte é fraca — e onde o seu guia deve exigir mais que o Fable fazia.
✗ Sessão vanilla (sem o guia)
- ✗Cada turno parte do zero, sem cadência fixa
- ✗Age antes de fundamentar; pula o observe
- ✗Não herda o que o sucessor já provou que funciona
✓ Sessão apontada ao guia
- ✓Adota o decision loop como instrução permanente
- ✓Fundamenta, raciocina, reavalia — turno após turno
- ✓Funciona "muito melhor que o esperado" na prática
⚠️ Duas ressalvas honestas — não venda o que não entrega
A densidade de raciocínio é em parte intrínseca
Aqueles 97% de raciocínio não se reproduzem 100% só por instrução — parte da cadência é própria do modelo-fonte. Paire o guia com mais orçamento de raciocínio (no Opus 4.8: effortLevel em xhigh/max, e alwaysThinkingEnabled on) em vez de esperar que a prosa feche a lacuna. Disposição é a camada mole; o effort é a garantia dura.
A verificação é fraca na fonte — seja melhor que ela
Check real após editar é fraco no Fable (23%) e na baseline (19%). Esse é o lugar mais claro para você ser melhor que o modelo que imita, não apenas igual. Não destile o ponto cego junto com a virtude: copie o raciocínio do Fable e corrija a verificação dele. Um hook PostToolUse em Edit|Write força o teste que a intenção esquece.
🌉 O guia é a camada de disposição — não a única camada
O guia destilado molda a disposição, e disposição é best-effort por natureza. Por isso ele mora bem num CLAUDE.md (carrega toda sessão) — e não na auto-memory, cujo recall é relevance-gated e pode não disparar a regra no turno certo. Mas o guia sozinho não basta: paire-o com as garantias duras que o harness força de fato — effortLevel para a densidade, hooks PostToolUse para a verificação. É a deixa exata do próximo módulo.
📝 Resumo do Módulo
- ✓A premissa: sem os pesos, mas com os logs — o comportamento gravado basta para reconstruir a disposição
- ✓Achar os JSONL: ~/.claude/projects/<projeto>/*.jsonl — com model ID por turno
- ✓Reduzir o ruído: peça um script Python que extraia 5 campos — nunca jogue o JSONL cru no contexto
- ✓Filtrar o alvo: só os turnos model == fable → sobram 429 turnos puros
- ✓Perfilar: 97% raciocínio · 84% antes da 1ª ação · 87% reavalia · 23% check real
- ✓Sintetizar: o decision loop num guia, apontado à sessão nova — e seja melhor na verificação
➡️ Próximo Módulo
3.6 — ⚙️ Disposição × garantia dura. Você destilou a disposição num guia — mas disposição é best-effort. Agora vamos cravar as garantias que o harness força de fato: effortLevel para a densidade de raciocínio, hooks PostToolUse para a verificação, e onde cada regra realmente deve morar.