El prompt caching reutiliza la parte estable de tu prompt (instrucciones, documentos, definiciones de herramientas) para que el modelo no tenga que volver a procesarla en cada llamada, lo que abarata las peticiones y reduce la latencia. Cuando construyes un agente que repite el mismo contexto una y otra vez, esa repetición domina la factura. En esta guía verás qué es el prompt caching, cómo funciona en Anthropic, OpenAI y Gemini, cómo ordenar el prompt para maximizar los aciertos, cuánto se ahorra de verdad y cómo cachear en tu propia máquina con vLLM. La misma explicación está disponible en inglés.

Puntos clave

  • El prompt caching almacena el prefijo ya calculado de un prompt; en las siguientes peticiones que empiezan igual, el modelo lee la caché en vez de reprocesar esos tokens.
  • Anthropic cobra la lectura de caché a alrededor del 10% del precio de entrada (hasta un 90% menos) y la escritura a 1,25× (caché de 5 minutos) o 2× (caché de 1 hora).
  • OpenAI aplica un 50% de descuento a los tokens en caché de forma automática, a partir de 1.024 tokens y en incrementos de 128 tokens, sin cambios en tu código.
  • Google Gemini descuenta un 90% los tokens en caché (2.5 Flash pasa de 0,30 a 0,03 dólares por millón) y activa la caché implícita por defecto en los modelos 2.5 y posteriores.
  • La caché es un prefijo exacto: cualquier cambio de un solo byte al principio del prompt invalida todo lo que viene detrás, así que el orden importa más que las etiquetas de caché.

¿Qué es el prompt caching?

El prompt caching es una técnica que guarda el resultado intermedio de procesar el principio de un prompt para no repetir ese trabajo en peticiones posteriores. Un modelo de lenguaje convierte cada token de entrada en una representación interna antes de generar la respuesta; ese cálculo cuesta tiempo y dinero. Si diez llamadas comparten las mismas 8.000 palabras de instrucciones y documentación, sin caché pagas por procesar esas 8.000 palabras diez veces.

Con la caché activada, la primera llamada calcula y almacena el prefijo, y las siguientes lo leen a una fracción del precio. El ahorro es grande justamente en los casos donde más se nota: agentes con un prompt de sistema largo, asistentes que responden preguntas sobre el mismo documento o flujos de ingeniería de contexto que arrastran mucho historial. La clave es que la caché funciona por prefijo: reutiliza los tokens comunes desde el inicio y deja de aprovecharse en el primer punto donde dos prompts difieren.

¿Cómo funciona en Anthropic, OpenAI y Gemini?

Los tres grandes proveedores ofrecen prompt caching, pero con modelos de activación y precios distintos.

Anthropic usa caché explícita: marcas hasta cuatro puntos de corte con cache_control y decides qué prefijo cachear. La documentación oficial resume la economía así: «los tokens leídos de caché cuestan solo el 10% del precio base de entrada». La escritura tiene un pequeño recargo (1,25× para la caché de 5 minutos, 2× para la de 1 hora), así que compensa a partir de la segunda lectura. El orden de renderizado es tools → system → messages, y el prefijo mínimo cacheable ronda los 1.024 tokens según el modelo.

OpenAI usa caché automática: no tocas nada. Cualquier petición de más de 1.024 tokens aprovecha el prefijo ya visto, que se cachea en tramos de 128 tokens, con un 50% de descuento en la parte reutilizada y una latencia hasta un 80% menor. Como la escritura es gratuita en los modelos clásicos, cualquier acierto es dinero ahorrado sin cálculo de rentabilidad.

Google Gemini combina las dos ideas. La caché implícita viene activada por defecto en los modelos 2.5 y posteriores y aplica el descuento sin configuración. La caché explícita te deja crear objetos de caché reutilizables a cambio de un coste de almacenamiento por hora (1,00 dólar por millón de tokens y hora en 2.5 Flash). En ambos casos el descuento sobre el token cacheado es del 90%.

¿Cómo estructurar el prompt para maximizar los aciertos?

La regla de oro es una: lo estable va delante, lo que cambia va detrás. Como la caché es un prefijo exacto, un solo carácter distinto al principio tira por tierra toda la reutilización posterior. Este ejemplo con el SDK de Anthropic cachea un documento largo en el bloque de sistema y deja la pregunta variable fuera del punto de corte:

from anthropic import Anthropic

cliente = Anthropic()

respuesta = cliente.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": DOCUMENTO_LARGO,  # el prefijo estable que quieres cachear
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": "Resume los puntos clave"}],
)

# Verifica el acierto: si es 0 en peticiones repetidas, algo invalida la cache
print(respuesta.usage.cache_read_input_tokens)

