Su agente reenvía los mismos 40.000 tokens de prompt del sistema, definiciones de herramientas y documentos de política en cada llamada. Con el precio de entrada de Claude Opus 5.5 de $4 por millón de tokens, ese prefijo cuesta $0.16 cada vez que se mueve, haya cambiado o no un solo byte desde la última solicitud.
El almacenamiento en caché de prompts es la solución, y Anthropic lo ha tasado agresivamente en Opus 5.5. Una lectura en caché cuesta $0.20 por millón de tokens frente a $4.00 por entrada nueva, un descuento del 95%. Pero una escritura en caché cuesta $5.00 por millón, lo que es más que enviar los tokens sin caché. Así que el almacenamiento en caché no es dinero gratis. Es una apuesta a que reutilizará el prefijo, y la apuesta tiene un punto de equilibrio preciso que casi nadie calcula antes de activarlo.
Este artículo desarrolla esa aritmética. La respuesta corta: con un solo prefijo, alcanza el punto de equilibrio después de 1.26 llamadas, y en estado estacionario, lo alcanza con una tasa de aciertos de caché de aproximadamente el 21%. Por debajo de eso, el almacenamiento en caché le cuesta dinero.
Vale la pena mencionar la escala primero. OpenAI reveló en su propio lanzamiento que su investigador mediano gasta más de $600 por día en agentes de codificación, con el percentil 90 por encima de los $7,000 por día. A ese volumen, una diferencia de 20 puntos porcentuales en la tasa de aciertos es un salario. Para obtener una imagen más amplia de los precios en los tres lanzamientos de septiembre, consulte nuestro análisis de la guerra de precios de modelos de septiembre de 2026.
Las tres tarifas que lo deciden todo
| Tipo de token | Tarifa de Claude Opus 5.5 por millón | Relativo a la entrada nueva |
|---|---|---|
| Entrada nueva | $4.00 | base |
| Escritura en caché | $5.00 | prima de $1.00 |
| Lectura en caché | $0.20 | ahorro de $3.80 |
| Salida | $20.00 | el almacenamiento en caché no lo afecta |
Dos hechos se desprenden directamente de esa tabla. Escribir un prefijo en la caché le cuesta $1.00 por millón más que no almacenarlo en caché en absoluto. Cada lectura posterior de ese prefijo le ahorra $3.80 por millón. El precio de salida nunca cambia, por lo que un agente que emite respuestas largas a partir de un prompt corto tiene poco que ganar aquí, mientras que uno que lee un contexto grande y estable y devuelve un veredicto corto tiene mucho que ganar.
La hoja de especificaciones completa, incluida la ventana de contexto de 1.000.000 de tokens y la salida máxima de 128.000 tokens, se encuentra en qué es Claude Opus 5.5.
El punto de equilibrio es 1.26 llamadas, no dos
Tome un prefijo de exactamente un millón de tokens y N llamadas que lo compartan, una escritura y N menos una lecturas.
uncached: N * $4.00
cached: $5.00 + (N - 1) * $0.20
4.00N = 5.00 + 0.20(N - 1)
3.80N = 4.80
N = 1.26
Necesita 1.26 llamadas para amortizar la prima de escritura. Dado que las llamadas se realizan en números enteros, eso significa: si el prefijo se lee de nuevo incluso una vez, almacenarlo en caché fue correcto. Dos llamadas ya le sitúan un 35% por delante.
| Llamadas compartiendo una escritura | Costo sin caché por 1M de prefijo | Costo en caché | Ahorro |
|---|---|---|---|
| 1 | $4.00 | $5.00 | 25% peor |
| 2 | $8.00 | $5.20 | 35% |
| 5 | $20.00 | $5.80 | 71% |
| 10 | $40.00 | $6.80 | 83% |
| 100 | $400.00 | $24.80 | 94% |
Esa tabla asume una escritura y una reutilización perfecta posterior. Los sistemas reales son más complejos, y ahí es donde entra el segundo cálculo.
En estado estacionario, el único número que importa es la tasa de aciertos
A lo largo de un día de tráfico, no se escribe una sola vez. Las cachés caducan, los prefijos se editan, llegan nuevos inquilinos. Sea h la fracción de sus tokens de prefijo servidos desde la caché. Un fallo se factura como una escritura, un acierto se factura como una lectura:
effective cost per 1M prefix tokens = $5.00 * (1 - h) + $0.20 * h
= $5.00 - $4.80h
break-even against $4.00 uncached: h = 1.00 / 4.80 = 20.8%
Veintiún por ciento es el número a recordar. Si menos de aproximadamente uno de cada cinco de sus tokens de prefijo se sirven desde la caché, activar el almacenamiento en caché empeoró su factura.
| Tasa de aciertos de caché | Costo efectivo por 1M de prefijo | Frente a $4.00 sin caché |
|---|---|---|
| 0% | $5.00 | 25% peor |
| 20.8% | $4.00 | punto de equilibrio |
| 50% | $2.60 | 35% más barato |
| 75% | $1.40 | 65% más barato |
| 90% | $0.68 | 83% más barato |
| 95% | $0.44 | 89% más barato |
| 99% | $0.25 | 94% más barato |
| 100% | $0.20 | 95% más barato |
Las dos tablas son la misma ecuación vista desde diferentes ángulos, ya que una escritura por N llamadas es una tasa de aciertos de (N-1)/N. Diez llamadas por escritura es una tasa de aciertos del 90% y ambas tablas indican el 83%.
Tres formas de solicitud, resueltas
Forma 1: agente de alta frecuencia, prefijo pequeño
Un agente de triaje de soporte con un prefijo de 40.000 tokens, un turno de usuario variable de 800 tokens, 600 tokens de salida, 10.000 llamadas al día. Asumiendo escrituras en el 3% de las llamadas, lo que da una tasa de aciertos del 97%.
| Sin caché | En caché | |
|---|---|---|
| Prefijo, 400M tokens/día | $1,600.00 | $137.60 |
| Turno variable, 8M tokens/día | $32.00 | $32.00 |
| Total de entrada por día | $1,632.00 | $169.60 |
Esto representa un 89.6% de descuento en la línea de entrada, aproximadamente $1,462 al día, o $43,800 al mes. La salida se mantiene en $120 al día de cualquier manera. Tenga en cuenta que el prefijo es de solo 40,000 tokens. El almacenamiento en caché es rentable aquí debido a la frecuencia, no al tamaño.
Forma 2: pasada única sobre un contexto de 1M
Un millón de tokens de entrada, una respuesta de salida, nunca reutilizado. Sin caché, esa llamada cuesta $4.00 de entrada. Con caché, cuesta $5.00, porque pagó por escribir un prefijo que nadie leyó. Ejecute 500 documentos al día con ese patrón y el almacenamiento en caché le costará $500 adicionales al día por nada.
Esta es la forma en que la gente se equivoca con más frecuencia, porque el contexto es enorme y el instinto es que los contextos enormes obviamente necesitan almacenamiento en caché. El tamaño es irrelevante. La reutilización es la única variable.
Forma 3: sesión de agente larga en una ventana de 1M
Ahora tome el mismo contexto de un millón de tokens y haga que un agente lo relea a lo largo de 200 turnos, que es exactamente lo que parece un bucle de tareas de 18 horas.
| Costo | |
|---|---|
| Sin caché, 200 x $4.00 | $800.00 |
| En caché, 1 escritura + 199 lecturas | $44.80 |
| En caché, 5 escrituras + 195 lecturas | $64.00 |
Incluso si la caché se enfría cuatro veces a mitad de sesión y paga cinco escrituras completas, sigue estando un 92% por debajo de la factura sin caché. Las sesiones largas son donde la tarifa de $0.20 se gana su reputación.
El error costoso: almacenar en caché la parte que cambia
Considere 5.000 documentos de 60.000 tokens cada uno, resumidos una vez cada uno detrás de un encabezado de instrucción compartido de 6.000 tokens.
| Estrategia | Costo de entrada |
|---|---|
| Sin almacenamiento en caché en absoluto | $1,320 |
| Almacenar en caché toda la solicitud, incluyendo cada documento | $1,650 |
| Almacenar en caché solo el encabezado de 6.000 tokens | $1,206 |
Almacenar en caché el límite incorrecto es un 25% peor que no almacenar en caché. Almacenar en caché el correcto es un 9% mejor. Misma función, mismas tarifas, una diferencia de $444 decidida enteramente por dónde termina el prefijo en caché.
La regla que se desprende de esto: almacene en caché la secuencia inicial más larga de bytes que sea idéntica en todas las llamadas, y ni un byte más. Si una marca de tiempo, un ID de solicitud o un documento por solicitud se encuentra dentro de su prefijo en caché, su tasa de aciertos se desploma a cero y cada llamada se factura a $5.00 en lugar de $4.00. La mecánica general de la coincidencia de prefijos se cubre en nuestro manual de almacenamiento en caché de prompts.
El 95% es una asíntota, no un descuento que recibe
El número principal es que las lecturas en caché cuestan el 5% de la entrada nueva. En realidad, nunca pagará el 5%, porque siempre pagó por al menos una escritura. Con 100 llamadas por escritura, está en el 94%. Con 10 llamadas por escritura, está en el 83%. Con 2 llamadas, está en el 35%.
Presupueste a partir de la tabla de tasas de aciertos, no del titular. Un equipo de finanzas que modela un ahorro del 95% y observa un 83% concluirá que la función está rota cuando funciona exactamente al precio establecido.
Lo que el material de lanzamiento no le dice
Tres elementos de entrada para esta aritmética no se encuentran en el material de lanzamiento de Opus 5.5 de Anthropic, y adivinar sobre ellos sería la forma más rápida de equivocarse con un presupuesto:
- Vida útil de la caché. Cuánto tiempo permanece activo un prefijo escrito determina directamente su tasa de aciertos en estado estacionario. Cada ejemplo trabajado anteriormente mantiene h constante como una suposición, no como una garantía de la plataforma.
- Longitud mínima del prefijo cacheable. Las plataformas suelen negarse a almacenar en caché prefijos muy cortos. Si el suyo está por debajo del límite, su tasa de aciertos efectiva es cero, sin importar cuán estables sean los bytes.
- Ámbito de la caché. Si un prefijo activo se comparte entre claves de API, espacios de trabajo o regiones cambia sustancialmente el recuento de escrituras en una implementación multi-inquilino.
Verifique los tres en la página de precios del proveedor antes de comprometerse con un número. Las tarifas de este artículo están publicadas. Estas tres no lo están.
Compruebe que la caché realmente está funcionando
El modo de fallo es silencioso. Nada lanza un error cuando un prefijo se enfría. Alguien añade un ID de depuración al mensaje del sistema, la tasa de aciertos cae del 97% a 0, y la única señal es una línea en una factura tres semanas después.
La API de Mensajes informa el desglose en cada respuesta:
"usage": {
"input_tokens": 812,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 40960,
"output_tokens": 604
}
En la primera llamada, `cache_creation_input_tokens` contiene el prefijo. En cada llamada posterior, ese campo debe ser 0 y `cache_read_input_tokens` debe llevar la misma carga. Guarde la solicitud una vez en Apidog, dispárela dos veces y observe qué campo se mueve.
Luego convierta esa observación en una aserción para que no pueda retroceder silenciosamente. Un escenario de prueba de Apidog que envía la solicitud dos veces y afirma `cache_read_input_tokens > 40000` en la segunda respuesta fallará en CI en el momento en que un compañero haga que el prefijo sea no determinista. Esa es una prueba de una línea que se interpone entre usted y un aumento de 25 veces en la facturación de prefijos, y es lo que ofrece el mayor rendimiento en este artículo.
Dónde se sitúa GPT-6 en la misma matemática
GPT-6 Sol lista la entrada a $2.00 por millón con un descuento del 90% en lecturas en caché, lo que sitúa una lectura en caché en $0.20 por millón, la misma cifra que Opus 5.5. GPT-6 Luna a $0.10 por millón de entrada resulta en $0.01 por millón en caché.
La diferencia es lo que podemos calcular. El material de lanzamiento de OpenAI no especifica una tasa de escritura en caché, por lo que la tasa de reutilización de equilibrio para GPT-6 no se puede derivar de la misma manera que para Opus 5.5. Que Anthropic publique un precio de escritura explícito de $5.00 es lo que hace que la cifra del 21% sea calculable en absoluto. El resto del lanzamiento de caché de OpenAI, incluidos los cambios de esfuerzo que preservan la caché y las nuevas herramientas de diagnóstico, se encuentra en nuestro artículo sobre el almacenamiento en caché de prompts de GPT-6.
Conclusión
El almacenamiento en caché de prompts en Claude Opus 5.5 es una cuestión aritmética: ¿más de una quinta parte de sus tokens de prefijo volverán activos? Si es así, actívelo y espere un 83% a 94% de descuento en la línea de entrada en lugar del 95% anunciado. Si su carga de trabajo son pases únicos sobre documentos únicos, déjelo desactivado y ahórrese la prima de escritura de $1.00 por millón. Y elija lo que elija, afirme `cache_read_input_tokens` en CI, porque una regresión de la caché nunca se anuncia.