En EP.2, usé hooks para reducir lo que Claude lee. Los resultados de tests solo mostraban fallos, los logs de build solo errores.

Decidí medir cuánto había reducido realmente.

Primero medir

Claude Code registra todas las conversaciones como archivos JSONL. Se acumulan por proyecto bajo ~/.claude/projects/, cada entrada contiene el uso de tokens. Construí un script (analyze-tokens.js) que lee estos datos, los cruza con archivos de sesión diarios, contabiliza turnos, cache_read/write/output por separado y lo convierte todo a costo.

Durante la construcción encontré un bug. El hook de registro de sesión referenciaba e.usage, pero la estructura JSONL era e.message.usage. Los tokens no se estaban registrando en los archivos de sesión. El analizador lo evitó leyendo el JSONL directamente.

Aquí está el costo de un día — 27 de marzo.

El 58% del costo total es lectura

ElementoCostoPorcentaje
cache_read$19.2258%
cache_write~$9.6229%
output~$4.3313%
Total$33.17

cache_read es 58%. Más de la mitad del costo de Claude viene de “leer”. En EP.1 escribí “la mayor parte de lo que Claude consume es lectura, no razonamiento.” Viéndolo en números, queda claro.

¿Qué está leyendo?

Rastreé lo que Claude carga cada turno.

ElementoCuándo se cargaTamaño
CLAUDE.md del proyectoCada turno155–214 líneas
CLAUDE.md raízCada turno10 líneas
MEMORY.mdCada turnoMenos de 23 líneas
Historial de conversaciónCada turnoAcumulativo

Hubo un descubrimiento sorprendente. SKILL.md (469 líneas) y los documentos de agentes (1,233 líneas) no se cargan cada turno. Solo se cargan cuando se invoca un skill, solo cuando se ejecuta un agente. Ya es lazy loading.

Lo único que se carga fijo cada turno es CLAUDE.md y MEMORY.md.

Separar CLAUDE.md en rules/

Que CLAUDE.md tenga 155–214 líneas no significa que todo se necesite cada turno. La tabla de rutas de artefactos solo se necesita al escribir artefactos. Las reglas de dominio de juego solo se necesitan para trabajo relacionado con juegos.

Claude Code tiene un directorio .claude/rules/. Crea un archivo ahí con frontmatter paths:, y solo se carga al acceder a esa ruta.

---
paths: tasks/**
---

Tabla de rutas de artefactos, bloques de encabezado comunes, reglas por rol...

Estas reglas solo se cargan al tocar la carpeta tasks/. En conversación general no se cargan.

Lo piloté primero en un proyecto. Moví la sección de artefactos de 45 líneas a artifact-rules.md y la eliminé de CLAUDE.md. Funcionó. Lo apliqué al resto.

ProyectoCLAUDE.md (antes→después)ReducciónArchivos separados
A (e-commerce)155→96 líneas38%artifact-rules.md
B (plataforma educativa)207→140 líneas32%artifact-rules.md, edu-rules.md
C (plataforma de juegos)214→114 líneas47%artifact-rules.md, game-domain.md

C bajó 47%. Al ser plataforma de juegos, las reglas de dominio (46 líneas) se cargaban cada turno. Ahora solo se cargan al tocar archivos relacionados con juegos.

Pero resulta que

Los números no están mal. 32–47% de reducción. Se ve bien.

Pero siendo honesto, esto es “32–47% de 155–214 líneas.” Unos cientos de tokens por turno. La mayor parte de los $19.22 en cache_read no viene de las 200 líneas de CLAUDE.md — viene de la acumulación del historial de conversación. Si corres 20 turnos en una sesión, en el turno 20 los 19 turnos anteriores completos se cargan como cache_read.

Un proyecto consumió más de la mitad del costo del día. Más de 3 veces más caro que los demás. La razón fue simple: 17 turnos en una sola sesión. El cache_read se disparó en los turnos finales.

Por mucho que adelgaces CLAUDE.md, si no cambias cómo se acumula el historial, la mayor parte del cache_read sigue igual. EP.1 redujo la cantidad de agentes. EP.2 usó hooks para cortar output. EP.3 redujo documentos fijos. Todo trabajo significativo, pero la fuga real sigue ahí.

Cortar o continuar, esa es la cuestión

Pasados 20 turnos, iniciar una nueva sesión es más eficiente para cache_read. Pero una nueva sesión significa que cache_write ocurre de nuevo. CLAUDE.md, MEMORY.md, prompt del sistema — todo se escribe desde cero.

Cortas sesiones para reducir cache_read, y cache_write sube. Mantienes sesiones para reducir cache_write, y cache_read sube. De cualquier forma hay costo.

Aún no tengo la respuesta. Alrededor de 20 turnos parece ser el punto de equilibrio, pero depende del tipo de trabajo. Trabajo de diseño con mucha conversación es mejor cortarlo pronto. Codificación continua es mejor mantenerla.

Ese es el verdadero descubrimiento de EP.3. Reduje lo que pude. Lo que queda es el dominio de “cómo usarlo.”

Otros posts de esta serie


Referencias