Estrategias de caching: prompt caching y caching de contexto

Los inicios de prompt repetidos cuestan dinero y tiempo en cada llamada. El prompt caching los guarda entre llamadas y ahorra ambas cosas.

El problema: el mismo texto, una y otra vez

Un agente suele enviar en cada petición el mismo inicio largo: prompt de sistema, definiciones de herramientas, documentos grandes. Sin caching, el modelo recalcula por completo esa parte en cada llamada individual — eso cuesta tiempo (latencia) y dinero (precio por token), aunque el texto no haya cambiado.

Cómo funciona el prompt caching

Anthropic y OpenAI ofrecen prompt caching para esto. El proveedor recuerda el inicio (prefijo) de un prompt que ya enviaste antes. Si poco después envías de nuevo ese mismo inicio — p. ej. el mismo prompt de sistema más un turno de usuario nuevo — el modelo solo tiene que procesar la parte nueva. El resto sale de la caché.

Qué ahorra

Con Claude, un acierto de caché (cache hit) cuesta solo una fracción del precio normal de los tokens de entrada, mientras que una escritura de caché (cache write) es algo más cara de lo normal. Con OpenAI, el prompt caching está activo automáticamente en cuanto un prompt es lo bastante largo, y reduce de forma notable coste y tiempo de espera, sin ningún cambio de código.

TTL: la caché caduca

Una caché no vive para siempre. Con Claude, el valor por defecto son 5 minutos; después la entrada desaparece, y la siguiente llamada vuelve a escribir en la caché. También existe una opción más larga y más cara. Quien envía muchas peticiones seguidas en poco tiempo es quien más se beneficia del caching.

EJEMPLO

Un agente con un prompt de sistema de 6.000 tokens más definiciones de herramientas hace 10 peticiones en 3 minutos. Sin caching, pagas el precio completo por esos 6.000 tokens en las 10 llamadas. Con caching, lo pagas una vez (escritura, 1,25x) y las otras 9 veces solo 0,1x — un ahorro claro, siempre que las peticiones se mantengan dentro del TTL de 5 minutos.

🛠️ EJERCICIO — PRUÉBALO TÚ

Averigua en uno de tus scripts de agente (o en la documentación de la API de tu proveedor de modelos) si y cómo se usa el prompt caching.

Mira el prompt de sistema / las definiciones de herramientas de tu agente: ¿cuántos tokens tiene aproximadamente esa parte fija?
Revisa en la respuesta de la API (si usas Claude) los campos cache_read_input_tokens y cache_creation_input_tokens — ¿se está acertando la caché?
Piensa: ¿con qué patrón de uso (muchas peticiones seguidas en poco tiempo frente a peticiones únicas poco frecuentes) merece más la pena el caching en tu caso?

✅ AUTOEVALUACIÓN

☐ ¿Puedes explicar por qué un acierto de caché es más barato que una escritura de caché?
☐ ¿Sabes cuánto dura una caché estándar en Claude antes de caducar?
☐ ¿Has identificado una parte concreta de tu propio prompt que sería adecuada para un punto de corte de caché?

QUIZ RÁPIDO

¿Por qué caduca por sí sola una entrada de prompt cache?