Prompt caching: recortar coste y latencia en producción

El contexto que pagas dos veces

Casi toda aplicación LLM en producción arrastra el mismo peso muerto: un prompt de sistema largo, unas instrucciones fijas, un puñado de ejemplos y, muchas veces, un documento entero de contexto. Ese bloque es idéntico en cada petición. Y en cada petición lo vuelves a enviar, el modelo lo vuelve a procesar y tú lo vuelves a pagar.

El prompt caching existe para cortar ese despilfarro. No es una optimización exótica ni un truco de laboratorio: es el ajuste con mejor relación esfuerzo/ahorro que puedes aplicar hoy a una app de LLM. Bien puesto, recorta hasta un 90 % del coste de la parte cacheada y baja la latencia hasta el primer token de forma notable. Mal puesto, no hace nada y ni te enteras.

Estas son las notas de campo para que haga algo.

Qué se cachea de verdad

Un LLM procesa tu prompt token a token y construye un estado interno (el KV cache) del que salen las siguientes predicciones. El prompt caching guarda ese estado ya calculado para un prefijo del prompt. Si tu siguiente petición empieza con exactamente el mismo prefijo, el modelo reutiliza el trabajo en lugar de rehacerlo.

Dos consecuencias que conviene tener claras desde el principio:

Solo se cachea un prefijo, y por coincidencia exacta. El caché cubre desde el inicio del prompt hasta el primer token que cambia. En cuanto algo difiere —una coma, una fecha, el nombre del usuario— el caché deja de aplicar de ahí en adelante.
El orden lo es todo. Lo estable va delante; lo variable, detrás. Si metes la pregunta del usuario antes del documento de contexto, rompes el prefijo y no cacheas nada útil.

Esa segunda regla es la que más dinero deja sobre la mesa cuando se ignora.

Ordena el prompt: estable delante, variable detrás

El patrón es sencillo de enunciar y fácil de incumplir. Todo lo que se repite entre peticiones va arriba; lo que cambia, abajo. En la API de Claude marcas el corte con cache_control:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": INSTRUCCIONES_LARGAS,  # prompt de sistema fijo
        },
        {
            "type": "text",
            "text": MANUAL_DE_PRODUCTO,     # documento de contexto estable
            "cache_control": {"type": "ephemeral"},  # cachea hasta aquí
        },
    ],
    messages=[
        # Lo único que cambia entre peticiones va al final.
        {"role": "user", "content": pregunta_del_usuario},
    ],
)

# En la respuesta verás el desglose: escritura vs lectura de caché.
print(response.usage)  # cache_creation_input_tokens / cache_read_input_tokens

La primera petición escribe el caché (paga un pequeño sobrecoste). Las siguientes, mientras el prefijo no cambie y estés dentro de la ventana de vida, leen el caché a una décima parte del precio. En OpenAI ni siquiera hay que marcar nada: el caché se aplica solo a prompts de 1.024 tokens o más, siempre que el prefijo coincida. La disciplina de ordenar el prompt, sin embargo, es la misma en ambos.

Cuánto ahorras y cuándo compensa

Los números importan, porque el caché no es gratis del todo: escribirlo cuesta un poco más que un token normal. La pregunta real es cuántos aciertos necesitas para amortizar ese sobrecoste.

Proveedor	Activación	Lectura de caché	Escritura	Mínimo	Vida
Claude (Anthropic)	Explícita (`cache_control`)	0,10× del input	1,25× (5 min) o 2× (1 h)	1.024 tokens	5 min o 1 h
OpenAI	Automática	0,50× del input	Sin sobrecoste	1.024 tokens	Minutos, hasta 1 h
Google (Gemini)	Explícita, con almacenamiento	Input reducido	Pago por hora de almacenamiento	Varía por modelo	Configurable

Con Claude a 5 minutos, recuperas el sobrecoste de escritura tras un solo acierto; a partir del segundo, todo es ahorro. Con la ventana de 1 hora amortizas al segundo acierto, así que solo compensa cuando las peticiones están lo bastante separadas como para que el caché corto expiraría, pero lo bastante juntas como para acertar dos veces dentro de la hora. OpenAI lo pone aún más fácil: descuento automático, sin sobrecoste de escritura y sin nada que configurar.

La regla mental: el caché compensa cuando reutilizas un prefijo grande muchas veces en poco tiempo. Un chatbot con un prompt de sistema de 4.000 tokens y tráfico constante es el caso ideal. Una tarea que se ejecuta una vez al día, no.

Dónde deja de ayudar

Cachear no es magia, y hay formas fáciles de anular el beneficio sin darte cuenta:

Prefijos por debajo del mínimo. Menos de 1.024 tokens y no hay caché. Los prompts cortos no se benefician; no fuerces contexto de relleno para llegar al umbral, no sale a cuenta.
Variabilidad colada arriba. Una marca de tiempo, un identificador de sesión o un saludo personalizado al principio del prompt de sistema rompe el prefijo en cada petición. Muévelo al final o elimínalo.
Expiración por tráfico bajo. El caché de 5 minutos se refresca con cada uso, pero si tus peticiones llegan más espaciadas, expira entre una y otra y siempre pagas escritura. Ahí es donde entra la ventana de 1 hora.
Cambios de modelo o de parámetros. Cambiar de modelo invalida el caché. Planifícalo antes de un despliegue que rote versiones.

Ninguno de estos casos es un fallo del caché; son señales de que el prompt no está ordenado para aprovecharlo.

Qué hacer el lunes

El caché de prompts es de esas cosas que dan resultado en una tarde y siguen ahorrando cada día después. Un plan mínimo y accionable:

Mide primero. Mira el desglose de usage en tus respuestas y calcula qué fracción de tus tokens de entrada es prefijo repetido. Si es alta, aquí hay dinero.
Reordena el prompt. Sistema e instrucciones fijas arriba, documentos de contexto estables después, entrada del usuario al final. Marca el corte de caché justo tras lo último que no cambia.
Elige la ventana según tu tráfico. Alta frecuencia, 5 minutos. Peticiones espaciadas pero recurrentes, 1 hora.
Verifica el acierto. Comprueba en producción que cache_read_input_tokens sube y el coste baja. Si no ocurre, algo variable se ha colado en el prefijo.

No es una optimización que requiera reescribir tu arquitectura ni cambiar de proveedor. Es ordenar lo que ya envías y dejar de pagar dos veces por el mismo contexto. Empieza por el prompt de sistema más largo que tengas: casi siempre es ahí donde está el ahorro esperando.