Por Claude prompt caching: calcula cuándo sale rentable
La escritura cuesta 1.25x y la lectura 0.1x o menos. Calcula el punto de equilibrio según el modelo y compruébalo con la API de Claude.
Qué cuesta el almacenamiento en caché de prompts antes de que resulte rentable
El almacenamiento en caché de prompts permite que Claude reutilice el inicio del prompt en lugar de volver a procesarlo en cada llamada. La decisión depende de dos multiplicadores aplicados al precio base de entrada del modelo. En octubre de 2026, una escritura en caché cuesta 1.25x el precio base de entrada durante los 5 minutos de vigencia, o 2x durante 1 hora, en todos los modelos. Una lectura desde la caché cuesta 0.1x en la mayoría de los modelos, pero el multiplicador de lectura ya no es el mismo en todos. Es 0.025x en Claude Fable 5.1 y Claude Mythos 5.1, que se lanzaron con esa tarifa el 1 de septiembre de 2026. Es 0.05x en Claude Opus 5.5 y Claude Sonnet 5.5, y el precio de Sonnet 5.5 se redujo de 0.1x a esa tarifa el 7 de octubre de 2026. Los ejemplos calculados a continuación usan la lectura estándar de 0.1x. Las lecturas más baratas hacen que el punto de equilibrio sea ligeramente más favorable, y la siguiente sección muestra en qué medida.
La compensación consiste en pagar un recargo ahora para obtener un descuento después. Se paga un importe adicional una vez para almacenar un prefijo. Cada solicitud posterior que comienza con exactamente los mismos bytes paga una décima parte del precio de entrada normal por esa parte, o menos en los modelos anteriores. Si un prefijo no se reutiliza durante su periodo de vigencia, cuesta un 25 por ciento adicional sin aportar ningún beneficio.
El punto de equilibrio, en una línea de álgebra
Llamemos B al coste base de entrada del prefijo si se enviara sin caché. Sin caché, N solicitudes cuestan N veces B. Con la caché de 5 minutos, la primera solicitud escribe el prefijo a 1.25B y las otras N menos 1 solicitudes lo leen a 0.1B. Igualamos ambos costes y obtenemos 0.9N = 1.15, por lo que N = 1.28. La segunda solicitud ya es más barata que no usar caché.
Si repetimos el cálculo con la escritura a 2x de la caché de 1 hora, obtenemos 0.9N = 1.9, por lo que N = 2.11. La caché de larga duración necesita dos lecturas para alcanzar el punto de equilibrio, por eso no es la opción predeterminada.
Con lecturas más baratas, la línea cambia, pero no mucho. Con una lectura a 0.05x, la caché de 5 minutos da 0.95N = 1.2, por lo que N = 1.26, y con 0.025x da 0.975N = 1.225, también N = 1.26. La caché de 1 hora baja a N = 2.05 y N = 2.03. La respuesta práctica es la misma en todos los modelos: la caché de 5 minutos resulta rentable desde la segunda solicitud y la caché de 1 hora desde la tercera.
El gráfico siguiente calcula estos costes para un prefijo de 20,000 tokens en Claude Opus 5. Su tarifa base de entrada es de $5 por millón de tokens a fecha de octubre de 2026, sin cambios desde agosto. Opus 5 es ahora un modelo antiguo, aunque sigue disponible. Su sucesor, Claude Opus 5.5, indica $4 por millón con una lectura a 0.05x, por lo que el mismo prefijo cuesta allí $0.10 al escribirlo y $0.004 al leerlo. Multiplique todas las cifras por 0.6 para un modelo de $3 por millón con la lectura estándar a 0.1x. La forma de la curva no cambia.
Los datos de este gráfico
[
{
"requests": 1,
"uncached_usd": "0.10",
"cached_5m_usd": "0.125",
"cached_1h_usd": "0.20"
},
{
"requests": 2,
"uncached_usd": "0.20",
"cached_5m_usd": "0.135",
"cached_1h_usd": "0.21"
},
{
"requests": 3,
"uncached_usd": "0.30",
"cached_5m_usd": "0.145",
"cached_1h_usd": "0.22"
},
{
"requests": 5,
"uncached_usd": "0.50",
"cached_5m_usd": "0.165",
"cached_1h_usd": "0.24"
},
{
"requests": 10,
"uncached_usd": "1.00",
"cached_5m_usd": "0.215",
"cached_1h_usd": "0.29"
},
{
"requests": 20,
"uncached_usd": "2.00",
"cached_5m_usd": "0.315",
"cached_1h_usd": "0.39"
}
]Una sola solicitud cuesta $0.10 sin caché y $0.125 con caché, por lo que almacenar en caché una solicitud de un solo uso supone una pérdida neta. En la segunda solicitud, la caché de 5 minutos cuesta $0.135, frente a $0.20. La caché de 1 hora todavía queda por encima en ese punto: $0.21, frente a los mismos $0.20. Solo queda por debajo del coste sin caché en la tercera solicitud: $0.22, frente a $0.30. Con 20 solicitudes, la diferencia es de $2.00 frente a $0.315.
Un acierto de caché también actualiza la entrada. Por eso la tabla de precios publicada denomina esa columna aciertos y actualizaciones de caché. Un endpoint con mucha actividad mantiene una entrada de 5 minutos activa indefinidamente a precios de lectura. La duración de 1 hora solo compensa su escritura a 2x cuando el tráfico tiene pausas reales.
El coste de una tasa de aciertos baja
El tráfico real produce fallos de caché. Una solicitud que no encuentra una entrada en la caché, pero que aún contiene un punto de corte, se factura como una escritura. Por eso, la forma correcta de modelarlo es expresar el coste como una función de la tasa de aciertos. El gráfico siguiente lo muestra para 1,000 solicitudes, cada una con el mismo prefijo de 20,000 tokens.
Los datos de este gráfico
[
{
"hit_rate_percent": 0,
"cost_5m_usd": "125.00",
"cost_1h_usd": "200.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 25,
"cost_5m_usd": "96.25",
"cost_1h_usd": "152.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 50,
"cost_5m_usd": "67.50",
"cost_1h_usd": "105.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 75,
"cost_5m_usd": "38.75",
"cost_1h_usd": "57.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 90,
"cost_5m_usd": "21.50",
"cost_1h_usd": "29.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 95,
"cost_5m_usd": "15.75",
"cost_1h_usd": "19.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 99,
"cost_5m_usd": "11.15",
"cost_1h_usd": "11.90",
"uncached_usd": "100.00"
}
]Con una tasa de aciertos del 0 por ciento, paga $125.00 en lugar de $100.00, y la caché de 1 hora duplica la factura hasta $200.00. Al resolver 1.25 menos 1.15h = 1, la caché de 5 minutos empieza a ahorrar dinero con una tasa de aciertos de aproximadamente el 22 por ciento. Por eso, con un 25 por ciento ya muestra $96.25. El mismo cálculo con la escritura 2x da aproximadamente un 53 por ciento para la caché de 1 hora. Por tanto, una tasa de aciertos del 50 por ciento aún cuesta $105.00, por encima de la línea sin caché. Con un 90 por ciento, los dos valores quedan en $21.50 y $29.00. Con un 99 por ciento, la caché corta llega a $11.15, cerca del mínimo de una décima parte del precio sin caché.
En un modelo con una lectura de 0.05x, los umbrales bajan a aproximadamente el 21 por ciento para la caché de 5 minutos y el 51 por ciento para la caché de 1 hora. Con una lectura de 0.025x, bajan a aproximadamente el 20 y el 51 por ciento. El mínimo disminuye con el precio de lectura, hasta una vigésima o una cuadragésima parte del coste sin caché.
La tasa de aciertos es el valor que debe instrumentar, porque es la única entrada que puede controlar una vez fijado el tamaño del prefijo.
Qué prefijos merecen un breakpoint
Una solicitud puede incluir hasta cuatro breakpoints de caché. Por tanto, la cuestión es qué bloques merecen uno. Los candidatos son bloques idénticos byte a byte entre solicitudes y lo bastante grandes como para tener impacto. El gráfico siguiente calcula el coste de cuatro estructuras habituales en 1,000 solicitudes, con una tasa de aciertos del 90 por ciento en la caché de 5 minutos.
Los datos de este gráfico
[
{
"label": "System prompt",
"prefix_size_tokens": "2,000",
"uncached_usd": "10.00",
"cached_usd": "2.15",
"saved_usd": "7.85"
},
{
"label": "System plus tools",
"prefix_size_tokens": "8,000",
"uncached_usd": "40.00",
"cached_usd": "8.60",
"saved_usd": "31.40"
},
{
"label": "Policy document",
"prefix_size_tokens": "25,000",
"uncached_usd": "125.00",
"cached_usd": "26.88",
"saved_usd": "98.12"
},
{
"label": "Codebase context",
"prefix_size_tokens": "120,000",
"uncached_usd": "600.00",
"cached_usd": "129.00",
"saved_usd": "471.00"
}
]Un prompt de sistema básico de 2,000 tokens ahorra $7.85 por cada 1,000 solicitudes frente a los $10.00 sin caché. Es un ahorro real a gran escala, pero no es lo que hace interesante la caché. Si añade las definiciones de herramientas, llega a 8,000 tokens y ahorra $31.40. Un documento de políticas de 25,000 tokens sobre el que todas las solicitudes hacen preguntas ahorra $98.12. La última fila es la que cambia la arquitectura: 120,000 tokens de contexto del código base o de la transcripción cuestan $600.00 sin caché y $129.00 con caché, lo que supone un ahorro de $471.00.
El ahorro aumenta con el tamaño del prefijo y con la tasa de aciertos, y con ningún otro factor. Esto cambia qué merece la pena incluir en un prompt: cuánto cuestan realmente un millón de tokens de Claude pasa a costar una décima parte del precio indicado, o menos en los modelos con lecturas más baratas, para todo lo que envíe más de una vez.
Cómo se refleja en una factura mensual
El gráfico siguiente toma el prefijo de 8,000 tokens indicado arriba, junto con un prompt de sistema y las definiciones de las herramientas, con una tasa de aciertos del 90 por ciento, y lo extrapola a volúmenes mensuales de solicitudes.
Los datos de este gráfico
[
{
"label": "10k requests",
"uncached_usd": "400.00",
"cached_usd": "86.00",
"saved_usd": "314.00"
},
{
"label": "100k requests",
"uncached_usd": "4,000.00",
"cached_usd": "860.00",
"saved_usd": "3,140.00"
},
{
"label": "1M requests",
"uncached_usd": "40,000.00",
"cached_usd": "8,600.00",
"saved_usd": "31,400.00"
}
]Con 10,000 solicitudes al mes, el ahorro es de $314.00, es decir, la diferencia entre $400.00 y $86.00. Con 100,000 solicitudes, el ahorro es de $3,140.00. Con un millón de solicitudes, el coste de entrada sin caché es de $40,000.00, y la caché elimina $31,400.00 de ese coste. Estas cifras corresponden sólo a tokens de entrada. La salida se factura por separado y la caché no cambia su coste. Téngalo en cuenta antes de prometer a alguien una reducción del 90 por ciento en la factura. La caché complementa las prácticas generales descritas en mantener bajo control la factura de un agente de IA en un VPS.
Cómo demostrar que la caché funciona
No confíe en el diseño. Lea el bloque de uso de la respuesta. Cada respuesta de la Messages API (interfaz de programación de aplicaciones) informa de los tokens almacenados en caché, los tokens leídos de la caché y los tokens nuevos que tuvo que procesar.
from anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
model="claude-opus-5",
max_tokens=512,
system=[
{
"type": "text",
"text": POLICY_DOCUMENT,
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": question}],
)
u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)Ejecútelo dos veces con el mismo documento y una pregunta diferente. La primera llamada informa de un valor cache_creation_input_tokens distinto de cero y un valor cache_read_input_tokens igual a cero. La segunda invierte esos valores porque se encontró el prefijo. input_tokens sólo cuenta los tokens posteriores al último punto de interrupción, por lo que en una segunda llamada correcta es pequeño, normalmente sólo el nuevo mensaje del usuario. Ambas llamadas se facturan porque la Claude API no tiene nivel gratuito, aunque para el prefijo de 20,000 tokens indicado arriba, el par cuesta aproximadamente catorce centavos.
La misma comprobación desde el shell, con un cuerpo de solicitud guardado en request.json:
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d @request.json | jq '.usage'Una segunda llamada correcta muestra algo parecido a esto:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}Una línea muestra la situación real. Si cache_read_input_tokens permanece en 0 entre llamadas, paga el coste de escritura de 1.25x cada vez y no obtiene nada a cambio.
Para la duración de 1 hora, el punto de interrupción incluye un tiempo de vida (TTL):
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}También existe el almacenamiento automático en caché: un único campo cache_control en el nivel superior de la solicitud, después del cual la API administra los puntos de interrupción a medida que crece la conversación. Consume uno de los cuatro espacios disponibles para puntos de interrupción. Empiece por esta opción. Cambie a puntos de interrupción explícitos cuando necesite decidir exactamente dónde se sitúa el límite.
La regla de orden que destruye las tasas de aciertos
La caché compara un prefijo byte por byte desde el inicio de la solicitud, y la solicitud se ensambla en un orden fijo: herramientas, sistema y mensajes. Un cambio en cualquier nivel invalida ese nivel y todo lo que viene después. Si edita la descripción de una herramienta, se invalidan también el prompt del sistema y todo el historial de mensajes, aunque no los haya modificado.
Esto establece una regla sin excepciones. Todo lo que cambie entre llamadas debe ir después de todo lo que no cambie.
El culpable habitual es una marca de tiempo. Una línea con Current time: 2026-08-03T14:07:11Z al principio de un prompt del sistema garantiza una tasa de aciertos del 0 %, porque el hash del prefijo cambia en cada llamada y ninguna entrada anterior puede coincidir con él. Muévala al mensaje del usuario, al final. Un identificador de sesión o un nonce por solicitud rompen la caché de la misma forma y tienen la misma solución. Los documentos recuperados que cambian en cada solicitud también deben ir después del bloque en caché; de lo contrario, colocan todos los tokens estables detrás de un límite que cambia.
El segundo problema es colocar el punto de corte en el bloque que cambia. Las escrituras en la caché se realizan en ese punto, por lo que, si el bloque es diferente cada vez, nunca se almacena nada estable y la búsqueda hacia atrás sólo encuentra entradas que las solicitudes anteriores escribieron en sus propios puntos de corte variables. Coloque cache_control en el último bloque cuyo contenido sea idéntico entre solicitudes.
El tercero es un cambio de parámetros que no consideraba parte del contenido del prompt. Cada modelo tiene una caché diferente. Cambiar tool_choice invalida el historial de mensajes, aunque las herramientas y el prompt del sistema sigan en la caché. Añadir o quitar una herramienta lo invalida todo.
El prefijo mínimo y la operación silenciosa sin efecto
Un prefijo más corto que el mínimo del modelo no se almacena en caché y no se muestra ninguna indicación. No se produce ningún error ni advertencia. La solicitud se completa y ambos contadores muestran 0. En octubre de 2026, los mínimos publicados son:
- 512 tokens en Claude Opus 5 y Claude Fable 5, y en las versiones más recientes Opus 5.5, Sonnet 5.5, Fable 5.1 y Haiku 5.5
- 1,024 tokens en Claude Sonnet 5 y Claude Opus 4.8
- 4,096 tokens en Claude Haiku 4.5
Si ambos contadores muestran 0 en una solicitud que cree que está almacenada en caché, compruebe primero la longitud del prefijo. Esta es también la razón por la que el modelo más barato no es automáticamente el más barato para una carga de trabajo con almacenamiento en caché. Haiku 4.5 necesita un prefijo ocho veces más largo que Opus 5 para que el almacenamiento en caché se active, por lo que una indicación del sistema de 2,000 tokens se almacena en caché con uno y se ignora silenciosamente con el otro.
Dónde almacena Claude Code la caché para usted y dónde no puede ayudar
Claude Code almacena en caché su propio prefijo. El system prompt y las definiciones de las herramientas aparecen al principio de cada solicitud y no cambian, por lo que se escriben una vez y se reutilizan durante el resto de la sesión. Por eso, el coste por turno de una sesión larga es muy inferior a lo que sugiere el tamaño del contexto. Esto se refleja en los contadores descritos en cómo informa Claude Code del uso de tokens.
No puede ayudarle cuando cambia una parte cercana al principio del contexto. El historial de la conversación sólo admite adiciones, por lo que los turnos nuevos normales amplían un prefijo que ya está en la caché. Editar un archivo que se leyó al principio de la sesión no rompe este mecanismo, porque Claude Code añade una nota indicando que el archivo ha cambiado en lugar de volver a escribir la lectura anterior. Lo que sí lo rompe es cambiar de modelo, porque cada modelo tiene su propia caché. Conectar un servidor MCP cuyas herramientas se cargan en el prefijo también lo rompe, al igual que compactar la conversación. Cada una de estas acciones hace que el siguiente turno vuelva a escribir el prefijo. Un intervalo largo de inactividad produce el mismo efecto, porque la entrada caduca y el siguiente turno debe pagar una escritura completa. Ninguna de estas situaciones es un error. Son el funcionamiento normal de la regla del prefijo.
Si escribe su propio cliente, aplique esta estructura desde la primera solicitud en lugar de adaptarla después. Construya la llamada como se hace en una primera aplicación de Claude API en un VPS, con los bloques estables al principio y los volátiles al final.
Modos de fallo y qué verá
Cada llamada es una escritura. cache_creation_input_tokens es distinto de cero en todas las solicitudes, mientras cache_read_input_tokens permanece en 0. Algo situado en el punto de interrupción o antes de él cambia entre las llamadas. Muestre los primeros 200 caracteres del prefijo ensamblado en dos solicitudes consecutivas y compárelos visualmente.
Ambos contadores son 0. El prefijo no alcanza el mínimo del modelo o el campo cache_control nunca llegó a la API. Cuente primero los tokens del prefijo y, después, registre el cuerpo de la solicitud que envió realmente.
Las lecturas funcionan y después se detienen. Se produce una serie de aciertos, después una escritura y luego vuelven los aciertos. El intervalo entre solicitudes superó la duración de vida. Acepte la escritura o cambie al TTL de 1 hour cuando haya comprobado que la tasa de aciertos supera el 53 por ciento, o aproximadamente el 51 por ciento en un modelo con una lectura de 0.05x o 0.025x.
La tasa de aciertos disminuye después de un despliegue. Se editó la descripción de una herramienta o se cambió el modelo. Ambas acciones invalidan todo el prefijo. Espere una ronda inicial costosa de escrituras después de cada despliegue que modifique el prompt.
La factura aumentó después de activar el almacenamiento en caché. La tasa de aciertos está por debajo del punto de equilibrio. Por debajo de aproximadamente el 22 por ciento en la caché de 5 minutos, enviar el prefijo sin caché resulta más barato. En la caché de 1 hour, ocurre lo mismo por debajo de aproximadamente el 53 por ciento. En los modelos con lecturas más baratas, esos umbrales se sitúan aproximadamente en el 20-21 por ciento y el 51 por ciento.
FAQ
¿Cuántas veces se debe reutilizar un prompt para que el almacenamiento en caché resulte rentable?
Una vez, con la caché de 5 minutos. Una escritura cuesta 1.25x el precio base de entrada y una lectura cuesta 0.1x en la mayoría de los modelos. Por tanto, N solicitudes sin caché cuestan N, mientras que N solicitudes con caché cuestan 1.25 más 0.1 por N menos 1. Los dos costes se igualan en N = 1.28, por lo que la segunda solicitud ya resulta más barata. En los modelos con lecturas a 0.05x o 0.025x, el punto de equilibrio es N = 1.26, lo que da el mismo resultado. La caché de 1 hora escribe a 2x y alcanza el punto de equilibrio en N = 2.11, o aproximadamente 2.05 con las lecturas más baratas, por lo que necesita dos lecturas.
¿Por qué cache_read_input_tokens siempre vale cero?
Compruebe primero la longitud del prefijo: por debajo del mínimo del modelo, 512 tokens en Claude Opus 5 y 4,096 en Claude Haiku 4.5 a fecha de octubre de 2026, el almacenamiento en caché se omite de forma silenciosa y ambos contadores muestran 0. Si el prefijo tiene la longitud suficiente, busque contenido que cambie entre llamadas y que esté en el punto de corte o antes de él, como una marca de tiempo o un identificador de sesión en el prompt del sistema. Si los contadores funcionaban y dejaron de hacerlo, el intervalo entre solicitudes fue superior a la duración de la caché.
¿El almacenamiento en caché de prompts cambia las respuestas de Claude?
No. La caché almacena la forma procesada de los tokens que ya envió, y el modelo recibe el mismo prompt en ambos casos. Es una función de facturación y latencia, no un cambio de comportamiento. Esto también significa que puede habilitarla en un prompt que ya funciona sin volver a ejecutar sus evaluaciones.
¿Debo pagar por la caché de 1 hora?
Sólo cuando el tráfico tenga intervalos superiores a 5 minutos y la tasa de aciertos siga superando aproximadamente el 53 por ciento, o cerca del 51 por ciento en un modelo con lecturas más baratas. En un fallo de caché, la escritura a 2x cuesta cuatro veces más que la escritura a 1.25x. Una escritura fallida de 1 hora desperdicia el precio base de entrada completo del prefijo, mientras que una escritura fallida de 5 minutos sólo desperdicia una cuarta parte. Una entrada de 5 minutos se actualiza con cada acierto, por lo que el tráfico constante la mantiene activa con precios de lectura sin pagar nunca por una duración mayor.