Prompt caching en Claude: cómo bajamos 73% la factura

TL;DR

Reestructuramos el orden de nuestros prompts y activamos prompt caching en Claude. El cache hit rate pasó de 0% a 81% en producción, lo que redujo nuestra factura de API en 73% en 6 semanas. El TTL de 5 minutos tiene implicaciones concretas que la mayoría ignora hasta que ya pagaron de más.

El problema: pagábamos por repetir el mismo texto millones de veces

Teníamos un pipeline de análisis de documentos legales. Cada request incluía un system prompt de 4.200 tokens: instrucciones de formato, ejemplos de extracción, terminología específica del cliente.

El documento a analizar cambiaba en cada llamada. El system prompt, nunca.

Aun así, pagábamos esos 4.200 tokens como tokens de entrada en cada una de las 3.800 llamadas diarias que procesábamos. Eso equivalía a casi 16 millones de tokens de entrada al día, de los cuales el 91% era texto idéntico.

La factura mensual llegó a $4.900. El 73% de ese costo era puro desperdicio acumulado request a request, día a día, durante semanas enteras en las que no sabíamos que existía una solución directa dentro de la propia API.

Antes de buscar alternativas de modelo o renegociar precios, decidimos auditar la composición real de nuestros tokens. Lo que encontramos fue un patrón claro: enviábamos el mismo bloque de 4.200 tokens en cada uno de los 3.800 requests diarios. El costo mensual asociado solo a ese bloque superaba los $3.500. El resto de la factura correspondía a los tokens variables, que eran los únicos que justificaban el precio estándar.

Ese diagnóstico fue el punto de partida. No necesitábamos un modelo más barato. Necesitábamos dejar de pagar por texto que ya habíamos enviado miles de veces.

Qué es el prompt caching y qué no es

Anthropic introdujo el prompt caching como una función explícita de la API: tú marcas qué bloques quieres cachear usando el parámetro cache_control, y Anthropic los almacena durante 5 minutos. Si el mismo bloque llega dentro de esa ventana, el costo por esos tokens cae a una décima parte del precio estándar.

No es magia del servidor. Tú decides qué se cachea y qué no. Si no marcas nada, pagas el precio completo siempre.

Los tokens de escritura de caché (el primer request que genera el caché) cuestan un 25% más que los tokens estándar. Los tokens de lectura de caché (todos los requests siguientes dentro de los 5 minutos) cuestan un 90% menos. La economía funciona si tienes volumen suficiente para amortizar ese primer costo.

Esto significa que el prompt caching no es una optimización pasiva que Anthropic aplica automáticamente en tu beneficio. Es una decisión de arquitectura que requiere que el equipo de desarrollo entienda la estructura del prompt, identifique los bloques invariantes y los etiquete correctamente en cada request. Si el sistema cambia (por ejemplo, si alguien modifica el system prompt o reordena los bloques), el caché se invalida y vuelves a pagar precio completo hasta que lo corrijas.

La documentación oficial en https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching detalla los modelos compatibles, los límites de bloques por request y las reglas de invalidación. Revisarla antes de implementar evita sorpresas en producción.

La regla de estructura que nadie te dice al principio

El error que cometimos durante las primeras 2 semanas fue colocar el contenido cacheado al final del prompt. Claude procesa el contexto de arriba hacia abajo, y el caché solo funciona sobre bloques que aparecen antes del punto de variación.

La regla es simple: lo estático va primero, lo dinámico va al final.

Estructura correcta:

1. System prompt completo (cacheado)
2. Documentos de referencia fijos, si los hay (cacheados)
3. Ejemplos few-shot invariantes (cacheados)
4. El input del usuario o documento variable (sin cachear)

Cualquier bloque variable que aparezca antes del bloque cacheado rompe el caché para todo lo que viene después. Lo comprobamos a las malas: un campo de metadata del usuario que insertábamos al inicio del system prompt anuló el caché completamente durante 11 días. El cache hit rate ese periodo fue de 0%.

La corrección fue simple pero no obvia: mover ese campo de metadata al final del mensaje, después de todos los bloques marcados con cache_control. Con ese único cambio, el hit rate saltó de 0% a 38% en menos de 24 horas.

