Claude Prompt Caching: reduce coste y latencia
Aprende Claude Prompt Caching para reducir coste y latencia de la API con caché automática, TTL de 5 minutos y 1 hora, métricas y ejemplos.
Claude Prompt Caching permite reutilizar grandes prefijos de prompts, documentos, tools e historial para reducir procesamiento repetido, costes y tiempo hasta el primer token.
Claude Prompt Caching: cómo reducir coste y latencia de la API
Aprende a reutilizar instrucciones, documentos, tools e historial para evitar que Claude procese el mismo contexto completo en cada solicitud.
Claude Prompt Caching permite reutilizar una parte estable del prompt entre diferentes llamadas a la API. Por tanto, resulta especialmente útil cuando tu aplicación envía instrucciones largas, documentos, ejemplos, tools o conversaciones que cambian poco entre solicitudes.
Sin caché, Claude debe volver a procesar todo ese contexto. En cambio, un cache hit reutiliza el prefijo ya procesado. Como resultado, puedes reducir el coste de input y mejorar el tiempo hasta el primer token.
Además, Anthropic ofrece actualmente dos formas de configurarlo: caché automática y breakpoints explícitos. Ambas utilizan la misma infraestructura, aunque resuelven casos diferentes.
Qué es Claude Prompt Caching
Prompt Caching almacena temporalmente un prefijo del prompt. Después, solicitudes posteriores pueden reutilizarlo si ese prefijo sigue siendo idéntico.
Por ejemplo, una aplicación puede tener 30,000 tokens de documentación interna y solamente 50 tokens nuevos por pregunta. Sin caché, el sistema procesa los 30,050 tokens una y otra vez. Sin embargo, con un cache hit gran parte del contexto puede reutilizarse.
Asimismo, la función puede trabajar con tools, system messages, mensajes de texto, imágenes, documentos y resultados de herramientas, según el tipo de bloque compatible.
+ documentos + tools
prefijo reutilizable
+ respuesta
Cómo funciona Prompt Caching paso a paso
En primer lugar, cuando habilitas la caché, Anthropic comprueba si el prefijo correspondiente ya existe. Si lo encuentra, realiza una lectura. En cambio, si no existe, procesa el contenido y crea una entrada nueva cuando empieza la respuesta.
Envías la primera solicitud
Claude procesa el contenido completo. Además, escribe el prefijo marcado dentro de la caché.
Repites el mismo prefijo
En la siguiente llamada, el sistema busca una entrada que coincida con el contenido estable.
Claude reutiliza la caché
Si existe un match, los tokens del prefijo aparecen como
cache_read_input_tokens.
Solo procesa el contenido nuevo
Por tanto, la parte variable puede ser mucho menor que el contexto total.
tools → system → messages. Por eso, conviene colocar
al principio lo que cambia con menor frecuencia.Cuánto puede reducir el coste Claude Prompt Caching
Anthropic utiliza multiplicadores diferentes para lectura y escritura. Por ello, escribir una caché cuesta más que un input normal. Sin embargo, las lecturas posteriores cuestan mucho menos.
Ejemplo sencillo de ahorro
Imagina que un contexto estable contiene 100,000 tokens y recibe diez preguntas durante la vida de la caché. La primera llamada crea la entrada. Después, las siguientes pueden reutilizar esos 100,000 tokens.
En consecuencia, el ahorro puede ser considerable cuando existe mucha repetición. En cambio, un prompt pequeño que solamente se usa una vez normalmente no se beneficia de la misma forma.
El beneficio depende de frecuencia, tamaño del prefijo, modelo, TTL y número de cache hits. Mide tu workload real antes de asumir un porcentaje fijo de ahorro.
Cómo activar la caché automática en Claude API
En términos generales, la caché automática es la forma más sencilla de empezar. Solo necesitas
añadir cache_control a nivel superior de la petición.
Después, Anthropic coloca automáticamente el breakpoint en el último bloque cacheable. Además, en conversaciones de varios turnos el punto avanza conforme crece el historial.
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=700,
cache_control={
"type": "ephemeral"
},
system=(
"Eres un asistente experto en documentación técnica. "
"Responde con precisión y utiliza únicamente el contexto disponible."
),
messages=[
{
"role": "user",
"content": "Resume los puntos principales del documento."
}
]
)
print(response.content[0].text)
print(response.usage)Este enfoque funciona bien cuando el historial crece de forma natural. Sin embargo, puede fallar si el último bloque cacheable cambia en cada petición. Por ejemplo, un timestamp variable puede impedir que coincida el prefijo esperado.
Cuándo utilizar breakpoints explícitos
Por otra parte, los breakpoints explícitos ofrecen más control. En lugar de permitir que
Anthropic elija el último bloque cacheable, colocas cache_control
exactamente donde termina el contenido reutilizable.
Por ejemplo, puedes cachear un manual grande y dejar fuera la pregunta del usuario. Así, cada solicitud mantiene el mismo prefijo.
import anthropic
client = anthropic.Anthropic()
DOCUMENTATION = """
[DOCUMENTACIÓN LARGA DEL PRODUCTO]
...
"""
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=700,
system=[
{
"type": "text",
"text": (
"Eres un asistente de soporte. "
"No inventes información."
)
},
{
"type": "text",
"text": DOCUMENTATION,
"cache_control": {
"type": "ephemeral"
}
}
],
messages=[
{
"role": "user",
"content": "¿Cómo cancelo una suscripción?"
}
]
)
print(response.content[0].text)
print(response.usage)Caché automática
- Configuración más simple
- Buena para conversaciones crecientes
- El breakpoint avanza automáticamente
- Menos código de mantenimiento
Breakpoints explícitos
- Mayor control del prefijo
- Útil para contenido estático
- Permite varias zonas de caché
- Evita incluir datos variables por error
TTL de 5 minutos vs caché de 1 hora
De forma predeterminada, Prompt Caching utiliza un TTL de cinco minutos. Además, cada lectura vuelve a refrescar esa entrada sin coste adicional de escritura.
Por tanto, el TTL corto funciona muy bien en aplicaciones con solicitudes frecuentes. Por ejemplo, un chatbot activo puede mantener su contexto caliente mientras el usuario continúa conversando.
Cómo activar el TTL de 1 hora
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=700,
cache_control={
"type": "ephemeral",
"ttl": "1h"
},
system="Contexto largo que reutilizaremos.",
messages=[
{
"role": "user",
"content": "Analiza el primer punto."
}
]
)| TTL | Ventaja | Coste de escritura | Cuándo elegirlo |
|---|---|---|---|
| 5 minutos | Más económico para workloads frecuentes | 1.25× input base | Chats activos, agentes y tráfico constante |
| 1 hora | Sobrevive a pausas más largas | 2× input base | Usuarios intermitentes, side-agents y procesos largos |
Finalmente, recuerda que ambos TTL ofrecen el mismo tipo de mejora de latencia. La diferencia principal está en cuánto tiempo quieres conservar la entrada antes de necesitar una nueva escritura.
Cómo comprobar si Claude Prompt Caching está funcionando
De hecho, no necesitas adivinar si existe un cache hit. Anthropic expone métricas
dentro del objeto usage de cada respuesta.
cache_creation_input_tokensTokens que se escribieron en una nueva entrada de caché
cache_read_input_tokensTokens recuperados desde una entrada existente
input_tokensTokens de input que quedaron después del último breakpoint
usage = response.usage
print(
"Cache write:",
usage.cache_creation_input_tokens
)
print(
"Cache read:",
usage.cache_read_input_tokens
)
print(
"Uncached input:",
usage.input_tokens
)
total_input = (
usage.cache_creation_input_tokens
+ usage.cache_read_input_tokens
+ usage.input_tokens
)
print("Total input:", total_input)Si las dos métricas de caché permanecen en cero, comprueba primero la longitud mínima requerida por el modelo. Después, revisa que el prefijo realmente sea idéntico entre solicitudes.
Cuándo merece la pena utilizar Prompt Caching
El beneficio aumenta cuando una parte grande del input se repite. Por tanto, no todos los workloads necesitan la misma configuración.
Documentos largos
Manuales, contratos, políticas y repositorios de información que se consultan repetidamente.
System prompts grandes
Instrucciones complejas con reglas, ejemplos y criterios que cambian pocas veces.
Agentes
Tools y contexto que se reutilizan mientras el agente completa varios pasos.
Chats largos
Conversaciones donde gran parte del historial permanece igual entre un turno y el siguiente.
Few-shot prompts
Prompts con numerosos ejemplos que se envían una y otra vez.
Muchas tools
Definiciones de herramientas extensas que permanecen estables durante múltiples ejecuciones.
Qué puede invalidar la caché de Claude
En primer lugar, Prompt Caching depende de un prefijo idéntico. Por tanto, cualquier cambio relevante antes del breakpoint puede obligar a crear una nueva entrada.
| Cambio | Riesgo | Qué hacer |
|---|---|---|
| Timestamp variable | El hash cambia en cada petición | Colócalo después del breakpoint |
| Pregunta del usuario | Convierte el prefijo en variable | Cachea antes del mensaje nuevo |
| Tools modificadas | Pueden invalidar capas posteriores | Mantén definiciones estables cuando sea posible |
| tool_choice | Puede invalidar la caché | Evita cambiarlo sin necesidad |
| Imágenes | Su presencia o ausencia puede invalidar entradas | Mantén la estructura consistente |
| Configuraciones de thinking | El comportamiento depende del modelo | Revisa la documentación de tu modelo |
No pongas el breakpoint sobre un bloque que cambia en cada solicitud. En ese caso, puedes pagar escrituras repetidas sin conseguir cache hits.
Prompt Caching para agentes y conversaciones largas
Por ejemplo, los agentes suelen reutilizar instrucciones, tools e historial durante varios pasos. Por ello, Prompt Caching puede ser especialmente valioso en workflows agentic.
Además, la caché automática puede mover el punto de caché conforme crece la conversación. Así, el sistema reutiliza el historial anterior y procesa principalmente los turnos recientes.
Sin embargo, Anthropic utiliza una ventana de búsqueda de 20 bloques por breakpoint. Por tanto, conversaciones que añaden muchos bloques por turno pueden necesitar breakpoints adicionales.
Precalentar una caché antes del tráfico
Para workloads con un system prompt muy grande, Anthropic también documenta una estrategia de pre-warming. Primero envías una solicitud que construye la entrada. Después, las solicitudes reales pueden beneficiarse de ella.
SYSTEM_PROMPT = [
{
"type": "text",
"text": LONG_SYSTEM_PROMPT,
"cache_control": {
"type": "ephemeral"
}
}
]
client.messages.create(
model="claude-sonnet-5",
max_tokens=0,
system=SYSTEM_PROMPT,
messages=[
{
"role": "user",
"content": "warmup"
}
]
)No obstante, el TTL continúa aplicándose. Por eso, un pre-warm solo tiene sentido cuando esperas tráfico posterior dentro de esa ventana.
Longitud mínima para que la caché funcione
Además, Anthropic define un mínimo de tokens según el modelo. Si el contenido queda por debajo de ese mínimo, la API procesa la petición normalmente y no genera un error.
Por ejemplo, Claude Sonnet 5 requiere actualmente al menos 1,024 tokens cacheables. En cambio, otros modelos pueden utilizar umbrales distintos.
cache_creation_input_tokens y
cache_read_input_tokens son ambos cero, verifica primero
el mínimo correspondiente al modelo.Buenas prácticas para reducir coste y latencia
- Coloca primero las tools y reglas que cambian con menor frecuencia
- Mantén el contexto estable antes del breakpoint
- Coloca timestamps y datos por solicitud después de la parte cacheada
- Usa caché automática para conversaciones sencillas y crecientes
- Usa breakpoints explícitos cuando necesites controlar el prefijo
- Elige 5 minutos cuando el tráfico sea frecuente
- Considera 1 hora cuando existan pausas largas entre solicitudes
- Revisa las métricas de usage después de desplegar
- No añadas breakpoints sin una razón clara
- Comprueba el mínimo de tokens del modelo
- Mantén la estructura JSON estable entre peticiones
- Prueba cache hits antes de calcular ahorros
- Mide también time-to-first-token, no solo precio
- Revisa documentación cuando cambies de modelo
Errores frecuentes con Claude Prompt Caching
Cachear contenido demasiado corto
La petición funciona, pero no crea una entrada. Por tanto, revisa los campos de usage antes de asumir que existe caché.
Modificar el prefijo en cada llamada
Incluso un pequeño timestamp puede cambiar el hash. En consecuencia, mueve los datos variables después del breakpoint.
Enviar solicitudes paralelas demasiado pronto
Una entrada queda disponible cuando empieza la primera respuesta. Por eso, espera ese momento antes de depender del cache hit.
Elegir 1 hora para todo
La escritura extendida cuesta más. Por tanto, úsala cuando la ventana adicional realmente evite nuevas escrituras.
No monitorizar cache reads
Sin métricas no sabes si la arquitectura funciona. Además, puedes perder ahorro durante semanas sin detectarlo.
Ejemplo de arquitectura recomendada
+ documentos
Cache
y respuestas
De este modo, esta separación mantiene el contexto estable al principio. Mientras tanto, la parte específica de cada usuario permanece al final. Por tanto, el sistema maximiza las posibilidades de reutilización.
Cuándo NO necesitas Prompt Caching
Probablemente no aporta mucho si
- El prompt es muy pequeño
- Cada solicitud es completamente diferente
- La tarea se ejecuta una sola vez
- No alcanzas el mínimo cacheable
Probablemente sí aporta valor si
- Reutilizas documentos largos
- Tienes muchos ejemplos few-shot
- Ejecutas agentes con muchas tools
- El historial crece durante varios turnos
Preguntas frecuentes sobre Claude Prompt Caching
¿Qué es Claude Prompt Caching?
Es una función de Anthropic que permite almacenar temporalmente un prefijo del prompt para reutilizarlo en solicitudes posteriores.
¿Prompt Caching reduce el coste de Claude API?
Cuando existen cache hits, sí. Actualmente, una lectura cuesta el 10% del precio normal de tokens de entrada. Sin embargo, primero debes pagar la escritura de la entrada.
¿Prompt Caching reduce la latencia?
Además, Anthropic indica que Prompt Caching puede mejorar el tiempo de procesamiento y el time-to-first-token, especialmente con contextos largos.
¿Cuánto dura la caché?
El TTL predeterminado es de cinco minutos. Además, puedes configurar un TTL de una hora pagando una escritura más cara.
¿La caché se renueva cuando la utilizo?
Sí. Las lecturas vuelven a refrescar el TTL de la entrada sin cobrar una nueva escritura de caché.
¿Qué puedo cachear?
Por ejemplo, Anthropic admite, entre otros bloques, tools, system messages, mensajes de texto, imágenes, documentos y resultados de herramientas.
¿Qué modelos soportan Prompt Caching?
Asimismo, Anthropic indica que Prompt Caching automático y explícito está disponible en todos los modelos Claude activos. Aun así, los mínimos de tokens pueden variar por modelo.
¿Cómo sé si tuve un cache hit?
Para comprobarlo, revisa cache_read_input_tokens. Si el valor es mayor
que cero, la petición recuperó tokens desde la caché.
¿Puedo usar varios breakpoints?
Por otra parte, Anthropic permite hasta cuatro breakpoints explícitos. Esto ayuda cuando diferentes secciones cambian con frecuencias distintas.
¿La caché guarda información para siempre?
No. En cambio, el tipo actual es ephemeral y está sujeto al TTL configurado.
Conclusión
En términos generales, Claude Prompt Caching puede ser una de las optimizaciones más efectivas cuando tu aplicación reutiliza grandes cantidades de contexto. Además, su implementación básica requiere pocos cambios.
Primero, identifica qué parte del prompt permanece estable. Después, coloca ese contenido al principio y deja la información variable al final. Asimismo, elige entre caché automática y breakpoints explícitos según el nivel de control que necesites.
Finalmente, mide cache_creation_input_tokens,
cache_read_input_tokens y la latencia real. De esta forma,
podrás comprobar si la caché reduce costes de verdad en tu workload.
Fuentes oficiales consultadas
¿Quieres reducir el coste de una aplicación con Claude?
Por ello, en Zadrig Technology podemos ayudarte a optimizar Claude API, Prompt Caching, tools, MCP, bases de datos y agentes para reducir procesamiento repetido y construir aplicaciones más eficientes.
Hablar con Zadrig Technology →
