El otro día estaba a media mañana con Claude, había hecho cuatro o cinco consultas, nada del otro mundo, y me saltó el aviso de que había agotado el límite de la sesión y que volviera en tres horas y veintidós minutos. Y la primera reacción es siempre la misma: pensar que el plan se ha quedado corto, que están recortando por detrás o que la herramienta ya no rinde como al principio. Me pasó a mí y me lo comentáis constantemente en el canal, así que me senté una tarde a medirlo en serio, con la pantalla delante y apuntando cifras, en lugar de seguir suponiendo. Lo que encontré es que el problema casi nunca está en el límite, sino en lo que estamos enviando sin darnos cuenta cada vez que pulsamos enter.

Te lo resumo en una frase antes de entrar en materia: tú escribes doscientas palabras y se envían doscientas mil. Y esa diferencia no la ves por ningún lado, porque ninguna interfaz te la enseña mientras trabajas.

Los modelos no tienen memoria, y de ahí sale todo lo demás

Esto hay que entenderlo bien, porque las once cosas que cuento más abajo salen todas de aquí. Un modelo de lenguaje no recuerda vuestra conversación anterior. Lo que pasa es que cada vez que envías un mensaje, se vuelve a enviar todo desde arriba: el prompt de sistema, las instrucciones del proyecto, las definiciones de todas las herramientas que tengas conectadas, los mensajes anteriores con sus respuestas, y al final del todo, en último lugar y ocupando una parte ridícula del total, lo que acabas de escribir tú.

Esa parte que ya se había enviado antes y se vuelve a enviar tiene nombre: input reutilizado. Y en un día de trabajo normal es la inmensa mayoría de lo que consumes. Por eso tu mensaje número veinte cuesta muchísimo más que el primero aunque hayas escrito lo mismo, y por eso cuando algo sale mal y le das a reintentar, ese reintento vuelve a pagar todo lo anterior otra vez.

Mientras grababa el vídeo abrí el comando /context en mitad de una sesión de trabajo real, de esas que llevas abiertas desde hace rato, y el reparto era este: system prompt 5.400 tokens, herramientas del sistema 18.700, skills 5.700, y el historial de mensajes 769.000 tokens. Setecientos sesenta y nueve mil. De todo eso, lo que había tecleado yo en ese turno concreto era una línea. Todo lo demás ya lo había enviado antes y lo estaba pagando de nuevo.

Si esto de que el modelo no tiene memoria te suena raro la primera vez que lo oyes, es completamente normal y no es culpa tuya: la IA se explica siempre por encima. Si quieres entender de verdad qué ocurre por debajo, escribí El motor de la Inteligencia Artificial precisamente para eso, empezando desde la aritmética básica y subiendo poco a poco hasta las redes neuronales y la IA generativa actual, sin dar por supuesto que sepas programar ni que tengas base matemática.

El vídeo completo

Lo tienes todo explicado y demostrado en pantalla aquí, con mi terminal real y las cifras de mi propia sesión, por si prefieres verlo antes de seguir leyendo.

Bloque 1: seis hábitos que puedes aplicar hoy sin instalar nada

Estos seis valen igual si trabajas desde el chat del navegador que si vives en la terminal, y no requieren que seas técnico ni que cambies de herramienta.

1. Edita el mensaje, no discutas con la respuesta

Cuando el modelo te entiende mal, o cuando te das cuenta de que se te había olvidado un detalle importante, el instinto es escribir otro mensaje diciendo «no, así no, hazlo de esta otra manera» o añadiendo el dato que faltaba. Y ahí acabas de meter en la conversación tres cosas que vas a arrastrar durante el resto de la sesión: tu prompt malo, la respuesta equivocada y tu corrección. Las tres se reenvían en cada turno que venga después.

La alternativa es editar el mensaje original, corregir la ambigüedad que causó el problema y volver a enviarlo. En Claude Code pulsas escape dos veces, te sitúas sobre el mensaje y lo modificas. En el chat es el lapicerito de editar, que lleva ahí desde siempre y no lo usa casi nadie. La rama mala desaparece y no vuelves a pagarla nunca.

2. Escribe el prompt como si fuera una especificación