Este tipo de error es más común de lo que parece. Muchos equipos activan el prompt caching, no ven mejora en el dashboard de costos y concluyen que la función no funciona para su caso. En la mayoría de los casos que hemos analizado, el problema es de orden, no de volumen ni de modelo.

Revisar la estructura del prompt debería ser el primer paso antes de cualquier otro ajuste. Un simple log de los tokens de entrada por bloque, comparado con el campo cache_read_input_tokens que devuelve la API, permite diagnosticar si el caché se está aplicando correctamente o no.

El TTL de 5 minutos y por qué destruye el ahorro si no lo planeas

5 minutos es poco tiempo si tu tráfico no es continuo.

Nuestro pipeline procesaba documentos en batches nocturnos. De las 11pm a las 3am, el sistema enviaba entre 200 y 400 requests por hora con pausas naturales entre grupos. El resultado: el caché expiraba repetidamente dentro de cada batch y el hit rate real en producción era de solo 34%, no el 81% que vemos hoy.

La solución fue mover los batches a un procesamiento más continuo: en lugar de esperar a acumular 100 documentos para enviarlos juntos, bajamos el umbral a 15 documentos y programamos el despacho cada 90 segundos. El TTL dejó de expirar entre llamadas y el hit rate subió al 81% en 3 días.

Si tu caso de uso tiene tráfico esporádico (menos de 1 request por minuto en promedio), el prompt caching probablemente no te ahorre nada. El caché expirará antes de que llegue el siguiente request.

Vale la pena calcular este número con datos reales antes de invertir tiempo en la implementación. Exporta los timestamps de los últimos 30 días y calcula el percentil 75 del intervalo entre requests consecutivos. Si ese percentil supera los 4 minutos, el ahorro será marginal. Si está por debajo de los 2 minutos, el caching probablemente sea la optimización de mayor retorno que puedas implementar hoy.

Para casos con tráfico mixto (picos diurnos y pausas nocturnas), considera separar las colas de procesamiento. Los documentos urgentes que llegan en horario laboral pueden procesarse en tiempo real, aprovechando el caché de forma natural. Los documentos diferibles pueden encolarse y procesarse en ventanas de alta densidad, donde el intervalo entre requests garantiza que el TTL no expira.

Cuándo y cómo usar ephemeral

El parámetro cache_control: {"type": "ephemeral"} le dice a la API que este bloque específico debe cachearse de forma independiente, sin depender del caché global de la sesión.

Sirve para 2 escenarios concretos:

Primero, aplicaciones multiusuario donde cada usuario tiene un contexto de sistema propio (por ejemplo, instrucciones personalizadas o historial reciente). Sin ephemeral, el caché del usuario A sobreescribe el del usuario B si ambos hacen requests casi simultáneos.

Segundo, cuando quieres cachear más de un bloque en el mismo request. La API permite hasta 4 puntos de ruptura de caché por mensaje. Puedes marcar el system prompt con ephemeral, marcar un documento de referencia extenso con otro bloque ephemeral, y dejar el input variable sin marcar.

En nuestro caso, agregamos un segundo bloque cacheado: un glosario jurídico de 1.800 tokens que incluíamos en todos los requests. Al marcarlo como ephemeral separado del system prompt, el ahorro adicional fue de $280/mes, porque ese bloque también se cargaba completo en cada llamada.

El uso de múltiples bloques ephemeral también permite versionar el caché de forma más granular. Si el system prompt cambia con menos frecuencia que el glosario, puedes actualizar solo el bloque del glosario sin invalidar el caché del system prompt. Esto es especialmente útil en sistemas donde distintos equipos controlan distintas partes del prompt, o donde algunas secciones se actualizan con cada despliegue mientras otras permanecen estables durante meses.

La referencia técnica completa del parámetro cache_control está disponible en https://docs.anthropic.com/en/api/messages, donde se documentan los tipos permitidos, los límites por request y el comportamiento esperado en casos de invalidación parcial.

Los números, semana a semana

