Lo que el prompt caching cuesta de verdad
Y por qué tu hit rate seguramente está al 20 %

Si tu factura LLM contiene Anthropic y no has instrumentado manualmente tu cache hit rate, casi con seguridad estás dejando 3-5× de reducción de coste sobre la mesa. No es una suposición. Es lo que vemos en cada equipo que auditamos.

El prompt caching es la mayor palanca de coste de la API de Anthropic. Bien usado, hace que tus tokens input repetidos pasen del precio completo al 10 % del precio completo, un descuento del 90 % sobre la parte de tu prompt que no cambia. Mal usado, que es lo que pasa en la mayoría de equipos, pagas el precio de lista y te preguntas por qué tu factura es tan grande.

Aquí tienes cómo funciona de verdad, por qué tu hit rate es peor de lo que crees, y los cambios concretos que llevan el hit rate del 20 % al 90 %.

Cómo funciona el prompt caching de verdad

Cuando marcas una sección de tu prompt como cacheable, Anthropic hashea esa sección y guarda su representación interna en el servidor durante 5 minutos. Si exactamente el mismo prefix reaparece en esos 5 minutos, el modelo no reprocesa esos tokens desde cero, carga el estado en cache y continúa desde ahí.

El pricing cambia radicalmente:

• Escritura del cache: 1,25× el precio input normal (prima one-time del 25 %)
• Lectura del cache: 0,1× el precio input normal (descuento del 90 %)
• TTL del cache: 5 minutos (extensible a 1 hora pagando un extra)

Así que la primera llamada paga un poco más, y cada llamada siguiente dentro de los 5 minutos paga el 10 % del coste input sobre la parte cacheada. Si haces muchas llamadas con el mismo system prompt, el cálculo es brutal a tu favor.

Pero hay una trampa: los cache hits solo se producen si el prefix es idéntico byte por byte. Ahí es donde la mayoría de equipos se estrellan.

Por qué tu hit rate es peor de lo que crees

Tres patrones rompen el caching en silencio:

1. Pones campos dinámicos arriba

El error más común. Tu system prompt seguramente se parece a esto:

Eres un asistente para Acme Corp.
Usuario actual: user_abc123
Fecha actual: 2026-04-23 14:17:02
Sesión: sess_9f8a...

Tu trabajo es ayudar a los usuarios con:
- Preguntas de cuenta
- Facturación
- Problemas técnicos
[... 1 500 tokens de instrucciones ...]

Cada campo encima de las instrucciones es dinámico. User ID, timestamp, session ID. En cuanto uno de esos campos cambia, el hash cambia, el cache se invalida, y pagas precio completo por los 2 000 tokens siguientes.

Fix: mete los campos dinámicos al final del mensaje, o en un mensaje user separado. Pon las instrucciones estables primero.

Tu trabajo es ayudar a los usuarios con:
- Preguntas de cuenta
[... 1 500 tokens de instrucciones estables ...]

---
Usuario actual: user_abc123
Fecha actual: 2026-04-23 14:17:02
Sesión: sess_9f8a...

Ahora los primeros 1 500 tokens cachean. En la segunda request con las mismas instrucciones, pagas 0,30 $/M en vez de 3 $/M sobre esos tokens.

2. Subes versiones de prompt a la ligera

Los equipos iteran sobre los prompts constantemente. Cada versión nueva invalida cada prefix cacheado. Si shipeas un cambio de prompt tres veces al día, tu cache nunca vive lo bastante para ser útil.

Fix: agrupa los cambios de prompt en releases semanales. Entre releases, el prefix es estable y puede cachear. Si estás en modo iteración rápida, asume que el caching no te va a ayudar, pero entonces desactívalo para no pagar la prima de escritura por nada.

3. No has puesto cache breakpoints

La API de Anthropic te deja marcar hasta cuatro cache breakpoints por request. Si no pones ninguno, solo cachea el system prompt. Pero seguramente tienes más contenido estático: ejemplos few-shot, definiciones de herramientas, un snippet de knowledge base. Todo eso también puede cachear, si lo marcas.

messages = [
    {"role": "system", "content": SYSTEM_PROMPT, "cache_control": {"type": "ephemeral"}},
    {"role": "user", "content": KNOWLEDGE_BASE, "cache_control": {"type": "ephemeral"}},
    {"role": "user", "content": FEW_SHOTS, "cache_control": {"type": "ephemeral"}},
    {"role": "user", "content": current_question},
]

