🍔 El problema: logs pesados
Abre una sesión JSONL real y lo primero que salta a la vista es el peso. La mayor parte no es conversación:
es tool_result con la salida repetida en el contexto, volcados de archivos completos,
salida de comandos y adjuntos en base64. Cargar los datos sin procesar en el contexto para analizarlos es un desperdicio puro: pagas tokens por bytes opacos.
⚖️ De dónde viene el peso
- •
tool_result— la salida de Read/Bash/Grep se reproduce completa en el log. - •Volcados de archivos: el contenido completo de cada archivo abierto.
- •Salida del comando: stdout/stderr de todo lo que se ejecutó.
- •Adjuntos — imágenes/archivos en
base64(megabytes por línea).
{"type":"user","message":{"content":[{"type":"tool_result",
"content":"…3.412 linhas do arquivo inteiro ecoadas aqui…"}]}}
{"type":"user","message":{"content":[{"type":"tool_result",
"content":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUg…"}]}}
tool_result reproducido
archivos completos
base64
contexto innecesario
💎 Lo que el debloat MANTIENE
La regla de debloat es quirúrgica: conserva lo que revela el comportamiento y descarta lo que solo ocupa espacio. Lo que queda es exactamente el oro: tus prompts, el texto del asistente, el modelo que escribió cada turno, una línea concisa por llamada a herramienta, y la presencia de razonamiento (marcada con 🧠, ya que el texto viene cifrado en los registros).
✓ Qué SE MANTIENE (el oro)
- ✓Mis prompts de usuario.
- ✓El texto del asistente.
- ✓El modelo (
message.model). - ✓1 línea por
tool_use(nombre + objetivo breve). - ✓LA PRESENCIA de razonamiento (marca 🧠).
✗ Qué NO guarda
- ✗La salida completa de la herramienta.
- ✗El contenido del archivo leído.
- ✗El texto literal del
thinking(viene cifrado).
💡 Por qué solo la PRESENCIA del razonamiento
El bloque thinking llega a los registros vacío/cifrado — solo con la signature. No tienes el pensamiento literal, pero sabes que existió. El debloat lo registra como una marca 🧠: lo suficiente para medir «¿pensó antes de actuar?» sin inventar contenido.
## 👤 humano refatora o parser e roda os testes ## 🤖 claude-fable-5 🧠 Vou ler o arquivo antes de mexer. → Read parser.py → Edit parser.py → Bash pytest -q
🗑️ Lo que el debloat DESCARTA
El otro lado de la regla: todo lo que es peso sin señal desaparece. Los payloads de tool_result,
los blobs de adjuntos y la contabilidad del harness: usage, uuids,
isMeta, sidechain. Nada de esto cambia el ritmo medido, así que puede salir sin culpa.
tool_result (payload)
La salida repetida de la herramienta. El hecho de que la herramienta se ejecutó queda (la línea de tool_use); la salida en sí, no.
Blobs de adjuntos
Imágenes y archivos en base64. Megabytes que no dicen nada sobre cómo trabaja el modelo.
Contabilidad del harness
usage (tokens), uuids, isMeta, sidechain — registro interno, no comportamiento.
🔎 La prueba mental
Para cada campo, pregúntate: "¿esto cambia la respuesta a '¿el modelo pensó antes? ¿cuántas herramientas usó? ¿en qué orden?'". Si no cambia el ritmo, sobra. Esa pregunta es toda la lógica del debloat_jsonl.py.
payload afuera
blobs en base64
harness
¿cambia el ritmo?
🐍 El script debloat_jsonl.py
La teoría se vuelve práctica con un solo comando. Sin argumentos, el debloat_jsonl.py se ejecuta en el
demo_session.jsonl que vive a su lado, imprime el tamaño antes/después y abre la
transcripción limpia — exactamente el flujo del curso para que compruebes el formato la primera vez.
# roda no demo_session.jsonl (ao lado do script) python debloat_jsonl.py # num arquivo seu, escolhendo a saída python debloat_jsonl.py minha_sessao.jsonl -o limpa.md # sem a marca de raciocínio, sem abrir o editor python debloat_jsonl.py s.jsonl --no-thinking --no-open
🎛️ Los flags
- •
(sem args)— usa eldemo_session.jsonly abre el resultado. - •
-o ARQUIVO— elige dónde guardar la transcripción ligera. - •
--no-thinking— omite la marca 🧠 de razonamiento. - •
--no-open— no intentes abrirlo en el editor (útil en el pipeline).
💡 Consejo práctico
É stdlib pura — sin dependencias que instalar. Empieza con la demo para ver el formato; después apunta a una sesión tuya en ~/.claude/projects/<projeto>/. En automatización, usa siempre --no-open.
demo_session.jsonl
elige la salida
antes/después
stdlib pura
📉 El resultado: ~74% de reducción
La cifra que imprime el script casi siempre sorprende: en una sesión típica, el debloat reduce alrededor de 74% del peso. Lo superfluo sí era la mayor parte del archivo — lo que queda, lo esencial, cabe en un archivo pequeño y legible de principio a fin.
$ python debloat_jsonl.py antes: 1.84 MB depois: 0.48 MB # ~74% menor escrito em: demo_session.clean.md
💡 Qué esperar
El porcentaje exacto varía según cuánta salida de herramientas tenía la sesión: las sesiones con mucha lectura de archivos se reducen aún más. Pero el rango de los ~74% es típica: la señal vive en una pequeña fracción del archivo.
100% (crudo)
~26%
~74%
el oro
🧩 La trampa del schema
Al abrir la transcripción ligera por primera vez, hay un detalle extraño: el el asistente aparece en varios encabezados seguidos. No es un bug. Cada bloque del asistente es una LÍNEA separada en el JSONL, y el debloat preserva el orden — entonces un solo turno de respuesta se convierte en varias entradas. Por eso, exactamente, el análisis (en el próximo módulo) agrupa todo en turno lógico.
## 👤 humano — el prompt## 🤖 claude-fable-5 🧠 — thinking## 🤖 claude-fable-5 — text→ Read / → Edit / → Bash — tool_use## 👤 humano — siguiente prompt → cierra el turno✓ Por qué está bien
- ✓Preserva el orden real de los eventos.
- ✓No inventa límites entre turnos demasiado pronto.
- ✓Deja la agrupación para el análisis (turno lógico).
✗ El error común
- ✗Creer que «5 encabezados = 5 respuestas».
- ✗Contar por encabezado infla los números.
- ✗Medir sin agrupar por prompt humano.
= 1 línea
preservada
= 1 turno
turno lógico
🧪 Resumen del módulo
debloat_jsonl.py se ejecuta en la demo de forma predeterminada — flags -o, --no-thinking, --no-open; solo stdlib.Próximo módulo:
2.2 — Corpus, números y la diferencia entre Fable y Opus