Hace unas semanas publiqué un artículo explicando por qué el 99% de lo que envías a Claude ya está en caché. Tensores KV, VRAM, SSDs locales — toda la maquinaria interna. Pero me dejé la parte que más duele: la factura.
Porque el prompt caching es una de esas cosas que parecen un chollo hasta que miras los números de cerca. Y entonces te das cuenta de que te están cobrando por ahorrar.
La paradoja del coste
Vamos a poner números. Con Claude Sonnet:
| Concepto | Precio por millón de tokens |
|---|---|
| Input normal | $3,00 |
| Cache write | $3,75 (1,25x) |
| Cache read | $0,30 (0,10x) |
Ojo al dato: escribir en caché cuesta un 25% más que procesar el input sin caché. Estás pagando un extra por el privilegio de que la próxima vez sea más barato.
Es como pagar el Costco. La cuota anual duele. Pero si compras suficiente, compensa.
El problema es que «suficiente» depende de cuántas veces vas a leer ese caché antes de que expire.
Cuándo pierdes dinero
Imagina que envías un prompt de 100K tokens con cache_control. Primera petición:
100.000 tokens × $3,75/M = $0,375 (cache write)
Si hubieras enviado eso sin caché:
100.000 tokens × $3,00/M = $0,300 (input normal)
Has pagado $0,075 extra. Un 25% más. Has perdido dinero.
Ahora, segunda petición con los mismos 100K tokens de prefijo:
100.000 tokens × $0,30/M = $0,030 (cache read)
Frente a:
100.000 tokens × $3,00/M = $0,300 (input normal sin caché)
Te has ahorrado $0,27. En dos peticiones ya has recuperado los $0,075 extra de la escritura y estás en positivo.
El punto de equilibrio está en 1,4 lecturas. Dicho en cristiano: si vas a usar ese prefijo al menos dos veces en los siguientes 5 minutos, el caché te sale rentable.
Por qué con Claude Code es un no-brainer
En una sesión de Claude Code, cada mensaje que envías incluye el system prompt, las herramientas, y todo el historial de la conversación. Mensaje tras mensaje. Sin caché, estarías pagando $3,00/M por los mismos 150K tokens de contexto cada vez que escribes «cambia el color de este botón».
Eso no hay quien lo pague.
Con prompt caching, pagas el write una vez y luego lees a $0,30/M durante toda la conversación. En una sesión de 50 mensajes con 150K de contexto acumulado, la diferencia es brutal:
Sin caché: 50 × 150.000 × $3,00/M = $22,50
Con caché: 1 × 150.000 × $3,75/M + 49 × 150.000 × $0,30/M = $2,77
De $22,50 a $2,77. Un 88% de ahorro. Por eso Anthropic activa el caché por defecto en Claude Code. Sería económicamente inviable no hacerlo.
Lo contraintuitivo: el cache read es lo que dispara tu contador de tokens
Y aquí viene la parte que confunde a todo el mundo.
Cuando abres tu dashboard de uso y ves cacheReadInputTokens: 4.241.579.174, tu cerebro dice: «he consumido cuatro mil millones de tokens». Y técnicamente es cierto: tu cuenta ha procesado esos tokens. Pero no los ha procesado como piensas.
Un cache read no recalcula los tensores KV. Los lee de memoria. Es enormemente más barato para Anthropic que un input normal, y por eso te lo cobran a un 90% de descuento.
Pero el número es gigante comparado con todo lo demás. Mis datos reales de un mes:
cacheReadInputTokens: 4.241.579.174 (99,5%)
cacheCreationInputTokens: 196.596.243 (4,6%)
inputTokens: 1.293.019 (0,03%)
outputTokens: 2.517.666 (0,06%)
El 99,5% de los tokens que pasan por mi cuenta son cache reads. Si Anthropic decidiera cobrar los cache reads al precio normal del input, mi factura se multiplicaría por 10. Literalmente.
Esto tiene una consecuencia práctica: cuando comparas tu consumo con el de otros, cacheReadInputTokens es la métrica más inútil que existe. Alguien que hace 200 sesiones cortas y alguien que hace 10 sesiones largas pueden tener cache reads radicalmente diferentes con el mismo gasto real.
Las tres palancas que controlas
Si usas la API directamente (no Claude Code, donde Anthropic gestiona el caché por ti), hay tres cosas que puedes hacer para optimizar:
1. Ordena tu prompt de más estable a menos estable
El caché funciona por prefijo. Si cambias algo al principio, invalidas todo lo que viene después. Esto es la regla de oro:
[System prompt — nunca cambia]
[Definiciones de tools — rara vez cambia]
[Documentos de referencia — cambian de vez en cuando]
[Historial de conversación — crece con cada mensaje]
[Último mensaje del usuario — siempre nuevo]
Si metes el mensaje del usuario antes que los documentos de referencia, invalidas el caché de los documentos cada vez. Una chapuza que te cuesta dinero en cada petición.
2. Usa breakpoints de caché con cabeza
Anthropic te da hasta 4 breakpoints (cache_control) por petición. La tentación es poner uno en cada bloque. Pero cada breakpoint fuerza un cache write aunque el contenido sea idéntico al que ya estaba cacheado.
Mi recomendación: un breakpoint al final del system prompt y otro al final del historial de conversación. Dos puntos de anclaje, no cuatro.
3. Respeta el mínimo cacheable
El caché solo funciona si el bloque tiene al menos 1.024 tokens (2.048 para Opus). Si tu system prompt tiene 500 tokens, no se va a cachear. Puedes comprobarlo mirando la respuesta de la API: si cache_read_input_tokens es 0, el bloque no alcanzó el mínimo.
Lo que no puedes controlar (y no debería preocuparte)
El TTL del caché es 5 minutos en VRAM (tier estándar). Si tu usuario tarda 6 minutos en responder, hay un cache miss y se recalcula todo. No puedes hacer nada al respecto sin pagar el extended cache (1 hora de TTL, pero a 2x el precio del input).
Para conversaciones interactivas — alguien chateando con tu bot — 5 minutos suele ser suficiente. Para procesos batch con pausas largas entre peticiones, plantéate el extended cache si los prompts son largos. Haz la cuenta: ¿el 2x del write se amortiza con los reads?
El efecto psicológico
Hay un efecto secundario que nadie menciona: el caché te incentiva a hacer más peticiones, no menos. Porque sabes que cada petición adicional cuesta una fracción de la primera.
Es el mismo mecanismo que las tarifas planas de datos móviles. Cuando pasaste de pagar por MB a una tarifa ilimitada, empezaste a usar más datos. No porque necesitaras más, sino porque el coste marginal era cero.
Con prompt caching, el coste marginal de una petición adicional (si el contexto ya está cacheado) es casi solo el coste del output. Y eso cambia tu comportamiento. Empiezas a iterar más rápido. A hacer preguntas más pequeñas. A usar el modelo como un rubber duck con esteroides.
¿Es eso malo? Depende. Si tienes un techo de gasto o una cuota como Claude Max, puede ser una trampa: el coste por petición baja, pero el número de peticiones sube. Y la cuota se mide en consumo total, no en coste marginal.
En resumen
El prompt caching es una de esas optimizaciones que funcionan exactamente al revés de como tu intuición espera:
- Pagas más al principio (el cache write cuesta 1,25x).
- Pagas mucho menos después (el cache read cuesta 0,10x).
- El punto de equilibrio es ridículamente bajo (1,4 lecturas).
- Los números de consumo son engañosamente grandes (99% de tus tokens son cache reads baratos).
- El orden de tu prompt importa más de lo que crees (prefijo estable = más caché).
Si usas la API de Anthropic y no estás usando prompt caching, estás tirando dinero. Si ya lo usas y no entiendes tu factura, ahora sabes por qué: el caché te cobra el doble por ahorrarte un 90%. Y en cuanto haces las cuentas, es la mejor oferta que hay.
Relacionado: Si quieres entender la maquinaria interna (tensores KV, VRAM, hashing por prefijo), lee Por qué el 99% de lo que envías a Claude ya lo tiene en caché. Y si te interesa cómo estimo mi cuota sin acceso a la API, Tokamak: estimando cuota de Claude sin API.
Read this article in English.