Cuatro cache breakpoints. Todos estables entre requests. Solo current_question no está cacheado. Tu coste input efectivo por request se desploma.

Medir tu hit rate real

Anthropic devuelve las stats de cache en cada respuesta API. Tienen esta pinta:

{
  "usage": {
    "input_tokens": 52,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 2100,
    "output_tokens": 180
  }
}

Tres cifras que deberías trackear:

• input_tokens, input no cacheado
• cache_creation_input_tokens, pagado a 1,25× para escribir el cache
• cache_read_input_tokens, pagado a 0,1× para leer el cache

Tu hit rate es:

hit_rate = cache_read_tokens / (cache_read_tokens + cache_creation_tokens + input_no_cache)

Si no logueas estos tres campos por request, pilotas a ciegas.

Un hit rate sano en un chatbot o un agente con un system prompt estable debería estar entre el 85-95 %. Si el tuyo está por debajo del 70 %, uno de los tres patrones de arriba te está mordiendo. Si está por debajo del 30 %, los tres seguramente.

Lo que un hit rate del 90 % da en dólares

Hagamos las cuentas sobre un caso concreto: un bot de soporte cliente, Sonnet 4.6, 5 000 conversaciones al día, 4 turnos por conversación, system prompt de 2 000 tokens, bloque few-shot de 500 tokens, mensaje de usuario de 300 tokens por turno.

Sin caching:

• Tokens input por llamada: 2 800 (system + few-shots + user)
• Coste input diario: 5 000 × 4 × 2 800 × 3 $/M = 168 $/día

Con caching al 30 % de hit rate (típico):

• Parte cacheada: 0,3 × 2 500 tokens (system + few-shots) × 0,30 $/M = 0,00023 $ por llamada
• Parte no cacheada: 0,7 × 2 500 + 300 = 2 050 tokens × 3 $/M = 0,00615 $ por llamada
• Diario: 5 000 × 4 × 0,00638 $ = 127 $/día

Con caching al 90 % de hit rate (lo que deberías tener):

• Parte cacheada: 0,9 × 2 500 × 0,30 $/M = 0,000675 $ por llamada
• Parte no cacheada: 0,1 × 2 500 + 300 = 550 tokens × 3 $/M = 0,00165 $ por llamada
• Diario: 5 000 × 4 × 0,00232 $ = 46 $/día

O sea 81 $/día ahorrados, o 2 430 $/mes, solo con pasar del 30 % al 90 % de cache hit. Sin reescribir código más allá de reordenar el prompt y añadir breakpoints.

Las trampas que nadie te avisa

Algunos edge cases raros que nos hemos encontrado:

El tamaño del system prompt importa. Anthropic solo cachea si la sección marcada tiene >1024 tokens. Los system prompts pequeños nunca se cachean aunque los marques. Si tu system prompt tiene 800 tokens, pádealo hasta 1 100 con instrucciones estables, o asume que no va a cachear.

Las definiciones de herramientas son cacheables pero fáciles de romper. Si generas tus tool schemas dinámicamente (común con MCP o plugins), el orden de las claves JSON importa para el hashing. Ordena las claves alfabéticamente o tendrás cache misses por drift de orden.

Los 5 minutos de TTL son reales. El tráfico esporádico (un chatbot que tira una vez cada 10 minutos) fallará cada cache. Para endpoints de bajo volumen, considera el TTL de 1 hora (cuesta 2× la prima de escritura pero vive 12× más), breakeven sobre 6 cache reads por hora.

El cache es por región. Si Anthropic hace failover a otra región a media sesión, pierdes el cache. No es frecuente, pero explica los bursts misteriosos de cache misses cuando ves incidentes de proveedor.

Lo que hay que hacer el lunes por la mañana

Tres acciones, por orden de ROI:

1. Loguea las stats cache en cada respuesta. Si no ves estos tres campos en tus métricas hoy, no puedes optimizar a ciegas. Es un fix de 15 minutos.
2. Reordena tu system prompt para poner los campos dinámicos al final. Eso solo suele llevar el hit rate del 30 % al 75 %.
3. Marca cache breakpoints explícitos en los ejemplos few-shot, las tool defs, y los bloques grandes de contexto estable.

Si haces estas tres cosas, tu factura Anthropic seguramente baja un 40-60 % esta semana, sin ningún cambio del lado del usuario.

Este artículo es el deep-dive compañero de Las matemáticas ocultas del pricing LLM, donde el cache fallido es el ítem nº 4 en la lista de los seis multiplicadores ocultos.