Quien haya montado un agente con LLM lo habrá vivido tarde o temprano: el prototipo funciona, el flujo parece sólido… y, de repente, llega la factura. No por “pensar demasiado”, sino por algo mucho más prosaico: repetir una y otra vez el mismo texto.
Ese es el problema que ha puesto sobre la mesa un artículo reciente en Medium firmado por Joe Njenga: en agentes con múltiples pasos, gran parte del gasto no proviene de las respuestas del modelo, sino de volver a pagar en cada llamada el mismo system prompt, definiciones de herramientas e instrucciones estáticas, solo porque la API es stateless (no recuerda nada entre peticiones). El autor lo resume con un ejemplo sencillo: si un agente hace 50 turnos y arrastra un system prompt de 10.000 tokens, el sistema “te cobra” 50 veces esa base, aunque no haya cambiado. Njenga sostiene que esto suele pasar desapercibido hasta que se revisa el consumo.
Anthropic ha movido ficha con una solución que, en la práctica, busca eliminar ese sangrado invisible: el prompt caching con modo “automático”, pensado precisamente para conversaciones largas y agentes que crecen con cada turno.
Por qué la API “te cobra lo mismo” aunque no cambie nada
Las APIs de modelos de lenguaje suelen funcionar como una calculadora: cada petición llega completa y se procesa desde cero. Para mantener coherencia, el cliente vuelve a enviar el system prompt, el contexto, los ejemplos, la definición de herramientas y la historia. Eso es “normal” en un diseño sin estado, pero tiene un coste directo: tokens de entrada repetidos.
En agentes, el efecto se multiplica porque el número de llamadas aumenta: planificación, ejecución, verificación, uso de herramientas, reintentos… Y, si además se trabaja con instrucciones muy largas (plantillas, políticas, guías internas), lo que parecía un coste “pequeño por llamada” se convierte en una fuga constante.
Qué es el prompt caching y qué cambia con el modo automático
El prompt caching no es “guardar respuestas” ni “dar memoria” al modelo. Lo que hace es cachear (reutilizar) un prefijo idéntico del prompt para no recalcularlo en cada petición.
Anthropic explica el mecanismo así: cuando se habilita el prompt caching, el sistema puede guardar todo el contenido hasta un “punto de corte” (cache breakpoint) y, en solicitudes posteriores que mantengan exactamente el mismo prefijo, reutilizarlo. Eso reduce latencia (menos trabajo de cómputo) y coste (los tokens en cache hit se cobran más baratos que el precio base de entrada).
Lo relevante en 2026 es el enfoque “automático”: en lugar de ir marcando manualmente puntos de caché en cada bloque, se puede habilitar con un único parámetro a nivel de petición y dejar que el sistema mueva el punto de caché hacia delante a medida que crece la conversación. Es decir: cada nuevo turno puede cachear “todo lo anterior” hasta el último bloque cacheable, y las partes previas se leen desde caché.
Lo que importa de verdad: cuánto ahorra y cuándo funciona
Anthropic publica precios diferenciados para este esquema: tokens de entrada base, escrituras de caché y cache hits. La consecuencia práctica es que un cache hit puede ser un orden de magnitud más barato que el token de entrada normal, dependiendo del modelo.
Un ejemplo claro (y fácil de entender): en la documentación de prompt caching, para modelos como Sonnet 4.6 se menciona un precio base de entrada y un precio muy inferior para cache hits & refreshes. En su página de Sonnet, Anthropic también habla de ahorros de hasta el 90 % gracias al prompt caching en ciertos escenarios. Esa cifra es un “hasta” (depende de que el prefijo sea realmente estable y de que haya hits), pero refleja la dirección del cambio: cuando un agente reusa mucha instrucción repetida, el ahorro puede ser enorme.
Eso conecta con la afirmación de Njenga en Medium, que lo expresa de forma agresiva (“10 céntimos por dólar”). No debe tomarse como garantía universal —cada arquitectura tiene su ratio de reuso—, pero sí como una señal: si el agente paga una y otra vez el mismo prompt, el caching cambia la economía del proyecto.
Cómo aprovecharlo sin volverse loco
En la práctica, hay tres reglas simples que determinan si el caching “pega” o no:
- Poner lo estático delante y lo dinámico al final
Instrucciones, definiciones de herramientas, ejemplos y contexto repetido deben ir al inicio. Datos variables (el input del usuario, resultados de herramientas, IDs, timestamps) conviene dejarlos para el final. Si lo dinámico se cuela al principio, se rompe el prefijo y la caché no sirve. - Mantener herramientas y sistema consistentes
Anthropic indica que el caching tiene en cuenta el prompt completo en orden: herramientas, sistema y mensajes. Si cada turno cambia las herramientas, se reduce drásticamente la probabilidad de cache hit. - Entender la ventana temporal
Por defecto, la caché tiene una vida de 5 minutos y se refresca sin coste adicional cuando se usa. Si el flujo real del producto tiene pausas largas entre turnos, Anthropic ofrece una opción de 1 hora con coste adicional (útil en agentes que operan con ventanas más largas).
Tabla resumen: el “coste fantasma” antes y después
| Escenario típico en agentes | Sin caching | Con caching (si hay prefijo estable) |
|---|---|---|
| System prompt largo (p. ej., 10.000 tokens) | Se paga en cada turno | Se paga una vez como escritura y luego se reutiliza |
| 50 turnos de agente | 10.000 × 50 = 500.000 tokens repetidos | La mayoría pasa a “cache hit” (mucho más barato) |
| Latencia | Recalcula siempre el prefijo | Reutiliza prefijo cacheado |
| Riesgo de “susto” en factura | Alto | Mucho menor (si hay buen diseño del prompt) |
Un estándar que se extiende: no es solo Anthropic
El prompt caching ya es una tendencia de industria. OpenAI, por ejemplo, documenta un sistema de caching que funciona automáticamente en muchas peticiones y promete reducciones grandes de coste y latencia cuando se repiten partes del prompt. AWS también lo ofrece en Bedrock para modelos compatibles. La lectura es clara: a medida que los agentes se vuelven la norma, el caching se vuelve infraestructura.
El matiz que no conviene olvidar
Reducir costes no elimina la necesidad de gobernanza. Un agente barato puede seguir siendo peligroso si se descontrola: más turnos, más herramientas, más llamadas. El caching ayuda a no pagar una y otra vez lo mismo, pero la disciplina de producto sigue siendo la misma: límites de turnos, validación de resultados y observabilidad del gasto.
Preguntas frecuentes
¿Qué es el prompt caching en la API de Claude?
Es un mecanismo que permite reutilizar un prefijo idéntico del prompt (herramientas, instrucciones y parte de los mensajes) para reducir latencia y coste en turnos posteriores.
¿El prompt caching “da memoria” al modelo?
No. No guarda “recuerdos” ni respuestas; reutiliza cómputo de entrada cuando el texto inicial es exactamente el mismo.
¿Qué hay que hacer para activar el caching automático en Claude?
Anthropic explica que se habilita añadiendo un campo de cache_control a nivel de petición (modo automático), y el sistema aplica el punto de caché al último bloque cacheable.
¿Cuándo no compensa el prompt caching?
Cuando el prefijo cambia continuamente (por ejemplo, si se reordena el prompt, se añaden datos variables al inicio o se alteran herramientas en cada turno), o si las sesiones se espacian más que la vida de la caché sin usar una duración mayor.
