TL;DR Nada se manda una sola vez. Todo lo que entra en la conversación se reenvía en cada turno que le queda a la sesión, así que el turno 40 paga también los 39 anteriores. Por eso la longitud de la sesión pesa más que el modelo, y por eso
/clearal cambiar de tarea rinde más que cualquier otro ajuste.
Miras /usage, ves media franja consumida sin haber hecho gran cosa, y el primer sospechoso siempre es el modelo. Casi nunca lo es.
Tu consumo es una multiplicación de dos factores, y solo uno tiene que ver con el modelo:
- Qué precio tiene un token. Qué modelo lo procesa, si entra o si sale, y si estaba cacheado.
- Cuántos tokens mandas. Qué acaba dentro del contexto, cuántos turnos se queda ahí, y cuántos contextos tienes corriendo a la vez.
El primero lo eliges una vez y se te olvida. El segundo crece solo mientras trabajas.
Nada se manda una sola vez
El modelo no recuerda el turno anterior. Cada petición lleva la conversación entera y Claude Code añade lo nuevo al final.
Escribes "arregla el test que falla en utils.test.ts". Eso no es una petición, son cinco:
1 system prompt + CLAUDE.md + tu mensaje → pide leer el test
2 todo lo anterior + el test → pide el fichero bajo test
3 todo lo anterior + el segundo fichero → propone un Edit
4 todo lo anterior + el Edit aplicado → ejecuta npm test
5 todo lo anterior + la salida de los tests → responde y termina
Cinco peticiones para un arreglo pequeño, y las cinco llevaban dentro la conversación completa hasta ese punto. El fichero que leyó en la 2 viaja otra vez en la 3, en la 4 y en la 5. Y en el turno 40, si la sesión llega tan lejos.
La caché es lo que hace esto sostenible: el historial que se reenvía se lee al 10% del precio de entrada. Al 10%, no gratis. Multiplicado por todos los turnos que quedan, deja de ser una cifra pequeña. Qué rompe esa caché y qué no la toca está en prompt caching en Claude Code, y no lo repito aquí.
Lo medí en tres sesiones reales
Claude Code apunta cada petición, con sus contadores de tokens, en el .jsonl de la sesión. Se pueden sumar:
jq -s '[.[] | .message | select(.usage)] | unique_by(.id) | map(.usage) | {
peticiones: length,
nuevo: (map(.input_tokens + .cache_creation_input_tokens) | add),
historial: (map(.cache_read_input_tokens) | add),
salida: (map(.output_tokens) | add)
} | . + {por_token_nuevo: (.historial / .nuevo | floor)}' \
~/.claude/projects/<tu-proyecto>/<sesion>.jsonl
El unique_by(.id) importa: una misma respuesta aparece varias veces en el fichero y sin él cuentas el doble.
Tres sesiones mías de esta semana:
sesión peticiones tokens nuevos historial releído ratio
A, diez días 1.378 5,9 M 357 M 61x
B, un día largo 630 10,5 M 171 M 16x
C, una mañana 87 0,37 M 14,3 M 39x
Por cada token nuevo que le di, releyó entre 16 y 61 de historial. Ese ratio no depende de ningún precio, son tokens contados.
Puesto a precio, con las lecturas de caché al 0.1x, las escrituras al 2x y la salida al 5x, releer el historial fue el 65%, el 39% y el 54% de cada factura. En dos de las tres sesiones costó más que todo lo demás junto: más que los ficheros nuevos, más que la salida del modelo, más que cualquier decisión que tomé sobre qué modelo usar.
El precio de un token
| Tipo de token | Precio | Cuándo lo pagas |
|---|---|---|
| Entrada nueva | 1x | Lo que añades este turno |
| Lectura de caché | 0.1x | El historial, en cada turno |
| Escritura en caché | 1.25x con TTL de 5 minutos, 2x con el de una hora | Una sola vez por token |
| Salida | ~5x | La respuesta, las tool calls y el thinking |
Dos cosas que no son evidentes. La primera: la salida cuesta del orden de cinco veces la entrada, porque se genera token a token y cada uno ocupa la GPU mucho más que leer. Una respuesta de 200 tokens son 200 pasadas del modelo. Ahí está la mitad de por qué el effort level mueve tanto la aguja: el thinking son tokens de salida.
La segunda: la escritura en caché se paga una vez y la lectura se cobra en cada turno posterior. Con suscripción el TTL es de una hora, así que la escritura va a 2x. Es el peaje de entrada de un historial que luego vas a releer cientos de veces al 10%.
Por dónde mirar, en el orden que importa
Anthropic publica su propio ranking de las cuatro cosas que vigilar, ordenadas por lo que cuestan. El orden es lo interesante:
1. Sesiones largas. "Every turn re-sends everything before it, so this is where most of a session's tokens go." La misma curva que hace que Claude empeore cuanto más larga es la sesión, vista desde la factura. Y tener un millón de tokens de ventana no arregla esto, le da más sitio.
2. Demasiado dentro del contexto. Ficheros que no hacían falta, salida verbosa de comandos, restos de la tarea anterior, servidores MCP que no estás usando. Todo eso se reenvía en cada turno y además el modelo tiene que pensar rodeándolo. Parte ya está dentro antes de que escribas nada, y cada feature entra en un momento distinto, los plugins que no usas incluidos. Sobre lo que añades tú actúan las cinco formas de dar contexto, quedarte con cinco MCP y el flag silencioso de los comandos que imprimen de más.
3. Un modelo o un effort por encima de lo que pide la tarea. Multiplica todo lo demás, y las dos opciones se quedan puestas de una sesión para la siguiente. Cuál usar en cada caso.
4. Romper la caché. Cambiar de modelo, de effort o de fast mode a mitad de conversación, o volver cuando ya ha expirado.
Fíjate en dónde ha quedado la caché. Última. La longitud de la sesión pesa más que el modelo y más que romper la caché, y es la más difícil de ver: /usage te dice cuánto llevas consumido, pero ningún comando te dice qué parte de eso fue historial releído. Para saberlo hay que bajar al .jsonl.
El subagente no es solo aislamiento, es economía
Un subagente arranca con su propia ventana: su system prompt, las tools y tu CLAUDE.md, pero no tu conversación. Corre sus turnos y a la sesión principal solo vuelve su respuesta. Lo demás se tira.
La contrapartida es que a veces relee cosas que la sesión principal ya tenía, y paga sus propios turnos mientras lo hace. Para un trabajo pequeño es puro sobrecoste. Compensa cuando el trabajo genera mucha salida que no necesitas conservar: revisar un log, procesar la salida de una suite entera. Lo que te ahorras no es ese turno, son todos los turnos siguientes en los que esa salida ya no viaja.
Si delegas siempre el mismo trabajo, dale su propia definición con model: haiku. Si no, corre con el modelo de tu sesión principal. Y ten presente que la principal solo recibe lo que el subagente decidió contar.
Lo que haces con esto
Antes de empezar la siguiente tarea, /clear en vez de seguir en la sesión que ya tienes abierta. Es un comando, no un ajuste, y según el propio ranking de Anthropic rinde más que cualquier decisión sobre el modelo.
El resto de hábitos, con su receta, están en cómo ahorrar tokens en Claude Code. Este tip es el porqué de aquellos diez.
Documentación oficial: Maximizing the value of your Claude Code sessions · Prompt caching