Prompt caching con Claude: cómo reducir el costo de tu API hasta 90%
Guía técnica del prompt caching de Anthropic (Claude): mecánica de prefijo, cache_control ephemeral, TTL de 5 minutos y 1 hora, multiplicadores de precio, código Python/TS y los errores que rompen el cache silenciosamente.
El prompt caching de Anthropic reutiliza porciones ya procesadas del prompt entre llamadas a la API, leyéndolas desde cache a una fracción del precio en vez de reprocesarlas cada vez. Leer desde cache cuesta del orden del 10% del precio de input base —de ahí el 90% de descuento sobre la porción cacheada— mientras que escribir el cache cuesta un poco más que el input normal (alrededor de 1,25x para el cache de 5 minutos y 2x para el de 1 hora). En Cognitiva, agencia chilena de IA, es la primera optimización que aplicamos en agentes con system prompt largo, RAG con contexto repetido y conversaciones multi-turno, porque baja la factura sin tocar la calidad. Este artículo explica la mecánica real (el cache es un prefijo exacto), cómo activarlo con cache_control en Python y TypeScript, cuándo conviene el TTL de 1 hora y los errores que invalidan el cache de forma silenciosa. Los precios exactos por modelo cambian: verifica siempre la página oficial de precios de Anthropic antes de proyectar ahorros.
Qué es y por qué importa
Si tu aplicación envía el mismo system prompt extenso, las mismas definiciones de herramientas o el mismo documento largo en cada llamada, estás pagando precio completo de input por reprocesar texto idéntico una y otra vez. El prompt caching guarda ese prefijo ya procesado y, en las llamadas siguientes, lo lee desde cache a una fracción del costo.
El ahorro neto depende de dos cosas: qué fracción de tu prompt es prefijo reutilizable y cuántas veces lo relees dentro de la ventana de tiempo. En cargas con prefijo grande y muchas relecturas, el ahorro sobre el costo total se ubica en el rango de 60% a 90%. No es magia: es no volver a pagar por lo que ya se procesó.
Cómo funciona: el cache es un prefijo exacto
El invariante del que se desprende todo lo demás: el cache es un prefijo exacto. La clave de cache se deriva de los bytes exactos del prompt renderizado hasta cada punto de corte. Cualquier cambio de un solo byte en cualquier parte del prefijo invalida ese punto y todo lo que viene después.
Orden de renderizado
El prompt se arma en este orden: tools, luego system, luego messages. Por eso lo más estable (definiciones de herramientas, system prompt) debe ir primero, y lo volátil (la pregunta del usuario, contexto dinámico) después. Un punto de corte al final del system cachea tools + system juntos.
Cómo se marca
Se marca con un bloque cache_control de tipo ephemeral, que es el único tipo soportado. El contenido se hashea de forma acumulativa hasta ese marcador inclusive.
{ "cache_control": { "type": "ephemeral" } }Mínimo de tokens
Hay un mínimo de tokens para que un prefijo se cachee (del orden de 1.024 tokens, y hasta 2.048 o 4.096 en algunos modelos). Prefijos más cortos se procesan sin cachear, sin error: simplemente no verás ahorro. El mínimo varía por modelo, así que confírmalo en la documentación oficial del modelo que uses.
TTL: 5 minutos o 1 hora
- **TTL por defecto: 5 minutos.** Cada vez que el contenido cacheado se reutiliza dentro de la ventana, el TTL se reinicia sin costo adicional.
- **TTL extendido: 1 hora.** Se activa agregando "ttl": "1h" dentro de cache_control. Útil para tráfico intermitente con huecos largos. Su escritura cuesta más (alrededor de 2x el input base).
- **Máximo 4 puntos de corte** (cache_control) explícitos por request.
// 5 minutos (por defecto)
{ "cache_control": { "type": "ephemeral" } }
// 1 hora
{ "cache_control": { "type": "ephemeral", "ttl": "1h" } }Regla práctica: si tu tráfico es continuo (requests cada pocos minutos), el TTL de 5 minutos basta y es más barato. El de 1 hora conviene cuando hay pausas largas entre llamadas que comparten el mismo prefijo.
Cuánto ahorra: los multiplicadores
Sobre el precio base de input, las operaciones de cache aplican estos multiplicadores (estables; los montos absolutos por modelo cambian, verifica el precio vigente):
| Operación | Multiplicador | Efecto |
|---|---|---|
| Cache write (5 min) | ~1,25x | Pagas un poco más una vez |
| Cache write (1 hora) | ~2x | Escritura más cara, dura más |
| Cache read / refresh | ~0,1x | 90% de descuento sobre lo cacheado |
Punto de equilibrio
Con TTL de 5 minutos, el cache se vuelve rentable tras un solo cache read (1,25x de escritura + 0,1x de lectura es menor que 2x sin cache para dos llamadas). Con TTL de 1 hora, la escritura duplicada exige al menos dos lecturas para amortizarse. Si vas a releer el prefijo una sola vez y rápido, el cache de 5 minutos ya conviene.
Código: system prompt, tools y documentos
System prompt extenso (Python)
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
system=[
{
"type": "text",
"text": "Prompt de sistema extenso o documento largo...",
"cache_control": {"type": "ephemeral"}, # TTL 5 min
}
],
messages=[{"role": "user", "content": "Resume los puntos clave"}],
)Tools + documento largo, corte al final del prefijo estable (Python)
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
tools=[
{"name": "buscar", "description": "...", "input_schema": {}},
{"name": "crear", "description": "...", "input_schema": {},
"cache_control": {"type": "ephemeral"}}, # cachea TODAS las tools
],
system=[
{"type": "text", "text": "Instrucciones del agente"},
{"type": "text", "text": "Documento largo de contexto",
"cache_control": {"type": "ephemeral"}}, # cachea tools + system
],
messages=[
{"role": "user", "content": "Pregunta que cambia en cada llamada"},
],
)TTL de 1 hora (TypeScript)
const response = await client.messages.create({
model: "claude-opus-4-8",
max_tokens: 1024,
system: [
{
type: "text",
text: "Documento largo de contexto...",
cache_control: { type: "ephemeral", ttl: "1h" },
},
],
messages: [{ role: "user", content: "Resume los puntos clave" }],
});Verificar que el cache realmente funciona
No asumas que el cache funciona: mídelo. La respuesta trae los tokens desglosados. Si en requests repetidos con prefijo idéntico el campo de lectura sigue en cero, hay un invalidador silencioso.
console.log(response.usage.cache_creation_input_tokens); // escritos (~1,25x)
console.log(response.usage.cache_read_input_tokens); // leidos (~0,1x)
console.log(response.usage.input_tokens); // sin cachear (precio completo)El total de input es la suma de los tres campos. La meta es maximizar cache_read_input_tokens y minimizar el input sin cachear. Conviene instrumentar esto con tu stack de observabilidad para vigilar la tasa de aciertos en producción.
Dónde más ahorra
- **Agentes con system prompt largo o muchas tools.** Las definiciones de herramientas van en posición cero del prefijo; cachear tools + system reduce el costo fijo de cada turno.
- **RAG con contexto repetido.** El documento o los ejemplos few-shot extensos como prefijo fijo, con la pregunta variable después del último punto de corte.
- **Conversaciones multi-turno.** El historial previo se relee desde cache en cada turno; los aciertos se acumulan a medida que crece la conversación.
- **Análisis de documentos largos.** El documento se cachea una vez y múltiples preguntas sobre él solo pagan cache read.
Gotchas: qué invalida el cache (a veces en silencio)
Algunos cambios invalidan el cache con error visible; otros simplemente dejan de cachear sin avisar. Los silenciosos son los que más cuestan:
- **Timestamps o fechas en el system prompt** (un Date.now() o datetime al inicio): cambian el prefijo en cada llamada y rompen el cache.
- **IDs o UUID al inicio del contenido**: mismo efecto.
- **JSON serializado sin orden estable** (sin ordenar claves) o iterar sets: la serialización no determinista cambia los bytes.
- **Contexto dinámico inyectado en el system prompt** (nombre de usuario, modo, sesión): muévelo a messages, después del prefijo estable.
- **Cambiar el modelo o las definiciones de tools**: invalida todo el prefijo. Mantén el set de tools determinista y ordenado.
- **Concurrencia.** Una entrada de cache recién es legible una vez que la primera respuesta empieza a transmitirse. Si disparas N requests idénticos en paralelo, todos pagan precio completo. En fan-out, envía uno primero, espera el primer token y luego los demás.
La disciplina es simple: el prefijo estable se mantiene congelado byte a byte; todo lo que varía va después del último punto de corte.
Preguntas frecuentes
Da el siguiente paso
Hablemos
Cuéntanos sobre tu negocio. Respondemos en 24 horas.
Otros canales
Escríbenos por WhatsApp o agenda una llamada de 30 minutos.