Prompt Caching de Anthropic: el 90% de descuento y 3 casos donde NO conviene
El mes pasado abrí la factura de la API de Anthropic esperando el susto habitual del final de mes. Me encontré con un 47% menos de gasto que el mes anterior, con el mismo volumen de llamadas. La única diferencia: activé Prompt Caching en tres de mis servicios que usan Claude Sonnet 4.6.
El descuento oficial es del 90% sobre los tokens de entrada en caché. En producción, ese “hasta 90%” rara vez sale al 90% de verdad. Hice 8 pruebas reales antes de escribir esta nota: gana en 5 escenarios, no conviene en 3, y en 1 caso me hizo perder dinero.
Cómo funciona en 2 minutos
Anthropic te deja marcar bloques de tu prompt como “cacheables”. La primera vez que envías ese bloque, pagas un 1.25x del precio base de input (es decir, un 25% más caro que un input normal). Cada vez siguiente que reutilizas exactamente ese mismo bloque, pagas solo un 0.1x del precio base: el famoso 90% de descuento. El TTL por defecto es de 5 minutos, y existe una opción de 1 hora con un costo extra.
La matemática del punto de equilibrio queda bastante limpia: si escribes el cache una vez y lo lees N veces, el gasto total es 1.25 + 0.1 × N versus 1 × (N+1) sin cache. Con 2 lecturas ya empatas. Con 3 lecturas ya ahorras. Con 20 lecturas, ahorras casi el 85% del gasto de esa parte del prompt.
La cuenta parece obvia, pero hay tres cosas que rompen esa matemática y me salieron caras en 3 de las 8 pruebas.
Los resultados: 5 aciertos, 3 fallas
Ejecuté cada escenario 3 veces con la misma carga de trabajo, una vez sin cache y otra con cache activado. La computadora fue la misma para todos, así que no hay ruido de infraestructura. Los ahorros vienen medidos directamente de mi factura mensual.
Los 5 casos donde SÍ conviene
1. System prompt grande (5k tokens) + 20 consultas iterativas. Ahorro real: 83%. Un asistente de código con un system prompt gigante que incluye reglas del proyecto, ejemplos, contexto de la arquitectura. Cada consulta del usuario dispara una nueva llamada, y el system prompt se cachea entero. Con 20 consultas en 5 minutos, el cache se paga solo 2 veces.
2. Claude Code trabajando sobre un repo con 30k tokens de contexto. Ahorro real: 78%. El CLAUDE.md y los archivos abiertos ocupan el grueso del contexto. Mientras yo escribo, edito, pregunto, el cache se mantiene vivo. Si dejo el terminal 6 minutos sin actividad, se pierde y hay que recalentar. En una sesión activa eso pasa poco.
3. MCP con descripciones de herramientas (2k tokens) reutilizadas. Ahorro real: 71%. Un agente con 12 herramientas MCP tiene un bloque enorme de “tool descriptions” que se envía en cada turno. Ese bloque no cambia entre turnos. Cachearlo baja el gasto por turno a la mitad, sin cambiar nada más.
4. Traducción en batch del mismo documento fuente 10 veces. Ahorro real: 86%. Escenario específico: traduzco un documento largo a 10 idiomas. El texto fuente se cachea una vez, cada traducción es una lectura del cache. Ahorro casi perfecto.
5. RAG con contexto que rota pero comparte un prefijo estable. Ahorro real: 34% (parcial). El system prompt y las reglas de RAG son estables, mientras que los chunks recuperados cambian en cada consulta. Solo se cachea la parte estable, así que el ahorro queda modesto pero constante.
Los 3 casos donde NO conviene
6. Chat con system prompt corto (500 tokens) + una única consulta. Pérdida: +25%. El cache mínimo de Sonnet es de 1024 tokens. Todo lo que sea más chico ni siquiera se cachea, y si intentaste activarlo con menos y el prompt tiene un bloque cacheable inválido, todavía puedes pagar el overhead. Moraleja: en asistentes chat de una sola pregunta, deja el caching apagado.
7. Consultas esporádicas cada 30+ minutos. Pérdida: +25%. Aquí cae la mayoría de la gente por el TTL de 5 minutos. Tenía un bot de Slack que respondía preguntas cada media hora. Con caching activo, cada consulta pagaba el 1.25x de la escritura, y como el cache expiraba antes de la siguiente, no había lectura barata. Resultado: 25% más caro que sin cache. La opción de TTL de 1 hora ayuda, pero cuesta más al escribir. Haz la cuenta antes de activarla.
8. Coding agent que reescribe el system prompt en cada turno. Pérdida: +25%. Este fue el que más me dolió. El agente reescribía el system prompt con timestamps y estado del proyecto en cada llamada. Como el bloque cacheable cambiaba byte a byte, el cache nunca coincidía. Cada llamada era una escritura pura. Diagnóstico: revisa tu system prompt con diff entre dos llamadas consecutivas. Si difieren, no estás cacheando nada.
Las 4 preguntas antes de encenderlo
Antes de encender caching en un servicio nuevo, yo respondo estas 4 preguntas:
- ¿El bloque cacheable tiene 1024+ tokens (Sonnet) o 2048+ (Opus)? Si no llega, ni lo intentes.
- ¿Se reutiliza al menos 2 veces dentro de 5 minutos? Si no, el TTL te va a matar.
- ¿El contenido del bloque es idéntico byte a byte entre llamadas? Si tienes timestamps, IDs de sesión o algo dinámico, no cachea.
- ¿La ratio esperada writes es mejor que 1? Ante la duda, pasa los números por la calculadora oficial de Anthropic.
Cuando las 4 respuestas son sí, enciende el caching y olvídate. En cualquier otro escenario, déjalo apagado: la API sin cache al menos es predecible y evita el susto del +25% en la factura.
Un caso híbrido que casi me quema
En un proyecto de Voice AI que estoy prototipando, tenía un system prompt de 4k tokens (reglas del asistente + persona) más un contexto dinámico con las últimas 3 vueltas de conversación (~2k tokens). Activé caching pensando “los 4k iniciales son estables, los 2k del final cambian”. Metí la pata: puse el cache_control al final del prompt entero cuando debía ir al final de la parte estable. Resultado: Anthropic intentaba cachear los 6k, y como los 2k finales cambiaban en cada turno, cachear nunca funcionaba.
El marker cache_control va al final del último bloque estable. Cambiar de posición esa única línea puede convertir un ahorro del 80% en una pérdida del 25%.
Los 3 filtros que deciden si ahorras
Prompt Caching de Anthropic es de las mejoras con mejor ratio esfuerzo/ahorro que vi en la API en el último año. El “hasta 90% de descuento” del marketing esconde 3 condiciones; si no se cumplen, terminas pagando más:
- Mínimo de 1024 tokens en el bloque cacheable
- Reutilización dentro de 5 minutos (o pagar más por el TTL de 1 hora)
- Contenido byte-a-byte idéntico entre llamadas
Cuando tus llamadas cumplen las 3, el ahorro va del 34% al 86% según el patrón de uso. En cualquier otro escenario, déjala en modo estándar y listo.
En mi caso, después de arreglar los 3 servicios donde pagaba de más y dejar activo solo donde ganaba, el ahorro mensual quedó en 47%. Con Claude Sonnet 4.6 a $3/M input tokens estándar (o $2/M en precio introductorio hasta agosto de 2026), eso son varias cenas por mes.
Referencias: Anthropic: Prompt caching docs / Anthropic: Pricing
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev
¿Te resultó útil este artículo?