Durante meses, muchos equipos de desarrollo y operaciones han vivido el mismo patrón con los agentes de Inteligencia Artificial: el prototipo funciona, el workflow encadena herramientas, el pipeline entra en CI… y, de repente, llega una factura que no cuadra con la sensación de uso real. No siempre es por respuestas largas ni por “pensamiento profundo”. A menudo es por algo más silencioso: pagar una y otra vez el mismo prompt.
El problema nace de una realidad técnica conocida: las APIs de modelos de lenguaje suelen ser stateless. No “recuerdan” entre llamadas, así que el cliente debe reenviar en cada turno el system prompt, el contexto, las definiciones de herramientas y las instrucciones de seguridad. En un chat corto, esto se nota poco. En un agente de 40 o 50 turnos, con herramientas, reintentos y validaciones, el coste se multiplica.
El ejemplo más fácil de visualizar es el que se ha popularizado en las últimas semanas: un agente que ejecuta 50 turnos con un system prompt de 10.000 tokens termina “pagando” 10.000 × 50 = 500.000 tokens solo por repetir instrucciones. El usuario cree que está pagando por “trabajo nuevo”, pero una parte enorme del gasto se va en recomputar un prefijo que no cambia.
Qué ha cambiado: Claude ya puede cachear automáticamente el prefijo estático
Anthropic ha atacado este punto con prompt caching, y lo relevante para devs y sysadmins es que ahora existe un modo automático (el recomendado) que evita tener que marcar manualmente cada bloque. En la práctica, basta con añadir un cache_control a nivel superior en la petición para que el sistema coloque el “punto de caché” en el último bloque cacheable y lo vaya moviendo hacia delante conforme crece la conversación.
Conviene entender bien qué cachea: Claude cachea el prefijo completo de la petición en el orden tools → system → messages, hasta e incluyendo el bloque designado como cacheable. En turnos posteriores, si ese prefijo es idéntico, el modelo no lo recalcula: lo lee desde caché.
El resultado tiene dos impactos inmediatos:
- Coste: los tokens leídos desde caché se cobran a un precio mucho menor que los tokens de entrada normales.
- Latencia: al evitar recomputación del prefijo, mejora el time-to-first-token, especialmente en prompts largos o con documentos extensos.
El detalle que importa al presupuesto: multiplicadores y TTL
Anthropic no vende esto como “gratis”, sino como una estructura de costes distinta. A nivel de multiplicadores:
- Cache write de 5 minutos: 1,25× el precio base de tokens de entrada.
- Cache write de 1 hora: 2× el precio base.
- Cache read (hits y refrescos): 0,1× el precio base.
La caché tiene, por defecto, una vida de 5 minutos, y se refresca sin coste adicional cada vez que se usa dentro de esa ventana. Si 5 minutos se queda corto (por ejemplo, agentes que esperan acciones humanas, aprobaciones o ejecuciones largas), puede configurarse una caché de 1 hora añadiendo ttl: "1h" al cache_control.
Tabla: reglas de coste del prompt caching en Claude
| Elemento | Qué es | Multiplicador sobre el precio base |
|---|---|---|
| Cache write (5 min) | Tokens nuevos que se escriben en caché | 1,25× |
| Cache write (1 h) | Tokens nuevos con TTL extendido | 2× |
| Cache read | Tokens reutilizados desde caché | 0,1× |
| Sin caché | Tokens de entrada normales | 1× |
Por qué esto le interesa a un sysadmin: menos gasto, mejor uso de rate limits
Aquí aparece una ventaja poco comentada fuera de equipos de plataforma: Anthropic indica que los cache hits no descuentan del rate limit. En escenarios con agentes concurrentes (o con ráfagas de herramientas), esto puede ser tan valioso como el ahorro económico: no solo pagas menos, también reduces presión sobre límites operativos.
Además, la API devuelve métricas específicas en usage para observar el caching:
cache_read_input_tokens: tokens servidos desde caché.cache_creation_input_tokens: tokens escritos en caché en esa petición.input_tokens: tokens totales de entrada.- Un desglose adicional en
cache_creationpor tipo de caché (5 min / 1 h).
En la práctica, esto permite instrumentar dashboards y alertas: si cache_read_input_tokens cae a cero de golpe, algo está rompiendo el prefijo (reordenación del prompt, herramientas cambiantes, o datos dinámicos colándose “arriba”).
Tabla: qué loguear en producción para vigilar el caching
| Campo | Qué indica | Señal de problema |
|---|---|---|
cache_read_input_tokens | Ahorro real por reutilización | Si baja a 0, se rompió el prefijo |
cache_creation_input_tokens | Coste de escribir caché | Si sube mucho, estás cambiando demasiado |
input_tokens vs cache_read_input_tokens | % de prompt reutilizado | Si el ratio cae, el agente “deriva” |
output_tokens | Respuesta generada | Si sube, el problema no es caching, es verbosidad |
Cómo diseñar un agente para que el caching “pegue”
En agentes reales, el caching no es magia: depende del layout del prompt. Tres reglas sencillas suelen marcar el éxito:
- Poner lo estático arriba: system prompt, políticas, definiciones de herramientas, ejemplos estables.
- Dejar lo dinámico al final: entradas del usuario, resultados de herramientas, timestamps, IDs, trazas, “estado” de ejecución.
- No cambiar herramientas en cada turno: si
toolscambia, el prefijo cambia.
Un consejo operativo útil: versionar el prompt estático (“policy_v3”, “tools_v12”) y asumir que cualquier cambio invalida la caché. Esto no es malo; simplemente es el comportamiento esperado. Lo importante es hacerlo conscientemente.
Ejemplo rápido: activar caching automático
En Claude, el modo automático se habilita con un cache_control “ephemeral” a nivel superior. Para usar TTL de 1 hora, se añade ttl: "1h".
{
"model": "claude-sonnet-4-6",
"max_tokens": 1024,
"cache_control": { "type": "ephemeral" },
"system": "Instrucciones fijas, políticas y estilo...",
"messages": [
{ "role": "user", "content": "Entrada del usuario..." }
]
}
No es una rareza: OpenAI y AWS también empujan el caching
El prompt caching se está convirtiendo en infraestructura estándar. OpenAI documenta caching automático que puede reducir latencia y costes de tokens de entrada “hasta” porcentajes muy altos en prompts repetitivos, y AWS ofrece prompt caching en Bedrock como función opcional en modelos compatibles para evitar recomputación de contexto. La señal es clara: los agentes están haciendo que el coste del “prefijo repetido” sea el nuevo enemigo, y los proveedores están optimizando justo ahí.
Preguntas frecuentes
¿El prompt caching hace que Claude “tenga memoria”?
No. No es memoria conversacional. Es reutilización de cómputo del prefijo cuando el texto inicial es idéntico.
¿Qué suele romper la caché en agentes?
Cambiar herramientas (tools), mover bloques del prompt, o introducir datos variables en la parte “alta” del prompt (antes del punto cacheable).
¿Cuándo compensa usar TTL de 1 hora en vez de 5 minutos?
Cuando el agente tiene pausas largas entre turnos (aprobaciones humanas, ejecuciones lentas, trabajos en segundo plano) y se quiere mantener el ahorro más allá de 5 minutos.
¿Qué métrica debería vigilar un sysadmin para saber si el caching funciona?cache_read_input_tokens: si es alto, se está reutilizando contexto y bajando coste; si cae a cero, algo ha invalidado el prefijo.
