Envías el mismo system prompt a Claude 200 veces al día. En cada turno, el modelo lo relee todo. Y lo vuelves a pagar todo. El prompt caching de Anthropic es una sola clave que añades en la petición, sin reescribir el código, y el coste de los tokens de entrada se desploma en cuanto reutilizas un mismo bloque.
Por qué pagas demasiado hoy
Usas Claude para un asistente que responde preguntas sobre tu documentación interna. Tu system prompt ocupa 4.000 tokens (instrucciones + extractos de doc). En cada conversación, en cada turno de esa conversación, la API relee esos 4.000 tokens como input. La tarifa se cobra sobre esos tokens aunque no hayan cambiado.
Con 200 peticiones al día, durante un mes, con varios usuarios en paralelo, la factura sube rápido. Lo peor es que ese contexto no cambia. Estás pagando la inercia.
Activar el caché: una sola clave
Tomas tu petición actual, añades cache_control en el bloque que debe cachearse. Eso es todo.
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=1024,
system=[
{
"type": "text",
"text": LONG_SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"},
}
],
messages=[
{"role": "user", "content": "Pregunta del usuario"}
],
)El bloque system (aquí un prompt largo + extractos de documentación) se vuelve cacheable. En la primera llamada, Anthropic escribe el caché y te cobra 1,25x esa tarifa. En la segunda llamada en menos de 5 minutos con el mismo bloque, es un hit: 0,10x.
Puedes hacer lo mismo con las tools y con bloques user que no cambian.
El ahorro real en los hits
| Tarifa tokens de entrada | Sin caché | Con caché (hit) |
|---|---|---|
| Multiplicador | 1,00x | 0,10x |
| Ahorro | ninguno | 90 % |
| Vuelves a pagar en cada turno | sí | no, dentro de la ventana TTL |
En concreto, si tu system prompt tiene 4.000 tokens a 5 por llamada. Con un hit cacheado, son 0,002 /día a 0,40 $/día solo para ese bloque. Y eso es antes de contar los hits en las tools y el contexto conversacional.
La trampa del primer hit
La trampa que la mayoría de integraciones pasa por alto: escribir el caché cuesta un 25 % más que la tarifa estándar. Así que la primera llamada cuesta 1,25x en lugar de 1,00x. Solo a partir del segundo hit en los 5 minutos empiezas a salir ganando.
Primera llamada: escritura del caché
Pagas 1,25x. El bloque se escribe en el caché de Anthropic.
Segunda llamada en menos de 5 min: primer hit
Pagas 0,10x. El total acumulado en 2 llamadas es 1,35x, aún más caro que 2 llamadas sin caché (2,00x... espera, ya estamos ganando).
Tercera llamada y siguientes: hits netos
A 0,10x cada uno, cada hit adicional amplía la diferencia. Con 10 llamadas en 5 min, pagas aproximadamente 2,15x en lugar de 10,00x.
Cuándo es rentable, cuándo es una pérdida
| Caso de uso | Caching útil | Por qué |
|---|---|---|
| Asistente de doc interna con 50+ usuarios activos | sí | Hits constantes en paralelo, ventana TTL siempre activa |
| Chatbot de soporte con contexto largo | sí | Los mismos 3.000+ tokens de contexto por conversación |
| Generación batch nocturna | sí | Envías 1.000 peticiones seguidas |
| Script puntual, 1 llamada por hora | no | El TTL de 5 min expira entre cada llamada |
| Prompts cortos (menos de 1.024 tokens) | no | La API ignora cache_control por debajo del umbral |
Medir el hit ratio en producción
La API devuelve en la respuesta los contadores cache_creation_input_tokens y cache_read_input_tokens. Puedes registrar los dos y calcular tu hit ratio de forma continua.
usage = response.usage
hits = usage.cache_read_input_tokens
writes = usage.cache_creation_input_tokens
total_in = usage.input_tokens + hits + writes
hit_ratio = hits / total_in if total_in else 0
print(f"Hit ratio: {hit_ratio:.0%}")Por encima del 30-40 % de hits, estás claramente ganando. Por debajo, te acercas al break-even, y es una señal para replantear tu patrón de tráfico o desactivar el caché en ciertos bloques.
Un hit ratio inferior al 10 % en producción significa que el caché te cuesta más de lo que te ahorra. Desactívalo en los bloques afectados.
Las trampas en el código
Preguntas frecuentes
¿El caching cambia la calidad de las respuestas?
No, sin ningún impacto en la salida del modelo. Obtienes exactamente la misma respuesta, más rápido y más barato. Anthropic no reprocesa los tokens cacheados, pero el modelo los ve como si se hubieran enviado normalmente.
¿Cuántos bloques cache_control puedo poner en una petición?
Hasta 4 por petición. Puedes cachear por separado tu system prompt, tus tools, un bloque de doc en messages, y otro más. Anthropic los gestiona de forma independiente.
¿Los tokens cacheados cuentan en la ventana de contexto?
Sí. Los tokens cacheados siguen ocupando la ventana del modelo. El caching no te da más contexto, solo un coste menor en los tokens de entrada que envías.
¿Existe el riesgo de que el caché se evicte antes de 5 minutos?
En la práctica, en un proyecto activo, no. Anthropic describe el modo ephemeral como un caché de mejor esfuerzo, pero en uso real aguanta bien la ventana TTL. Con tráfico muy esporádico, puede ocurrir.
Para profundizar
Activa el caché en tu bloque más voluminoso, mide el hit ratio durante 48 horas, y tendrás una visión cifrada de lo que realmente cambia en tu caso. Si quieres una revisión de tu stack de IA, hablamos.
Hablar de tu stack de IA con Blokby