Cuando empiezas a usar Claude Code en serio, te encuentras sin falta con el «has alcanzado el límite». Este capítulo trata la forma de trabajar que evita llegar ahí.
Pero el objetivo no es ahorrar por ahorrar. Es lograr que te quede cupo cuando de verdad lo necesitas. Si por apretar el bolsillo el resultado empeora, has perdido el norte, así que al final hablaremos también de dónde trazar la línea.
Por qué crece el consumo
La unidad de consumo es el token. Aquí mucha gente cae en un malentendido: no lo determina solo «la longitud de la instrucción que enviaste».
Todos los archivos que Claude ha ido a leer por su cuenta se cargan en la entrada. Hacerle leer enteros los archivos grandes lo dispara de golpe.
En cada intercambio se envía también todo el historial previo. En una conversación larga sube el precio unitario de cada ida y vuelta.
Seguir corrigiendo hasta que pasen las pruebas consume una ida y vuelta por cada fallo. Es la otra cara de su punto fuerte.
De los tres, sobre el que más margen tienes es el FACTOR 2. Los archivos que se leen los determina el trabajo y el número de intentos lo determina la dificultad, pero la longitud del historial se cambia con la forma de trabajar.
Lo de «si doy instrucciones cortas, sale barato» es un malentendido. Si la instrucción es tan corta que no transmite la intención, Claude explora más, produce una implementación desviada y la rehace. El resultado es que aumentan las idas y venidas y sale caro. Lo barato no es la instrucción corta, sino la instrucción que sale bien a la primera.
No hay un solo tipo de cupo
Ya lo mencionamos en el capítulo 4, pero este es el punto más importante de todo el manejo diario: existen por separado un cupo de ciclo corto y otro de ciclo largo.
El corto se recupera relativamente pronto, así que puedes reanudar el trabajo si esperas. El largo tarda días en recuperarse y, si lo agotas, te quedas sin poder trabajar durante varios días. Cuando te ha pasado eso de «se había recuperado y se ha vuelto a parar enseguida», lo que ocurría es que solo había vuelto el corto y el largo seguía agotado.
El comportamiento del cupo en sí está en cómo resolver el usage limit reached, y el resultado de medir el fenómeno de que el cupo semanal vuelva antes de lo previsto, en la verdad sobre el reinicio anticipado del límite semanal.
Despacha primero el trabajo pesado que tiene fecha de entrega y deja los experimentos exploratorios para los ratos en los que vas holgado de cupo.
Agotar el cupo largo a base de prueba y error y quedarte sin poder trabajar el día del trabajo de verdad. Solo te queda esperar a que se recupere.
El effort: elegir entre velocidad y profundidad
Claude Code tiene un ajuste para elegir cuánto quieres que piense. Si le haces pensar en profundidad, la precisión sube, pero también suben el tiempo y el consumo.
Aquí pierdes tanto si lo dejas «siempre al máximo» como «siempre al mínimo». Lo correcto es cambiarlo según la dificultad de la tarea.
Sustituciones rutinarias, formateo, añadir pruebas, implementaciones cuyo enfoque ya está decidido. Trabajos donde no hay nada que sopesar.
Errores de causa desconocida, decisiones de diseño, cambios cuyo alcance no se ve venir. Trabajos en los que equivocarse cuesta mucho rehacer.
El contenido del ajuste y cuándo usar cada nivel lo tratamos en qué es el effort y cómo alternar entre rápido y profundo. El eje para decidir es compararlo con el coste de rehacer. Si haciéndole pensar en profundidad sale a la primera, resulta más barato que ir ligero y repetirlo tres veces.
Plegar el contexto es también una decisión de coste
En el capítulo 3 lo tratamos desde el ángulo de «hay que plegar porque deja de recordar», pero hay otro motivo para plegar. Como el historial largo se envía cada vez, si sigues trabajando sin plegar, el consumo por ida y vuelta no para de crecer.
Dicho esto, plegar también consume. Si pliegas demasiado, pierdes incluso las premisas que necesitabas y tienes que volver a explicarlas, con lo que sale más caro. Los criterios los recopilamos en ¿conviene ejecutar /compact a mano?.
Cuándo plegar, a modo de guía
bien : justo después de terminar un trabajo
antes de pasar a otro conjunto de archivos
mal : a mitad de un trabajo (se borran las premisas que ibas a usar)
«porque se ha alargado un poco» (no hay criterio)
Las formas en que más fácilmente se desperdicia
La mayor parte del consumo nace de las idas y venidas que no acaban en resultado. Estos son los patrones habituales.
Sin pruebas no puede confirmar su propio «ya está», así que aumentan las vueltas en las que tú lo miras, lo señalas y él lo rehace.
De varios miles de líneas solo hacen falta unas decenas. Pasándole solo el fragmento relevante obtienes el mismo resultado más barato.
Hasta los trabajos que no vienen al caso se acumulan en el mismo historial y acabas arrastrándolos para siempre.
Las convenciones propias del proyecto puedes dejarlas en la memoria persistente del capítulo 6 y ahorrarte escribirlas siempre.
Conocer tu propio consumo
Antes de reducir, lo primero es saber en qué y cuánto estás gastando ahora. Si ahorras a ojo, casi siempre recortas justo donde no surte efecto.
Hay dos cosas que mirar: cuánto se ha hinchado la conversación actual y cuánto cupo queda. Lo primero sirve para decidir si plegar; lo segundo, para decidir si conviene empezar hoy ese trabajo.
El cupo restante. Decide si puedes emprender un trabajo pesado. Si queda poco, cambia a algo ligero o espera a que se recupere.
Cuánto se ha hinchado la conversación. Decide si plegar antes de pasar al siguiente trabajo. A mitad de una tarea no hace falta mirarlo.
Lo importante es no aumentar la frecuencia con la que lo miras. Comprobar lo que queda cada pocos minutos no reduce el consumo. Basta con mirarlo en los cortes del trabajo.
Ahorros que salen por la culata
Hay maneras de ahorrar que producen el efecto contrario. Todas se ven a menudo.
Las premisas no llegan, la implementación se desvía y aumentan las repeticiones. Si hay que recortar algo, que sea el volumen que pegas, no la explicación.
Si pliegas a mitad de un trabajo, se borran hasta las premisas que ibas a usar. Sale caro por lo que cuesta volver a explicarlas.
Si le haces pensar poco ante un error de causa desconocida, probará una y otra vez hipótesis desacertadas. Suben el tiempo y el consumo.
Si toqueteas con todo parado, no puedes comprobar el efecto. Espera a que se recupere y prueba de uno en uno.
Lo que crece cuando lo usa un equipo
Un consumo que no te preocupaba mientras lo usabas tú solo aflora de otra forma al extenderlo al equipo.
Lo más frecuente es el estado en el que cada persona está explicando por su cuenta las mismas premisas. Las convenciones del proyecto, las reglas de nomenclatura, las zonas que no se tocan: si cada cual las escribe cada vez, se duplican tantas veces como personas haya. Lo correcto es dejarlas en la memoria persistente del capítulo 6 y compartirlas en el repositorio.
El otro caso es aquel en el que alguien consume el cupo con un uso exploratorio y otra persona se queda parada en pleno trabajo serio. El comportamiento cambia según se trate del cupo individual o del de la organización, así que confirma al menos ese punto antes de implantarlo.
Rinde más ordenar lo que se comparte que imponer reglas. Decir «hay que ahorrar tokens» solo consigue que cada uno interprete una cosa distinta; en cambio, tener la memoria persistente y las formas de verificar bien puestas en el repositorio reduce de forma natural las idas y venidas de todo el mundo.
En la práctica: siete formas de consumir menos
Van ordenadas de mayor a menor efecto. Con las dos primeras se resuelve la mayor parte.
Cuanto más corto es el historial, más barata sale cada ida y vuelta. Es lo que más rinde.
Si puede comprobarlo y corregirlo por su cuenta, se reducen las vueltas contigo.
Indica el directorio o los archivos concretos. Te ahorras entera la parte de exploración.
El trabajo rutinario no necesita el máximo. En los puntos difíciles, no escatimes.
Si hay algo que explicas cada vez, eso es justo lo que hay que dejar por escrito (capítulo 6).
Justo después de terminar un trabajo. Si pliegas a mitad, tocará volver a explicarlo todo.
Si sacas la investigación a otro contexto, el historial principal no se ensucia (capítulo 6).
La optimización de costes en el conjunto del trabajo con código está recogida, con una mirada más amplia, en el gran manual de optimización de costes del coding con IA.
Dónde trazar la línea para no ahorrar de más
Para terminar, lo que más quería decir en este capítulo: ahorrar no es el objetivo.
Preocuparte tanto por el cupo que acabes afrontando también lo difícil con el ajuste ligero y corrigiendo una y otra vez implementaciones desviadas aumenta a la vez el consumo y el tiempo. Es el caso típico de derrochar creyendo que ahorras.
Decide por «el tamaño de lo que habría que rehacer». Los trabajos que, si se tuercen, se deshacen en unos minutos, ligeros y rápidos. Los trabajos en los que un error te funde medio día, hazle pensar en profundidad desde el principio. El cupo es algo que se reserva para lo segundo.
Y una cosa más: parar cuando estás parado también forma parte del oficio. Antes que toquetear la configuración al alcanzar el límite, esperar a que se recupere y reanudar en plenas condiciones te lleva antes al final.
Resumen
- El consumo lo determinan los archivos leídos, el historial de la conversación y el número de intentos. Lo que puedes mover es sobre todo el historial
- «Instrucción corta igual a barato» es un malentendido. Lo barato es la instrucción que sale bien a la primera
- Hay dos cupos, uno de ciclo corto y otro de ciclo largo. Si agotas el largo, te quedas varios días sin poder trabajar
- Cambia el effort según la dificultad. Tanto el máximo permanente como el mínimo permanente salen perdiendo
- Plegar es a la vez una cuestión de memoria y una cuestión de coste. Pero plegar a mitad sale caro
- Lo que más efecto tiene son dos cosas: separar las conversaciones y dar de antemano una forma de verificar
- Ahorrar no es el objetivo. Decide por el tamaño de lo que habría que rehacer y guarda cupo para los puntos difíciles