🧠 Destilación: recuperar el cerebro
Esta es la historia que le da alma al curso. Apareció un buen modelo durante algunos días y se fue. Nunca tendrás los pesos de él. Pero tiene los logscada conversación queda grabada, turno a turno. Y en los logs hay suficiente comportamiento para reconstruir la disposición — la forma de trabajar, sin la mente. Este módulo destila de nuevo el «cerebro de Fable»: desde los archivos JSONL sin procesar hasta una guía de comportamiento reutilizable.
Contenido detallado
La premisa: sin los pesos, pero con los logs
Durante algunos días, hubo un modelo excepcional disponible. Quienes lo usaron notaron la diferencia: no en lo que sabía, sino en cómo trabajaba: razonaba antes de actuar, leía antes de modificar, verificaba qué cambiaba. Después salió de escena. Nunca tendrás los pesos que hacían que aquello funcionara. Pero hay una pregunta mejor que "¿cómo recupero los pesos?": ¿cómo recupero la disposición sin ellos?
🧠 La idea en una frase
No tienes los pesos del modelo — pero tienes los logs. Cada sesión de Claude Code registra un archivo JSONL con, por turno: timestamp, el prompt del usuario, la respuesta del modelo, las llamadas a herramientas, los resultados y —el detalle que lo desbloquea todo— el ID del modelo por turnoHay suficiente comportamiento allí para reconstruir la disposición del agente.
La gran distinción del módulo: pesos ≠ disposición. Los pesos son la mente, cerrada e irrecuperable. La disposición es el forma de trabajar — y la forma de trabajar deja un rastro observable. El rastro se puede leer.
Qué es
Destilación del comportamiento: el proceso de convertir sesiones reales de un agente en un guía de disposición reutilizable. Observas el comportamiento registrado, nombras el patrón y lo conviertes en una instrucción. No copias la mente: extraes el método. Funciona para cualquier agente cuyo registro tengas, no solo Fable.
Por qué aprender
Porque es el método para fabricar el método. El resto del curso enseña a leer los prompts de laboratorio desde afuera. Este tema gira la cámara hacia adentro: generas tus propios datos cada vez que conversas con un agente y estás desperdiciando ese oro. Quien domina la destilación no depende de que un modelo siga disponible: guarda su comportamiento en un archivo de texto y lo señala en la siguiente sesión.
✗ Lo que se pierde con el modelo
- ✗Los pesos — la mente, cerrada e irrecuperable
- ✗La densidad de razonamiento intrínseca al modelo
- ✗El acceso directo («god mode») a esa cadencia
✓ Lo que se conserva de los logs
- ✓A disposición — el orden en que hace las cosas
- ✓O bucle de decisión explícito, en texto reutilizable
- ✓Números medidos que se convierten en metas para tu sesión
El log ya se está generando
No necesitas empezar a recopilar datos. La recopilación ya lleva semanas en marcha, en silencio, en tu disco. Cada buena conversación que tuviste con un agente es una muestra archivada de su comportamiento. La destilación no es un experimento que montas desde cero: es la lectura de un registro que ya existe y que casi nadie mira.
Encontrar los JSONL — dónde vive el registro
Antes de analizar cualquier cosa, necesitas localizar la fuente. Los logs no están en un servidor lejano ni bajo llave: están en tu máquina, en un directorio previsible. Cada proyecto en el que trabajaste con Claude Code tiene su propia carpeta de sesiones, y cada sesión es un archivo .jsonl con una línea por evento.
~/.claude/projects/<projeto>/*.jsonl
Una carpeta por proyecto; un archivo por sesión. Cada línea del archivo es un evento JSON — y dentro del blob de metadatos está el oro: lo que escribiste, lo que el el modelo respondió, las herramientas que llamó, y el ID del modelo por turno.
🗂️ Lo que registra cada turno
O ID del modelo por turno es lo que hace posible la destilación. Sin él, tendrías un montón de conversaciones mezcladas. Con él, puedes rastrear exactamente qué turnos provienen del agente que quieres estudiar, y separar Fable de todo lo que no es Fable.
✓ La señal que quieres
- ✓Secuencia de herramientas por turno (¿empieza con Bash? ¿grep?)
- ✓Presencia de bloques de razonamiento antes de la 1.ª acción
- ✓Si ejecutaste una comprobación después de editar
- ✓El model ID, para filtrar el agente objetivo
✗ El ruido que descartas
- ✗UUID, hashes internos, campos de transporte
- ✗Listas de servidores MCP y skills repetidas en cada turno
- ✗Contenido enorme del resultado de una herramienta (registros dentro del registro)
- ✗Todo lo que no dice cómo decidió el agente
Confirma el estado antes de procesar
Fiel al propio método que estás destilando: básate primero en la realidad. Enumera el directorio, cuenta los archivos, mira qué proyectos tienen sesiones antes de pedir cualquier script. No querrás descubrir a mitad del análisis que estabas apuntando a la carpeta equivocada. Primero Ground, luego reason — empieza aquí.
Reducir el ruido: el script, no el contexto
Aquí está la decisión técnica que define si la destilación es viable o un desperdicio costoso. El JSONL sin procesar es enorme y está lleno de metadatos inútiles. La tentación de quien empieza es pegar el archivo entero en el contexto y pedir «analiza esto». No hagas eso. Haces crecer la ventana, gastas tokens en vano y ahogas la señal con ruido. La jugada correcta es procesar fuera: pídele al propio Claude Code que escriba un script de Python que extraiga solo los campos útiles.
🐍 La regla: el código procesa, el contexto recibe el resumen
El movimiento elegante es una meta: pídele al agente que escriba el extractor. No fue la persona quien abrió el JSONL y copió los campos a mano: fue Claude Code quien generó un archivo Python para hacerlo. El script lee los archivos sin procesar, elimina el ruido y devuelve algo conciso: cinco campos por turno, todavía un poco «blob», pero legible y barato.
Principio general, que vale mucho más allá de esta tarea: no vuelques datos grandes y sin procesar en el contextoHaz que el código reduzca primero. El contexto es valioso; úsalo en la señal destilada, no en el volcado bruto.
# para cada turno en ~/.claude/projects/<proyecto>/*.jsonl
registro = {
"timestamp": turno["timestamp"],
"project": turno["cwd"],
"session": turno["sessionId"],
"model": turno["message"]["model"], # ← la clave del filtro
"user_msg": extrai_texto_usuario(turno),
"assistant_msg": extrai_texto_assistente(turno),
}
# descarta: UUID, hashes, lista de MCP/skills, blobs de resultados
Cinco campos. Es suficiente para definir el comportamiento sin ahogar el contexto. El archivo de salida todavía parece un blob, pero ahora cada registro cabe en la cabeza, y el conjunto entero cabe en el presupuesto.
✗ Poner el JSONL sin procesar en el contexto
- ✗Llena la ventana con metadatos inútiles
- ✗Cuesta caro y degrada la atención del modelo
- ✗La señal se pierde en medio del ruido
- ✗No escala a decenas de sesiones
✓ Deja que el script procese por fuera
- ✓El código lee lo crudo; el contexto recibe lo conciso
- ✓5 campos por turno, baratos de cargar
- ✓Escala a todos los proyectos de una vez
- ✓El agente escribe el extractor: tú solo pides
La metalección
Observa el detalle poético: estás usando el sucesor de Fable para reconstruir Fable. El modelo actual escribe el script, ejecuta el análisis, prepara la guía y luego pasa a ser guiado por el comportamiento del predecesor. La herramienta de destilación y el objeto destilado conviven en la misma sesión. Es reflexivo y es lo que hace accesible la técnica: no necesitas infraestructura, solo pedirlo bien.
Filtrar por el agente objetivo
Los logs reducidos contienen conversaciones de varios modelos mezclados — Opus 4.8, 4.6, 4.5 y Fable. Para perfilar Fable, necesitas un conjunto que sea solo Fable. Aquí es donde el model ID por turno justifica su costo: filtras los registros y conservas solo los turnos donde model == fable, y descarta todo lo demás.
turnos_fable = [
r for r in registros
if "fable" in r["model"]
]
# de decenas de sesiones y miles de turnos…
# …quedan exactamente los 429 turnos de Fable
Cambiar el criterio del filtro cambia el objetivo de la destilación. "fable" hoy; mañana puede ser el próximo modelo que quieras estudiar. El pipeline es el mismo: solo cambia la cadena.
Todo mezclado
Decenas de sesiones a lo largo de un período de cuatro días, con respuestas de todos los modelos usados durante el período. Un conjunto amplio, pero heterogéneo: no se puede concluir nada sobre un agente específico a partir de aquí.
Filtra model == fable
Una línea de código separa lo bueno de lo malo. Observa la intencionalidad práctica: el uso de Fable fue priorizado al inicio a propósito: quienes sabían que el modelo era poderoso concentraron en él los trabajos pesados, generando una muestra densa precisamente del agente que importa.
Quedan 429 turnos puros
Un corpus limpio, homogéneo y medible — solo Fable. Es la base sobre la que se construirá el perfil de comportamiento del siguiente tema. No es una sesión; es el conjunto de respuestas del modelo, contadas turno a turno.
La muestra es tan buena como el filtro
Si el filtro es demasiado laxo (toma por error turnos de otro modelo), el perfil mezcla comportamientos y la conclusión queda contaminada. Confirma qué quedó antes de perfilar: cuenta los turnos, comprueba que todos los model IDs coincidan con el objetivo. Un corpus impuro produce una guía que describe un agente que nunca existió.
Perfilar el comportamiento: las cifras
Con el corpus puro en mano, pides el análisis: cuantitativa e cualitativa. El resultado es el perfil de comportamiento de Fable a lo largo de los 429 turnos — un agente disciplinado, que prioriza el razonamiento, autónomo, con amplio rango dinámico. El turno típico es compacto, pero, cuando se autoriza, puede sostener enormes builds autónomos en un solo turno. Y lo mejor: todo esto se convierte en número, comparable con la línea de base.
📊 El perfil en cifras: Fable 5, 429 turnos reales
Ventana de cuatro días, con comparación en la misma ventana frente a la línea base que el modelo debería superar.
| Hábito | Fable (fuente) | Baseline | Lectura |
|---|---|---|---|
| turnos que contienen razonamiento | 97% | 80% | razona en casi todos los turnos |
| razona antes de la 1.ª acción | 84% | 73% | el plan precede a la acción |
| revalúa después de un resultado | 87% | 80% | el ciclo observar → decidir |
| lee el archivo antes de la 1.ª edición | 48% | 52% | ambos débiles → apuntar a ~100% |
| ejecuta verificación real después de editar | 23% | 19% | el punto ciego común → corregir |
| tasa de error de la herramienta | 3,3% | 3,0% | baja; la recuperación es metódica |
| abandona un turno tras un error | casi nunca | casi nunca | diagnostica, no se rinde |
🧭 Los números no son trofeos: son metas
Las tres primeras líneas (razonamiento, plan previo, reevaluación) son donde Fable brilla y supera con creces la línea base: es el corazón de la disposición. Las dos siguientes (leer antes de editar y verificar después de editar) son donde falla — y también la baseline. Esto no es un detalle: es la instrucción más importante del módulo.
No estás copiando a un héroe perfecto. Estás heredando los puntos fuertes e apuntando explícitamente más allá de los puntos débiles. La guía que sintetizas en el siguiente tema debe decir: "razona como él" e "verifica mejor que él".
Medir hace que la disposición sea auditable
"Fable razonaba bien" es una impresión. "El 97% de los turnos contenía razonamiento, frente al 80% de la línea de base" es un hecho verificable y una meta accionable. Transformar lo vago en algo medible es lo que distingue elogiar un modelo de reconstruir un modelo. El número es el puente entre la admiración y el método.
Sintetizar la guía: el decision loop, señalado
El último paso cierra el ciclo: le pides al agente comparar el perfil con tu modelo actual (Opus 4.8) y producir un guía de disposición — un playbook que destila el comportamiento en un bucle de decisión explícito. Después, tú apunta la nueva sesión a esta guía. El sucesor empieza a operar informado por el método del antecesor. Perdimos Fable; nos quedamos con el loop.
GROUND establece el estado real (git, grep, read, run-state)
│
REASON di el objetivo + la hipótesis + el plan antes de actuar
│
ACT da el siguiente paso; agrupa lo que es independiente
│
OBSERVA lee de verdad lo que volvió
│
RE-EVALUATE actualiza el plan a partir del resultado, no al revés
│ (repite ACT..RE-EVALUATE hasta alcanzar la meta)
VERIFY ejecuta el verificación real en lo que cambiaste
│
NARRATE cuenta lo que pasó con honestidad
El ciclo interno ajustado es ACT → OBSERVE → RE-EVALUATE. Saltarse OBSERVE es cómo los buenos planes producen resultados erróneos. Fíjate en los dos últimos pasos en cian: VERIFY e NARRATE son exactamente donde la fuente es débil — y donde tu guía debe exigir más que hacía Fable.
✗ Sesión vanilla (sin la guía)
- ✗Cada turno parte desde cero, sin una cadencia fija
- ✗Actúa antes de fundamentar; se salta el observe
- ✗No hereda lo que el sucesor ya demostró que funciona
✓ Sesión orientada a la guía
- ✓Adopta el decision loop como instrucción permanente
- ✓Fundamenta, razona, reevalúa — turno tras turno
- ✓Funciona «mucho mejor de lo esperado» en la práctica
⚠️ Dos salvedades honestas — no prometas lo que no entregas
La densidad de razonamiento es en parte intrínseca
Ese 97 % de razonamiento no se reproduce al 100 % solo con instrucciones: parte del ritmo es propio del modelo de origen. Combina la guía con un mayor presupuesto de razonamiento (en Opus 4.8: effortLevel en xhigh/máx., e alwaysThinkingEnabled on) en vez de esperar que la prosa cierre la brecha. La disposición es la capa flexible; el effort es la garantía firme.
La verificación es débil en la fuente: supérala
El check real después de editar es débil en Fable (23%) y en la baseline (19%)Este es el lugar más claro para que seas mejor que el modelo que imita, no solo igual. No destiles el punto ciego junto con la virtud: copia el razonamiento de Fable y corrige su verificación. Un hook PostToolUse en Edit|Write fuerza la prueba que la intención pasa por alto.
🌉 La guía es la capa de disposición — no la única capa
La guía destilada moldea la disposición, y la disposición es best-effort por naturaleza. Por eso encaja bien en un CLAUDE.md (se carga en toda sesión) — y no en la auto-memory, cuyo recall está limitado por relevancia y puede no activar la regla en el turno adecuado. Pero la guía por sí sola no basta: combínala con las garantías estrictas que el harness realmente fuerza: effortLevel para la densidad, hooks PostToolUse para la verificación. Es la señal exacta del próximo módulo.
📝 Resumen del Módulo
- ✓La premisa: sin los pesos, pero con los registros — el comportamiento registrado basta para reconstruir la disposición
- ✓Encontrar los JSONL: ~/.claude/projects/<projeto>/*.jsonl — con el model ID por turno
- ✓Reducir el ruido: pide un script Python que extraiga 5 campos; nunca vuelques el JSONL crudo en el contexto
- ✓Filtrar el objetivo: solo los turnos model == fable → quedan 429 turnos puros
- ✓Perfilar: 97% razonamiento · 84% antes de la 1.ª acción · 87% reevalúa · 23% verificación real
- ✓Sintetizar: el ciclo de decisión en una guía, apuntado a la sesión nueva — y verifica mejor
➡️ Siguiente Módulo
3.6 — ⚙️ Disposición × garantía estricta. Destilaste la disposición en una guía — pero la disposición es best-effort. Ahora vamos a establecer las garantías que el harness fuerza de hecho: effortLevel para la densidad de razonamiento, hooks PostToolUse para la verificación, y dónde debe residir realmente cada regla.