Este es el que más iteraciones ahorra, y donde más tokens se pierden sin que nadie se dé cuenta. En lugar de ir soltando preguntas sueltas sobre el mismo material, agrupa todo lo que necesitas de ese contexto en un único prompt y cierra el formato de salida antes de enviarlo. Puedes seguir una estructura tipo contexto, rol, instrucción, formato, objetivo y restricciones, o la que mejor te funcione, pero el principio es el mismo: cada cosa que dejas abierta es una iteración que vas a pagar entera, con todo el historial detrás.

Aquí es donde el spec-driven development deja de ser una metodología para proyectos grandes y se convierte en un hábito de teclado. Cuanto más se parezca tu prompt a un contrato, menos veces vas a tener que volver. Si quieres la versión larga de esta idea, con Spec-Kit y agentes de IA en proyectos reales, va de eso Del vibe coding al Spec-Driven Development.

3. Un chat nuevo por cada tarea

Las conversaciones largas son estupendas mientras sigas con el mismo problema, porque el contexto acumulado te ayuda de verdad. En el momento en que cambias de tarea, ese mismo contexto deja de ayudarte y pasa a cobrarte. La regla es sencilla: cambias de trabajo, cambias de ventana.

Un matiz importante: /clear no te devuelve a cero, porque el sistema y las herramientas se siguen enviando igual. Lo que hace es cortar en seco el arrastre del historial, que es la parte que crece sin freno.

4. Pasa al siguiente paso el resultado, no el proceso

Cuando tienes un flujo de varias fases, investigar y luego redactar, o analizar y después implementar, la tentación es quedarte en el mismo hilo para que «se acuerde de todo». Lo que tiene que viajar al siguiente paso es el artefacto bueno: el informe final, el fichero de especificación, el resumen ya validado. No los borradores que descartaste, ni las fuentes que rechazaste, ni las tres rondas de correcciones que hicieron falta para llegar hasta ahí.

En la práctica lo hago siempre igual. Primero le pido que escriba el traspaso a un fichero, y aquí está el detalle que marca la diferencia: si le pides «hazme un resumen de lo que hemos hablado», te devuelve una narración de la conversación que no le sirve de nada a la ventana siguiente. Lo que quieres es un documento que se entienda solo. Yo se lo pido más o menos así:

Escribe en docs/traspaso.md el resultado de este trabajo, pensado para alguien que NO ha visto esta conversación. Incluye solo: decisiones tomadas y por qué, restricciones que hay que respetar, estado actual y siguiente paso concreto. No incluyas alternativas descartadas, ni el proceso, ni los intentos fallidos. Máximo 40 líneas.

Después lo leo por encima, que son treinta segundos y me ahorra disgustos, abro ventana limpia y le digo que ese fichero es todo el contexto que necesita. La ventana nueva arranca con cuarenta líneas en lugar de con ochenta mil tokens, y sabe todo lo que tiene que saber.

5. Pide solo el output que necesitas

El output se paga dos veces, y esto casi nadie lo tiene presente: se paga cuando se genera, que es la parte cara, y se vuelve a pagar en todos los turnos siguientes, porque pasa a formar parte del historial.

Lo probé delante de la cámara con un cambio pequeño, arreglar el manejo de errores de una función. Pidiéndolo como lo pide todo el mundo, me devolvió el fichero entero reescrito, trescientas líneas de las cuales me interesaban cuatro, y la sesión se fue a diez mil tokens. Repetí exactamente la misma tarea pidiendo solo el diff de las líneas que cambian, sin reescribir el fichero y sin explicación, y se quedó en seis mil setecientos. Mismo resultado en el código, y un historial que a partir de ahí no tiene nada que ver.

Así que pon tú el límite siempre: dame solo el diff, dame la función modificada y no el fichero completo, resúmemelo en cinco líneas, dame el JSON sin explicación.

6. Busca tú, no seas vago

El modelo puede leerse tu proyecto entero, claro que puede, y es comodísimo. También es la forma más rápida que existe de fundir la ventana de contexto, porque cada fichero que abre para descartarlo se queda dentro ocupando sitio durante el resto de la sesión.

