Reglas con paths en Claude Code: cero tokens hasta que el modelo lee un archivo coincidente
Un experimento mide cuánto contexto añade el mismo conjunto de reglas en Claude Code según se pegue inline, se importe o se limite con paths. Solo la última cuesta cero hasta que hace falta.
Un mismo conjunto de reglas de 2.004 palabras para Claude Code cuesta distinto según dónde se guarde. Inline en CLAUDE.md suma 3.330 tokens a la primera petición; traído con @import, 3.442; como archivo en .claude/rules/ sin cabecera, 3.438; y con un campo paths limitado a src/api/**, cero, exactamente cero, hasta que el modelo lee un archivo de esa ruta. Entonces aparece, y cuesta 2.987 tokens.
La medición
El experimento se hizo en una sola máquina, con Claude Code v2.1.263 y una única pieza de texto: 40 viñetas numeradas, 12.135 caracteres y 2.004 palabras, deliberadamente anodinas para que el modelo no tuviera nada que hacer salvo responder OK. El prompt:
claude -p "Reply with just OK." --output-format json --max-turns 1
Sumando input_tokens, cache_read_input_tokens y cache_creation_input_tokens del bloque usage, la línea base —un CLAUDE.md de tres líneas sin reglas— daba 20.617 tokens. Las tres primeras colocaciones quedaron a un centenar de tokens entre sí: el texto es el mismo y solo cambia el envoltorio. La cuarta fue byte a byte idéntica a la base.
Eso encaja con lo que dice la documentación de memoria de Claude Code, que el autor cita: los archivos de más de 200 líneas consumen más contexto y pueden reducir la adherencia, los @import ayudan a organizar pero no recortan nada porque se cargan al arrancar, y las reglas con paths solo entran cuando el modelo trabaja con archivos que coinciden con el patrón.
Cuándo se paga
Lo interesante es el segundo experimento. Con la configuración limitada por paths se pidió a Claude que leyera un solo archivo y respondiera una pregunta que únicamente las reglas podían contestar. Leyendo src/api/handler.ts, dentro del patrón, acertó. Leyendo src/ui/button.ts, fuera del patrón, respondió que no lo sabía. En el transcript del primer caso aparece un registro adjunto de tipo nested_memory con el texto íntegro de las reglas justo después del resultado del Read; en el segundo no hay tal registro. Es el mismo canal que usan los CLAUDE.md anidados en subdirectorios.
El coste se ve en los totales: la ejecución coincidente creó 11.597 tokens de caché frente a los 8.610 de la no coincidente. La diferencia, 2.987 tokens, es el conjunto de reglas aterrizando en la segunda petición. Sale algo menos que los 3.330 de la versión inline, presumiblemente porque el adjunto arrastra menos estructura que una sección de CLAUDE.md.
De ahí sale lo práctico: el ahorro existe solo para los turnos anteriores a la primera lectura que coincide, y para sesiones que nunca tocan un archivo del patrón. A partir de ese turno las reglas forman parte de la conversación y ya no se van. El autor cuenta que el repositorio que mantiene tiene un CLAUDE.md de 34KB, capado por un test en 33KB, y un coding.md de 8,9KB con paths para src/, test/, scripts/** y .github/**. Ese archivo cuesta cero tokens hasta la primera lectura de un fuente, y unos 2.500 a partir de ahí. Un turno que solo redacta informes y no abre código no las paga nunca. La cifra es de una máquina y un modelo concretos, y la documentación ya decía lo mismo sin números; lo que faltaba era comprobar que el cero es literal.