Evita los invalidadores silenciosos: no metas datetime.now() ni identificadores aleatorios en el prompt de sistema, serializa el JSON con las claves ordenadas y no cambies el conjunto de herramientas a mitad de conversación (las herramientas se renderizan las primeras y su cambio invalida toda la caché). Para una caché de una hora, usa {"type": "ephemeral", "ttl": "1h"}, que dura más entre ráfagas de tráfico a cambio de una escritura más cara.

¿Cuánto se ahorra en coste y latencia?

Depende del ratio de acierto, pero el orden de magnitud es claro. Si el 80% de tus tokens de entrada son un prefijo compartido y ese prefijo se lee a un 10% de su precio, el coste de entrada baja de forma drástica: pagas el precio completo solo por el 20% variable más una fracción por el resto. Con el 50% de OpenAI el ahorro es menor pero llega gratis y sin trabajo.

El punto de equilibrio importa cuando hay recargo de escritura. Con la caché de 5 minutos de Anthropic, dos peticiones ya salen a cuenta (1,25× de escritura más 0,1× de lectura frente a 2× sin caché); con la de 1 hora necesitas al menos tres. La latencia también cae: OpenAI habla de hasta un 80% menos de tiempo de procesamiento del prompt, porque leer de caché es mucho más rápido que recalcular. En un agente que dispara muchas llamadas por tarea, ese recorte se nota tanto en la factura como en la experiencia. Si quieres medir el impacto en producción, una herramienta como Helicone te muestra el ratio de acierto por petición.

¿Se puede cachear en modelos que ejecutas tú (vLLM)?

Sí, y sin coste por token. Los motores de inferencia como vLLM implementan automatic prefix caching (APC): guardan la caché de claves y valores (KV cache) de los prefijos ya calculados y la reutilizan cuando otra petición empieza igual. No es una tarifa que ahorras, sino cómputo de GPU que no repites, lo que se traduce en menos latencia y más peticiones por segundo.

# Prefix caching viene activado por defecto en el motor V1 de vLLM;
# este flag lo deja explícito
vllm serve meta-llama/Llama-3.1-8B-Instruct --enable-prefix-caching

Es la misma idea que la caché de los proveedores, aplicada a tu propio hardware: si sirves un prompt de sistema fijo a miles de usuarios, la primera petición calienta la KV cache y el resto la aprovecha. Combina bien con una pasarela como OpenRouter cuando mezclas modelos propios y de API detrás de la misma interfaz.

Preguntas frecuentes

¿El prompt caching cambia la respuesta del modelo?

No. La caché solo evita repetir el cálculo del prefijo; el modelo genera exactamente la misma salida que generaría sin ella. Cachear es una optimización de coste y latencia, no un cambio de comportamiento. Lo único que varía es el desglose de tokens de la respuesta: verás parte de la entrada facturada como lectura de caché en lugar de como entrada nueva.

¿Cuánto tiempo vive la caché?

Poco, por diseño. Anthropic usa 5 minutos por defecto y ofrece una opción de 1 hora; OpenAI retiene el prefijo del orden de minutos de inactividad (con ventanas más largas en los modelos recientes); Gemini mantiene la caché explícita el tiempo de vida que le indiques, pagando almacenamiento por hora. Cada acceso suele refrescar el temporizador, así que un tráfico constante mantiene la caché caliente sola.

¿Cuál es el tamaño mínimo para que se cachee?

Ronda los 1.024 tokens en Anthropic y OpenAI, y 2.048 en Gemini 2.5 Pro. Por debajo de ese umbral la petición simplemente no cachea, sin error: verás cero tokens de lectura de caché. Por eso el prompt caching brilla en prompts largos y repetidos, no en preguntas cortas y únicas.

Conclusión

El prompt caching es de las optimizaciones con mejor relación esfuerzo-recompensa cuando construyes agentes o asistentes que repiten contexto. La receta es sencilla: coloca lo estable al principio, marca el punto de corte donde empieza lo variable y mide el ratio de acierto. Con descuentos de hasta el 90% en Anthropic y Gemini y del 50% automático en OpenAI, más el prefix caching gratuito de vLLM en tu propia máquina, la repetición deja de ser un lastre en la factura. El siguiente paso es revisar tu prompt de sistema, congelar su prefijo y activar la caché en el proveedor que uses.

Fuentes: [1] Prompt caching, documentación de Anthropic[1], [2] Prompt caching, guía de OpenAI[2], [3] Context caching, Gemini API[3], [4] Automatic prefix caching, documentación de vLLM[4].

Visitas: 0

Fuentes

  1. Prompt caching, documentación de Anthropic
  2. Prompt caching, guía de OpenAI
  3. Context caching, Gemini API
  4. Automatic prefix caching, documentación de vLLM

Ruta: Agentes de IA en producción: evaluación y fiabilidad