Prompt Caching en Claude: 90% menos coste por petición

Tu agente tiene un system prompt de 3.000 tokens. Lo envías en cada petición. Si haces 500 llamadas al día, pagas 1.500.000 tokens de entrada diarios — por el mismo texto, que nunca cambia.

La mayoría de equipos lo acepta como coste fijo. Es un error que se puede corregir en menos de una hora.

Prompt caching es una feature nativa de la API de Anthropic que permite marcar bloques del contexto como cacheables. La primera petición escribe el caché. Las siguientes lo leen al 10% del coste de entrada. El modelo reutiliza el estado computado — sin pérdida de calidad, sin cambios en el output.

Por qué el prompt caching importa en producción

El problema no es la calidad del agente. El problema es la estructura de costes.

En un agente de soporte con un system prompt de 3.000 tokens y 500 llamadas diarias:

• Sin caching: 1.500.000 tokens de entrada al día → ~135€/mes
• Con caching: 3.000 tokens × 500 lecturas × 10% → ~14€/mes

Mismo agente. Mismo output. Misma calidad. La diferencia es de 121€ al mes por no añadir tres líneas al código.

A escala — 5.000 llamadas diarias, system prompt más largo, múltiples herramientas — la diferencia supera los 1.000€ mensuales. Y sigue siendo el mismo agente.

Cómo implementar prompt caching en TypeScript

El cambio es mínimo. Se añade cache_control: { type: "ephemeral" } al bloque que quieres cachear:

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

const response = await client.messages.create({
  model: "claude-opus-4-7-20250514",
  max_tokens: 1024,
  system: [
    {
      type: "text",
      text: `Eres el asistente de soporte de ACME Corp.
Tu objetivo es resolver dudas sobre pedidos, devoluciones y estado de cuenta.

Reglas:
- Responde siempre en el idioma del cliente
- No ofrezcas descuentos sin autorización
- Si el caso supera tu capacidad, escala a soporte humano
[... resto del system prompt estático ...]`,
      cache_control: { type: "ephemeral" }
    }
  ],
  messages: [
    {
      role: "user",
      content: userMessage
    }
  ]
});

const { input_tokens, cache_read_input_tokens, cache_creation_input_tokens } = response.usage;

console.log(`Tokens de entrada: ${input_tokens}`);
console.log(`Cache read: ${cache_read_input_tokens}`);
console.log(`Cache write: ${cache_creation_input_tokens}`);

La primera petición activa el caché (cache_creation_input_tokens > 0). Las siguientes lo leen (cache_read_input_tokens > 0) — y ese es el número que importa: significa que estás pagando el 10%.

Dónde colocar los breakpoints para máximo ahorro

Hay tres lugares donde el caching tiene el mayor impacto:

1. System prompt largo Si tu system prompt supera 1.024 tokens (el mínimo para activar el caché), márcalo completo. Es donde más token-horas se acumulan en agentes de uso frecuente.

2. Definiciones de herramientas Si usas más de 5 tools, su definición puede sumar 2.000-4.000 tokens. Puedes cachear el bloque de tools igual que el system prompt, marcando el último elemento del array con cache_control.

3. Contexto estático de conversación (RAG) Si tu agente inyecta documentos largos que no cambian entre peticiones — manuales internos, base de conocimiento, catálogo de productos — ese contexto es candidato a caching. El bloque debe ser idéntico entre peticiones para que el caché sea efectivo.

Los errores que anulan el caching

Error 1: incluir contenido dinámico antes del breakpoint

Si algo variable (un timestamp, un ID de sesión, el nombre del usuario) aparece antes del marcador de caché, el caché se invalida en cada petición.

// ❌ Esto invalida el caché en cada llamada
const system = `Hora actual: ${new Date().toISOString()}
[... 3.000 tokens de instrucciones ...] ← el cache nunca aplica aquí`;

// ✅ El contenido dinámico va DESPUÉS del breakpoint, en el mensaje del usuario
messages: [
  {
    role: "user",
    content: `[${new Date().toISOString()}] ${userMessage}`
  }
]

Error 2: no medir los cache hits

Implementas el caching, no monitorizas nada, y no sabes si funciona. Loguea siempre cache_read_input_tokens. Si es cero en peticiones que deberían cachear, algo en el sistema prompt está cambiando entre llamadas.

Error 3: cachear prompts demasiado cortos

El mínimo para activar el caché es 1.024 tokens. Si tu system prompt tiene 500 tokens, el caching no aplica. En ese caso, la optimización correcta es la Batches API de Anthropic para procesar múltiples peticiones en paralelo a menor coste.

TTL y durabilidad del caché

El caché ephemeral dura 5 minutos. Esto significa que en agentes de baja frecuencia (menos de una petición cada 5 minutos), el caché se invalida antes de amortizarse.

Para agentes de alta frecuencia (chatbots, sistemas de soporte en tiempo real), el caching es prácticamente gratuito: la primera petición de cada ventana de 5 minutos paga la escritura, todas las demás leen. Con 500 peticiones en 5 minutos, la escritura representa el 0,2% del coste total.

Para agentes con peticiones espaciadas, evalúa si el caching aporta suficiente ahorro o si hay otras optimizaciones más efectivas.

Resultados en agentes de producción

Los agentes que construimos en DAILYMP con integración de IA que tienen prompt caching correctamente configurado muestran de forma consistente:

• 80-90% de reducción en tokens de entrada facturados
• Latencia igual o mejor: el cache hit procesa menos tokens, lo que puede reducir el tiempo de respuesta
• Sin impacto en el output: el modelo recibe exactamente el mismo contexto

La arquitectura del system prompt importa. Un prompt bien estructurado — con la parte estática al principio y la dinámica al final o en el mensaje del usuario — extrae todo el valor del caching. Un prompt mal diseñado puede tener el breakpoint en el lugar equivocado y no cachear nada relevante.

El cálculo antes de implementar

Para saber si prompt caching te conviene:

1. Mide el número de tokens de tu system prompt actual (puedes usar el endpoint de token counting de Anthropic)
2. Multiplica por el número de peticiones diarias
3. Compara el coste sin caching vs. con caching (10% en lecturas, 25% más en escrituras, que se amortizan rápido)

Si el resultado supera 20-30€/mes de ahorro, la implementación se justifica por sí sola. Si el system prompt tiene menos de 1.024 tokens, busca otra optimización.

---

Si tienes agentes en producción y todavía no usas prompt caching, probablemente estás pagando entre 50€ y 500€ más al mes de lo necesario, según tu volumen. Es un ajuste técnico pequeño con impacto directo en el P&L.

Si quieres que lo revisemos juntos y lo implementemos en tus agentes, en una semana está hecho.

Revisar los costes de mis agentes con Daily →