Si sabes lo que buscas, búscalo tú antes. Un grep, un rg, el buscador del editor, treinta segundos, y entras diciéndole exactamente dónde está el problema y pasándole solo las cuarenta líneas que importan. El trabajo de localizar es la parte cara en tokens y la barata para ti; el modelo se dedica entonces a lo que hace mejor, que es razonar sobre el fragmento correcto.

Y esto no va solo de programar: si tienes un informe de doscientas páginas y necesitas un dato de la tabla de la página ochenta, búscalo tú y pega esa tabla en lugar de subir el PDF completo.

Bloque 2: herramientas y API

Aquí ya hace falta que trabajes con la terminal, con servidores MCP conectados o llamando directamente a la API.

7. Revisa tus MCP, pero sobre todo revisa tus skills

Este punto lo tenía preparado de otra manera y lo tuve que cambiar mientras montaba el vídeo, y creo que es lo más útil de todo. El consejo que vas a encontrar repetido en todas partes es que desconectes los servidores MCP que no uses, porque cada uno inyecta la descripción de todas sus herramientas en el prompt de sistema y eso viaja en cada turno. Era cierto. Pero mi /context decía esto:

MCP tools · /mcp (loaded on-demand)
└ 44 tools · 0 tokens
Skills · /skills
└ 43 skills · 5.7k tokens

Cuarenta y cuatro herramientas MCP y cero tokens. Claude Code detecta cuándo las definiciones se comerían una parte importante de la ventana y deja de cargarlas todas al arrancar: mantiene un índice ligero con los nombres y carga el esquema completo de cada herramienta solo cuando va a usarla de verdad. A cambio pagas algo de latencia la primera vez que se llama a cada una.

Ahora fíjate en la línea de abajo, que es la que no mira nadie. Las skills sí están dentro, y están dentro siempre, use yo alguna o no, porque no tienen carga diferida: el nombre y la descripción de cada una se inyectan al arrancar la sesión y solo el cuerpo se lee cuando hace falta. Con unas pocas no te arruinas, pero si has ido instalando plugins del marketplace es facilísimo plantarte en decenas de entradas y ahí ya hablamos de un peaje fijo por sesión en algo que probablemente no usas.

Así que la acción concreta son dos comprobaciones de quince segundos antes de ponerte a trabajar. Abre el /context y mira tu línea de MCP: si pone que van bajo demanda y marca cero, olvídate de desconectar servidores, no vas a ahorrar nada; si te marca una cifra alta, entonces sí, quita los que no vayas a usar hoy, y que no te extrañe encontrártela, porque los servidores que van por HTTP en lugar de stdio no siempre se difieren igual. Y después revisa tus skills y borra las que no uses, que esa es la que de verdad puedes accionar hoy mismo.

8. Usa el modelo justo para cada tarea

Entre un modelo y otro hay una diferencia de precio considerable, y no hace falta artillería pesada para formatear un JSON o renombrar variables. Si el trabajo está bien especificado, un modelo barato lo resuelve igual de bien. El problema es que decidir eso a ojo es incómodo, y en la duda todo el mundo tira del modelo más caro, que es exactamente la forma de quedarse sin tokens un martes por la mañana.

Para no ir a ciegas desarrollé SpecJudge, una herramienta open source que lee los artefactos de tu proyecto (specs, tasks, AGENTS.md, CLAUDE.md, lo que tengas) y te dice qué modelo encaja con ese trabajo en relación calidad-precio. El juez corre en local con Ollama, así que tus especificaciones no salen de tu máquina, y cada nivel de exigencia que reporta tiene que citar un fragmento literal de tu propio spec que exista de verdad en el texto: si se inventa la cita, se descarta la evaluación entera. En el vídeo se ve cómo me dice que para esa tarea concreta no necesito Opus ni Fable, que con Sonnet voy sobrado.

Se instala con pip install specjudge, está publicada en PyPI y aprobada en el catálogo de extensiones de spec-kit, así que si trabajas con spec-kit la añades directamente con specify extension add specjudge. Tengo un vídeo entero explicando cómo funciona por dentro y cómo la desarrollé por si quieres el detalle.

9. Prompt caching, solo si escribes tú la llamada

Aclaro esto porque me lo preguntáis mucho: el prompt caching no es un botón que actives en el chat ni en Claude Code. Es una función de la API. En el chat no existe ese control, y Claude Code, que es un cliente que llama a la API, ya se ocupa por dentro. Donde se implementa de verdad es en tu propio código, cuando eres tú quien monta la petición.

