Hasta esta semana, saber cuánto costaba una sesión de Claude Code era fácil; saber por qué costaba eso, bastante menos. La versión 2.1.251 corrige justo esa parte: /cost estrena una línea de caché de prompts por sesión y /usage añade una barra de límite de gasto, y ambos datos quedan además disponibles para los scripts de la línea de estado. Es la primera vez que se puede distinguir de un vistazo entre trabajo real y contexto reprocesado sin motivo.
Llega en el mejor momento posible, dos semanas antes de que el 14 de septiembre entren en vigor los nuevos límites semanales, que para quien viene disfrutando del incremento temporal supondrán trabajar con menos margen del que tiene hoy. Medir antes de recortar deja de ser una recomendación teórica.
Qué te está diciendo la nueva línea de caché
La línea que aparece ahora en /cost desglosa cuatro cosas por sesión: el ratio de aciertos de caché, los fallos, los tokens que ha habido que volver a cachear y si la caché estaba caliente o fría. Para quien no haya mirado nunca este mecanismo de cerca, conviene entender qué hay detrás, porque de ahí sale el ahorro.
Cuando trabajas en un repositorio, buena parte de lo que se envía al modelo en cada turno es idéntico al turno anterior: las instrucciones del proyecto, los archivos que ya están en contexto, el historial de la conversación. La caché de prompts permite reutilizar ese bloque en lugar de procesarlo otra vez, y recuperar contexto cacheado cuesta una fracción de lo que cuesta volver a procesarlo. Mientras el principio de lo que envías no cambie, la caché sigue sirviendo.
El problema es lo fácil que resulta romperla sin darse cuenta. Editar el archivo de instrucciones del proyecto a mitad de sesión invalida todo lo que venía después. Cambiar de modelo, también. Dejar la sesión parada el tiempo suficiente como para que caduque la entrada convierte la siguiente petición en un arranque en frío. Ninguna de esas tres cosas producía hasta ahora ninguna señal visible: simplemente, la sesión salía más cara y nadie sabía por qué.
Un ratio de aciertos bajo en una sesión larga no significa que el trabajo sea caro: significa que estás pagando dos veces por el mismo contexto.
Con el desglose delante, la interpretación es directa. Un ratio de aciertos alto en una sesión larga indica que el contexto se está aprovechando. Un número elevado de tokens recacheados apunta a que algo invalida la caché una y otra vez, y casi siempre es una de las tres causas anteriores. Y una caché sistemáticamente fría en sesiones cortas y repetidas sugiere que el patrón de trabajo —abrir, preguntar, cerrar— está pagando el arranque cada vez.
La barra de límite de gasto en /usage
El segundo añadido es una barra de límite de gasto en /usage, acompañada del campo rate_limits.spend_limit para quien personaliza su línea de estado. Está pensada específicamente para quienes trabajan detrás de una pasarela de aplicaciones de Claude con topes de gasto configurados, un escenario habitual en equipos y en organizaciones que centralizan el acceso.
La utilidad es la de cualquier indicador de consumo puesto donde se toma la decisión: saber que te quedan tres cuartas partes del presupuesto antes de lanzar un trabajo largo cambia lo que decides lanzar. Hasta ahora ese dato vivía en un panel de administración que casi nadie abre a mitad de sesión. En la misma actualización, /usage incorpora además un desglose por bucle con el número de ejecuciones y los tokens consumidos en cada una, que es el nivel de detalle que hacía falta para saber qué parte del trabajo se está comiendo la cuota.
/tasks ya dice qué modelo lleva cada subagente
El tercer cambio es pequeño y probablemente el que más dinero ahorra a quien delega trabajo en subagentes: /tasks muestra ahora el modelo y el nivel de esfuerzo de cada uno. Quien lanza tareas en paralelo sin fijar explícitamente el modelo de cada una descubre aquí, en una sola pantalla, cuántas de ellas están corriendo sobre un modelo más caro del que necesitaban.
Es el clásico gasto que nadie audita porque nunca se ve: un subagente que revisa el formato de unos archivos no necesita el mismo modelo ni el mismo nivel de esfuerzo que otro que refactoriza media base de código, pero si no se declara nada, ambos acaban ejecutándose igual. Ver los dos en la misma lista es lo que empuja a corregirlo.
🔎 Un diagnóstico de diez minutos
Trabaja una mañana normal y ejecuta /cost al terminar. Si los tokens recacheados son altos, revisa si estás editando el archivo de instrucciones del proyecto a mitad de sesión o cambiando de modelo sin necesidad. Después lanza /tasks con tus subagentes habituales en marcha y comprueba cuántos corren con un modelo que no les hace falta. Son las dos fugas más comunes y ninguna de las dos era visible hace una semana.
De la factura a la línea de estado
Que los dos datos se expongan también como objeto prompt_cache y como campo de rate_limits para los scripts de la línea de estado no es un detalle menor. Un dato que hay que ir a buscar con un comando se consulta cuando ya ha pasado algo; un dato que está permanentemente en la barra inferior de la terminal se consulta antes. Quien tenga una línea de estado personalizada puede tener el estado de la caché y el margen de gasto delante todo el rato, y ese cambio de ubicación es lo que convierte una métrica en una costumbre.
La conclusión práctica es sencilla y encaja con el calendario: quedan dos semanas para el nuevo régimen de límites y ahora existen las herramientas para llegar sabiendo dónde se va la cuota. La diferencia entre ajustar con datos y ajustar a ciegas es, en el mejor de los casos, un puñado de horas al mes; en el peor, un mantenimiento presupuestado con un margen que no era el que creías.
