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 (caché de 1 hora).
  • OpenAI descuenta los tokens en caché de forma automática desde los 1.024 tokens: 50% y escritura gratis en los modelos anteriores a GPT-5.6; hasta un 90% en GPT-5.6 y modelos posteriores, que cobran la primera escritura a 1,25x y admiten puntos de corte explícitos en el prompt.
  • 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 toolssystemmessages, y el prefijo mínimo cacheable ronda los 1.024 tokens según el modelo.

OpenAI cachea de forma automática cualquier petición de más de 1.024 tokens, sin cambios en tu código, y la latencia baja hasta un 80%. En los modelos anteriores a GPT-5.6 el descuento es del 50% sobre la parte reutilizada y la escritura es gratuita, así que cualquier acierto es ahorro puro sin cálculo de rentabilidad. GPT-5.6 y los modelos posteriores cambian la economía: el descuento en lectura sube al 90%, la primera escritura cuesta 1,25x el precio de entrada (la misma proporción que la caché de 5 minutos de Anthropic) y puedes marcar puntos de corte explícitos en el prompt para decidir qué se cachea, con el prefijo garantizado durante al menos 30 minutos en vez de los «minutos de inactividad» de los modelos clásicos.

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 los modelos OpenAI anteriores a GPT-5.6 el ahorro es menor pero llega gratis y sin trabajo; en GPT-5.6 y posteriores el descuento sube al 90% a cambio de una pequeña escritura inicial, como en Anthropic.

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 (un enrutador que expone decenas de modelos de distintos proveedores tras una única API) 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 unos minutos de inactividad en los modelos anteriores a GPT-5.6, y garantiza un mínimo de 30 minutos en GPT-5.6 y posteriores; 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?

Depende del modelo. En Anthropic va de 512 tokens en los modelos más recientes a 4.096 en versiones anteriores (1.024 en Claude Opus 4.8, el modelo del ejemplo de arriba); en OpenAI son 1.024 tokens en todos los modelos actuales; en Gemini son 2.048 en la familia 2.5 y suben a 4.096 en los modelos más nuevos. Por debajo del 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, Gemini y los modelos OpenAI más recientes (50% automático y sin coste de escritura en las versiones de OpenAI anteriores a GPT-5.6), 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
  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