Semana	Cache hit rate	Costo diario estimado	Cambio principal
Baseline	0%	$163	Sin caching activado
Semana 1	0%	$163	Caching activado pero mal estructurado
Semana 2	38%	$101	System prompt reordenado
Semana 3	34%	$107	Tráfico batch (caché expira)
Semana 4	81%	$44	Procesamiento continuo
Semana 6	81%	$44	Glosario legal cacheado como ephemeral

La factura del mes donde aplicamos todos los cambios fue de $1.320, frente a los $4.900 del mes anterior. La diferencia no vino de negociar precios ni de cambiar de modelo, sino de dejar de pagar por el mismo texto una y otra vez.

Los precios de referencia utilizados para estos cálculos están publicados en https://www.anthropic.com/pricing. Los valores exactos varían según el modelo y pueden actualizarse, por lo que conviene verificar antes de proyectar ahorros en un presupuesto formal.

Qué revisar antes de implementarlo

Primero, calcula tu ratio de tokens estáticos vs. dinámicos. Si el 60% o más de tus tokens de entrada son invariantes entre requests, el caching tiene sentido económico. Por debajo del 40%, el ahorro raramente compensa el tiempo de implementación.

Segundo, mide tu patrón de tráfico real. Exporta los timestamps de tus requests del último mes y calcula el intervalo promedio entre llamadas. Si supera los 4 minutos, el TTL trabajará en tu contra.

Tercero, prueba en staging con un 10% del tráfico antes de migrar todo. La API devuelve el campo cache_read_input_tokens en cada respuesta, lo que permite medir el hit rate real antes de comprometerte con el nuevo patrón de requests.

Cuarto, establece alertas sobre el cache hit rate en producción. Un caché que funcionaba bien puede dejar de funcionar si alguien modifica el system prompt, reordena bloques o introduce una variable dinámica en la sección estática del prompt. Sin monitoreo, ese cambio puede pasar desapercibido durante días y generar una diferencia significativa en la factura del mes.

Quinto, documenta la estructura de caché como parte del código. El orden de los bloques, los puntos de ruptura marcados con cache_control y la justificación de qué es estático y qué es dinámico deben estar en el repositorio. El conocimiento implícito sobre por qué el prompt está ordenado de cierta manera se pierde con la rotación de equipo, y reconstruirlo cuesta tiempo y dinero.

Para equipos que gestionan múltiples pipelines en paralelo, vale la pena crear una plantilla de estructura de prompt que estandarice el orden: sistema primero, referencias fijas después, input variable al final. Esa convención, aplicada de forma consistente, elimina la mayor parte de los errores de estructura antes de que lleguen a producción.

Conclusión

El prompt caching de Claude no requiere cambiar de modelo ni renegociar contratos: solo exige entender la estructura del costo y escribir prompts en el orden correcto. Con 6 semanas de ajustes incrementales, pasamos de $4.900 a $1.320 mensuales sin perder una sola llamada de producción.

El patrón que describimos aquí, identificar bloques estáticos, ordenarlos correctamente, controlar la densidad del tráfico y monitorear el hit rate, es aplicable a cualquier pipeline que use la API de Claude con volumen diario sostenido. No es una optimización exótica ni requiere infraestructura adicional. Es una decisión de arquitectura de prompts que se implementa en horas y se amortiza en días.

Si ya usas la API de Claude con volumen diario sostenido, audita cuántos de tus tokens de entrada son idénticos entre requests. Ese porcentaje es tu factura innecesaria. La documentación de patrones de optimización de costos para LLMs, incluyendo análisis comparativos de distintas estrategias, está disponible en recursos como https://a16z.com/the-new-langchain-llm-cost-optimization-patterns/, que complementa bien la documentación técnica de Anthropic para quienes quieren un marco más amplio antes de decidir qué optimizar primero.

El caching es solo una de varias palancas disponibles, pero es la de mayor impacto cuando el perfil de tokens lo justifica. Empieza por medir, luego estructura, luego monitorea. En ese orden.

¿Necesitas ayuda para construir esto?

Kreante acompaña a PyMEs y founders en LatAm que quieren reemplazar SaaS caro con IA personalizada. Hemos shipped 265+ proyectos (60% LowCode/AI, 70% B2B) en US, Europa y LatAm.

Agenda una llamada de 30 minutos con Kreante