Y si estás en ese caso, hoy es mucho más fácil que hace un año, porque ya no hace falta ir marcando bloque a bloque: con la caché automática añades un campo al nivel superior de la petición y el sistema coloca el punto de corte en el último bloque cacheable, moviéndolo hacia delante conforme crece la conversación. La cuenta sale sola, porque leer de caché cuesta el diez por ciento del precio de entrada normal y escribir en ella un veinticinco por ciento más, de modo que si vas a reutilizar ese prefijo aunque sea un par de veces ya te compensa. Dura cinco minutos por defecto y se refresca gratis cada vez que se usa, así que en un flujo activo se mantiene viva sola.

Dos avisos para que no te lleves un chasco: hay un mínimo de tokens por debajo del cual no se cachea nada y no salta ningún error, simplemente lo pagas entero sin enterarte; y el punto de corte tiene que ir en algo que no cambie entre llamadas, porque si lo pones en un bloque que lleva la fecha o el mensaje del usuario, cada petición genera un hash distinto y acabas pagando la escritura siempre sin leer jamás.

10. Compacta tú, antes de que te compacte a ti

Hay veces que no puedes abrir ventana limpia porque estás en mitad de una tarea larga y el agente necesita una decisión tuya. Para eso está la compactación, que resume la conversación y libera sitio para continuar. Claude Code lo hace solo cuando te acercas al límite, y esa pasada automática funciona igual que si la lanzaras tú.

El problema de dejar que salte sola es que salta cuando le toca, no cuando a ti te conviene, y normalmente te pilla en mitad de algo. Así que hazlo tú en un punto de corte natural, cuando acabas de cerrar una parte del trabajo, y sobre todo dile qué te interesa conservar, porque el comando acepta instrucciones. Algo así:

/compact conserva las decisiones de arquitectura y los nombres de los
ficheros que hemos tocado, y olvida los intentos fallidos

Y si puedes, combínalo con el punto 4: pídele primero el fichero de traspaso y compacta después. A partir del momento en que compactas, el modelo trabaja con un resumen aproximado de lo anterior, no con lo anterior; si las decisiones están en un fichero en tu disco, te da igual lo que se pierda por el camino.

Bloque 3: la capa local, para quien quiera ir más allá

Todo lo anterior tiene un techo, y el techo es que actúas dentro de la llamada: cuando tú intervienes, la petición ya está formada. La única manera de bajar de ahí es ponerse antes, con una capa local entre tu entorno y la API.

11. Un intermediario local entre tu entorno y el proveedor

Con un proxy corriendo en tu máquina puedes hacer tres cosas muy concretas. Resolver sin llamada, devolviendo desde una caché local una pregunta que ya se respondió antes, con lo que ahorras el cien por cien de esa petición. Recortar lo que sale, enviando solo los fragmentos útiles del contexto en lugar del bloque entero. Y aplicar límites duros, una regla que bloquee o corte cualquier petición que supere el umbral que tú decidas, para no comerte media cuota en una llamada que se te fue de las manos.

Es lo más avanzado de todo y no es para todo el mundo, pero si trabajas mucho por API es donde está la mayor parte del ahorro. Un aviso importante que enlaza con el punto 7: en cuanto pones un proxy en medio y cambias el endpoint, algunos clientes dejan de diferir las definiciones de herramientas y te las cargan todas, así que mide antes y después y comprueba que el intermediario no te cuesta más de lo que te ahorra.

Si solo te vas a quedar con cinco cosas

Edita en vez de discutir. Abre ventana nueva en cuanto cambies de tarea. Compacta tú, dirigiendo qué se conserva. Revisa tus skills y quita las que no uses. Y comprueba si el modelo que has elegido es realmente el que necesita esa tarea. Con eso solo vas a notar que llegas bastante más lejos antes de volver a ver el aviso del límite.

Y si te apetece, haz una cosa: abre tu /context antes de empezar a trabajar mañana y mira con cuántos tokens arrancas de verdad, antes de escribir una sola palabra. Cuéntamelo en los comentarios del vídeo, que me interesa mucho comparar cifras con las vuestras.

¡Que la IA te acompañe!