8. Economía de tokens — qué entra en el contexto y qué se queda fuera
Los tokens son un recurso finito. Colocación en cuatro capas (inline · automático · bajo demanda · externo), cómo el ahorro eleva la calidad de decisiones, y las herramientas de auditoría que controlan el presupuesto.
Esta es la parte 8 de la serie Alice Way. Las partes Parte 1 a Parte 7 cubrieron dónde, cómo y con quién distribuir la carga de la mente. Este artículo trata del recurso más fundamental del que dependen todas esas decisiones: la context window, es decir, los tokens.
0. La economía de tokens es reducir deliberadamente lo que entra en la mente
La context window del colaborador es finita. No todo cabe. Pero el hecho más importante — lo que entra determina la calidad de la decisión. Lleno de ruido, la señal se debilita. Comprimido a señal, la misma ventana puede llevar una decisión mucho más profunda.
La economía de tokens no es, por tanto, solo reducción de costes. Es la selección deliberada de qué admitir en la mente. Carga automática vs bajo demanda, memoria vs fuera-de-memoria, principal vs Subagent: cada decisión que cubrió la serie converge en un único problema de asignación de recursos.
Este artículo registra la colocación en cuatro capas de esa asignación, cómo el ahorro de tokens se traduce en calidad de decisión, y las herramientas de auditoría que mantienen el contexto acumulado ordenado.
1. Colocación en cuatro capas — canales por los que entran los tokens
La colocación de tokens que encontré tiene cuatro capas.
| Capa | Qué | Cuándo entra | Costo de tokens |
|---|---|---|---|
| L1 inline | Persona · autoridad de decisión · guardas de seguridad | Cada sesión, automático | Siempre (más costoso) |
| L2 carga automática | Primeras N líneas del índice de memoria, CLAUDE.md del proyecto | Cada sesión / al entrar en el directorio | Siempre (condicional) |
| L3 lectura bajo demanda | Cuerpos de memoria, reglas por lenguaje, archivos de código | Cuando el trabajo entra en esa área | Solo en ese trabajo |
| L4 referencia externa | Todo el código base, logs de build, respuestas de API externas | Subagent recibe / solo resumen al principal | El principal ve solo el resumen |
El núcleo: L1·L2 deben ser cortas porque se leen a menudo; L3·L4 pueden ser largas porque se leen raramente. La misma información en la capa incorrecta desperdicia tokens.
| Mala colocación | Resultado |
|---|---|
| L4 → L1 (todo el código en la persona) | Consumo masivo de contexto en cada sesión |
| L1 → L4 (definición de rol en un archivo externo) | El colaborador no sabe su persona en cada sesión |
| L2 → L3 (índice de memoria bajo demanda) | El colaborador no sabe que existe su propia memoria |
| L3 → L2 (todos los cuerpos de memoria cargados automáticamente) | La carga automática del índice pierde su significado |
2. Ahorro de tokens → calidad de decisión — la cadena causal
Por qué el ahorro de tokens es un problema de calidad de decisión, no solo de coste.
2.1 Relación señal-ruido
Supón una context window de 100k. Si persona + memoria + cargas automáticas irrelevantes ocupan 80k, solo quedan 20k para señal de grado-decisión. Reducir las cargas automáticas a 30k en la misma ventana hace crecer el espacio de señal a 70k. La misma decisión se desarrolla con mucha más profundidad.
La calidad de la decisión escala con la relación señal, no con el tamaño del contexto.
2.2 Difusión de atención
El colaborador, como cualquier persona, se vuelve menos preciso sobre qué importa a medida que crece el contexto. Encontrar la línea clave dentro de 100k es menos preciso que dentro de 30k. Eliminar el ruido en sí mismo eleva la calidad de la decisión.
2.3 Latencia del primer token
Menos tokens significan respuesta más rápida. La respuesta más rápida mantiene el flujo del operador intacto. El flujo sin interrupciones también reduce su carga mental. La calidad sube también del lado del operador.
3. Patrones de ahorro en rotación
Patrones que aplico activamente para el ahorro de tokens.
3.1 Índice de memoria limitado a 200 líneas
El índice MEMORY.md se mantiene por debajo de 200 líneas. Más allá de eso cae fuera de la ventana de carga automática, perdiendo su significado. La presión de ese límite de 200 líneas se convierte en sí misma en la motivación para podar.
3.2 No leer directorios completos
Leer un directorio grande de una vez consume tokens. Primero listar con ls, filtrar con grep, luego leer solo los archivos específicos. Integrado en la persona como una guarda de estabilidad.
3.3 Cabecera/rango primero para archivos de más de 500 líneas
Nunca leer un archivo grande de principio a fin. Leer las primeras 100 líneas para la estructura, luego solo el rango necesario. La misma decisión se toma contra 200 líneas de contexto, no 1000.
3.4 Delegar trabajo profundo a Subagents
Búsqueda, revisión, build, test van a fondo en los Subagents; el principal solo ve el resumen. El contexto principal permanece en modo de decisión. (Ver Parte 6 — Delegación multi-agente.)
3.5 Cadencia de poda de memoria
Memoria de proyecto mensualmente, memoria de feedback trimestralmente, memoria de referencia cada medio año. El contexto obsoleto no debe ocupar espacio sin utilidad. La estructura de memoria sobre la que operan estas cadencias se trata en Parte 3 — Sistema de memoria.
3.6 Herramienta de auditoría de tokens
Una herramienta como /token-audit se ejecuta periódicamente. Informa de qué entradas no han sido referenciadas en más de 60 días, qué memorias se han inflado, qué cargas automáticas no se usan. Es la base para las decisiones de poda.
4. Ubicaciones de contexto costosas — dónde podar primero
El coste de tokens varía según la ubicación. Las mismas 100 líneas pueden costar 10 veces más dependiendo de la colocación.
| Ubicación | Costo por línea (relativo) | Prioridad de poda |
|---|---|---|
| Persona (L1) | × cada sesión × cada respuesta | ★★★ máxima |
| Índice de memoria (L2) | × cada sesión | ★★ |
| CLAUDE.md del proyecto (L2) | × cada sesión en ese proyecto | ★★ |
| Cuerpo de memoria (L3) | × solo cuando se lee | ★ |
| Archivo de código (L4) | × solo cuando se lee | (no podar — dividir) |
La persona es la más costosa. Las mismas 100 líneas en la persona se pagan × cada sesión × cada respuesta. Por eso la persona se mantiene compacta y se poda con más frecuencia.
5. Trampas — patrones donde la economía de tokens se descarrila
5.1 Inline "por si acaso"
Añadir una guarda, una política, un ejemplo a la persona porque podría ser útil algún día. Un año después la persona tiene 1000 líneas. → Mantener la regla: "solo se promueve a la persona si se ha activado realmente dos veces."
5.2 Cuerpo de memoria copiado en el índice
Copiar parte de un cuerpo de memoria en el índice a modo de "resumen." El índice se infla. → El índice lleva siempre solo anzuelos de una línea. Los cuerpos permanecen en sus archivos.
5.3 Sin revisión periódica de tokens
Usar el sistema diariamente sin saber a dónde van los tokens. → Programar auditorías de tokens periódicas. Qué cargas automáticas son grandes, qué memorias no se usan.
5.4 Resultados del Subagent absorbidos completos en el principal
El Subagent retorna 1000 líneas y el principal absorbe todo. La razón de usar un Subagent desaparece. → Los resultados del Subagent siempre se dividen en resumen (para el principal) + completo (para archivos o la siguiente llamada al Subagent).
5.5 Alcanzar el límite de contexto
Los tokens llegan al final de la ventana y se activa la compactación automática, o el contexto más antiguo se descarta. La porción descartada podría ser precisamente la que el operador no rastreaba conscientemente. → Mantener siempre conciencia del uso del contexto; al 80% de utilización, hacer limpieza.
6. Economía de tokens acumulada — qué cambia
Cambios desde que empecé a tratar la economía de tokens como una prioridad de primer nivel.
| Ítem | Antes | Después |
|---|---|---|
| Contexto de inicio de sesión | Plano 60–70k | Índice + persona = 15–20k |
| Tokens disponibles para trabajo profundo | 30–40k | 80–85k |
| Frecuencia de compactación de contexto | A menudo | Raramente |
| Calidad de decisión en el mismo trabajo | Promedio | Profundo (menos ruido) |
| Velocidad de respuesta | Promedio | Rápido |
El núcleo está en las últimas dos filas: el mismo trabajo produce una decisión más profunda, y lo produce más rápido. Los ahorros de tokens se traducen directamente en calidad de decisión.
7. Comprimido en un principio
El núcleo del diseño de economía de tokens se resume en una oración.
"Inline solo lo que debe verse en cada sesión; carga automática lo que se ve a menudo; lectura bajo demanda lo que se ve ocasionalmente; externo para lo que casi nunca debería verse. El error costoso es la capa incorrecta."
Cuando esto se cumple, la economía de tokens se convierte en acelerador de la calidad de decisión. Cuando se rompe, el ruido consume el espacio de decisión y el colaborador se confunde sobre qué importa.
El siguiente artículo es el último. Cubre cómo todo esto — persona, memoria, skills, hooks, Multi-Agent, verificación, tokens — arranca y concluye realmente cada día: Parte 9 — Protocolos de sesión.