Guía de costos de Prompt Caching: Cache Hits, prefijos y gasto real en la API

El costo del Prompt Caching depende de tres variables: qué parte de tu prompt es un prefijo reutilizable, con qué frecuencia se repite ese prefijo dentro de la ventana activa de la caché y cómo fija el precio un proveedor determinado para las escrituras en caché frente a los aciertos de caché. Si aciertas con esos tres números, el almacenamiento en caché puede reducir significativamente tu factura de tokens de entrada en cargas de trabajo repetitivas; si te equivocas, puedes terminar pagando una prima por escritura para una caché que nunca se reutiliza.

Esta guía separa lo que documentan los proveedores, lo que puedes verificar en las superficies de API públicas y lo que deberías probar antes de comprometer el gasto de producción en una estrategia de almacenamiento en caché.

Puntos clave

• El costo del Prompt Caching tiene dos componentes: un costo de escritura (que generalmente se cobra cuando se crea una nueva entrada en la caché) y un costo de acierto (que generalmente se cobra cuando una solicitud reutiliza esa entrada). La documentación de Anthropic describe explícitamente esta distinción entre escritura y acierto; debes confirmar los multiplicadores actuales en la página de documentación antes de modelar el gasto.
• Los aciertos de caché requieren una coincidencia de prefijo exacta o casi exacta hasta un punto de interrupción definido. Reordenar las instrucciones del sistema, las definiciones de herramientas o los ejemplos de few-shot antes de ese punto de interrupción invalida la caché y fuerza una reescritura.
• Las entradas de caché caducan después de un tiempo de vida (TTL) definido por el proveedor. Si tu volumen de solicitudes para un prefijo determinado es demasiado escaso para aterrizar dentro de esa ventana, pagarás costos de escritura repetidos en lugar de acumular ahorros por aciertos.
• La documentación de OpenRouter señala que el comportamiento y los precios del Prompt Caching varían según el proveedor y el modelo subyacente, por lo que una estrategia de almacenamiento en caché que ahorra dinero en un backend no se transfiere automáticamente a otro. Verifica la compatibilidad por modelo antes de enrutar el tráfico basándote en ahorros supuestos.

Por qué te cobra realmente el Prompt Caching

El Prompt Caching permite a un proveedor de API almacenar la representación procesada de un prefijo de prompt para que las solicitudes posteriores que comparten ese prefijo omitan cálculos redundantes. El modelo de facturación que se deriva de esto no es "los tokens en caché son gratuitos". Es más parecido a "los tokens en caché son más baratos al reutilizarse, pero la primera escritura cuesta más que un token de entrada estándar".

La documentación de Prompt Caching de Anthropic establece esta estructura directamente: una solicitud que crea una nueva entrada en la caché se factura de manera diferente a una solicitud que acierta en una existente. Los multiplicadores exactos cambian con el tiempo y según el modelo, así que trata cualquier número que veas en una publicación de blog, incluida esta, como algo que debes verificar con la documentación actual en lugar de una constante fija.

La implicación práctica es que el Prompt Caching es una apuesta por la reutilización. Si tu prompt del sistema, esquema de herramientas o bloque de contexto recuperado se envía una vez y nunca se repite, el almacenamiento en caché añade una prima de escritura sin ahorros por aciertos que la compensen. Si ese mismo bloque se envía cientos de veces dentro de la ventana activa de la caché, los ahorros por aciertos pueden superar el costo de escritura por un margen amplio.

Cómo funcionan los aciertos de caché: prefijos, prefijos y puntos de interrupción

Los aciertos de caché se basan en prefijos, no en el contenido en un sentido difuso. La parte almacenada en caché de un prompt debe coincidir con la solicitud entrante token por token hasta el punto donde se establece el límite de la caché, a veces llamado punto de interrupción (breakpoint). La documentación de Anthropic describe esto como un mecanismo explícito donde los desarrolladores marcan qué parte del prompt es elegible para el almacenamiento en caché, normalmente las instrucciones estables del sistema, las definiciones de herramientas y los documentos de referencia largos que no cambian entre llamadas.

Esto tiene una consecuencia de ingeniería directa: cualquier cosa que coloques antes del punto de interrupción de la caché debe ser idéntica a nivel de byte entre solicitudes, incluidos los espacios en blanco y el orden. Un error común es intercalar variables por solicitud (como una marca de tiempo o un ID de usuario) en el prompt del sistema antes del límite de la caché. Esa única variable derrota a la caché para todo el prefijo, y pagas costos de escritura en cada llamada en lugar de acumular aciertos.

La solución es sencilla: mantén el contenido genuinamente estático (definiciones de herramientas, instrucciones de estilo de la casa, documentos de referencia grandes) en el prefijo almacenado en caché y mueve cualquier cosa específica de la solicitud al sufijo no almacenado en caché, normalmente el mensaje del usuario.

La vida útil de la caché importa tanto como el diseño del prefijo. La documentación de Anthropic describe una duración de caché predeterminada medida en minutos, con una opción de mayor duración disponible para cargas de trabajo que lo necesiten. Si tu patrón de tráfico envía un prefijo compartido una vez cada pocos minutos, una caché de corta duración puede caducar antes de que llegue la siguiente solicitud, y terminarás pagando costos de escritura repetidamente. Las cargas de trabajo de alta frecuencia (sesiones de chat, bucles de agentes, pipelines por lotes que se ejecutan uno tras otro) son candidatos mucho mejores que las llamadas esporádicas de baja frecuencia.

Modelado del gasto real en la API: un enfoque práctico

En lugar de afirmar un porcentaje de ahorro, modela tu propia carga de trabajo con la siguiente estructura. Este ejemplo ilustra la estructura de la solicitud conceptualmente; verifica los nombres de campo exactos y los precios actuales en la documentación del proveedor antes de implementarlo.

{
  "model": "claude-sonnet-5",
  "system": [
    {
      "type": "text",
      "text": "You are a support agent. Full policy document follows...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "What is the refund window for order 48213?" }
  ]
}

El marcador cache_control en el bloque del sistema indica que este contenido es un candidato para el almacenamiento en caché. La primera llamada en una sesión paga el costo de escritura por ese bloque. Cada llamada posterior dentro de la ventana activa de la caché que reutilice el prefijo idéntico paga la tarifa de acierto en lugar de la tarifa de entrada completa por esos tokens.

Para estimar si vale la pena implementarlo para tu servicio, reúne cuatro números de tus propios registros:

1. Tamaño del prefijo: el recuento de tokens del contenido estable que pretendes almacenar en caché (prompt del sistema, esquema de herramientas, documento de referencia).
2. Frecuencia de llamadas dentro de la ventana TTL: cuántas solicitudes reutilizan ese prefijo exacto dentro de la duración activa de la caché.
3. Tarifas de escritura y acierto: extraídas de la documentación actual del proveedor, no supuestas de memoria.
4. Variabilidad del sufijo: si la parte no almacenada en caché de tu prompt es pequeña en relación con la parte almacenada en caché, ya que los ahorros escalan con la cantidad del prompt total que se encuentra detrás del punto de interrupción de la caché.

Si tu prefijo es grande, tu frecuencia de llamadas dentro de la ventana TTL es alta y tu sufijo es pequeño, es probable que el almacenamiento en caché reduzca el gasto. Si alguna de esas tres condiciones es débil, realiza una comparación de costos lado a lado antes de implementar el almacenamiento en caché de forma generalizada. La guía de TokenLab sobre cómo reducir los costos de la API de IA analiza un conjunto más amplio de palancas más allá del almacenamiento en caché, incluida la selección de modelos y el procesamiento por lotes, en /blog/cut-ai-api-costs-30-percent.

Tabla de decisiones: cuándo vale la pena el Prompt Caching

Patrón de carga de trabajo	¿Es probable que la caché ayude?	Notas
Prompt del sistema largo o esquema de herramientas reutilizado en muchas llamadas en una sesión	Sí	Caso clásico; el costo de escritura se amortiza con los aciertos
Documento recuperado grande reutilizado en una ráfaga corta de preguntas de seguimiento	Sí, si las llamadas aterrizan dentro del TTL	Confirma el TTL con la documentación actual antes de asumir la ventana de reutilización
Prompts únicos sin tráfico repetido	No	Prima de escritura sin aciertos para compensarla
Prompts de alta variabilidad donde la sección "estable" sigue cambiando	No	Cualquier cambio antes del punto de interrupción invalida la caché
Bucles de agentes con definiciones de herramientas repetidas en muchos turnos	Sí	Los esquemas de herramientas son candidatos principales para el almacenamiento en caché
Trabajos por lotes de baja frecuencia espaciados más allá del TTL de la caché	No	La caché caduca antes de la reutilización; paga el costo de escritura cada vez
Enrutamiento entre múltiples proveedores donde solo algunos backends admiten caché	Verificar por modelo	No asumas que el soporte de caché se transfiere entre proveedores

Utiliza esta tabla como una lista de verificación inicial, no como una respuesta definitiva. Confirma el TTL, los precios de escritura/acierto y la mecánica de los puntos de interrupción con la documentación del proveedor para el modelo específico que planeas usar, ya que estos detalles cambian y varían según la familia de modelos.

Diferencias entre proveedores que debes verificar antes de comprometerte

El Prompt Caching no se implementa de forma idéntica en todas partes, y eso es importante si enrutas el tráfico a través de múltiples proveedores o modelos. La documentación de OpenRouter sobre las mejores prácticas de Prompt Caching señala que el soporte y el comportamiento de la caché difieren según el proveedor subyacente, lo que significa que una estrategia ajustada para la mecánica de caché de un modelo no se aplica automáticamente cuando cambias de modelo o enrutas a través de un backend diferente.

Si tu arquitectura utiliza enrutamiento de modelos para controlar el costo (por ejemplo, enviando tareas de clasificación rutinarias a un modelo de menor costo como DeepSeek V4 Flash, GLM-5.2 o Gemini 3.5 Flash, mientras reservas Claude Sonnet 5 o GPT-5.5 para tareas de razonamiento más difíciles), debes verificar el soporte de almacenamiento en caché de forma independiente para cada modelo en esa tabla de enrutamiento. Una estrategia de almacenamiento en caché validada con la documentación de un modelo no es una suposición segura para otro. La página de clasificaciones de TokenLab rastrea las diferencias a nivel de modelo que puedes usar como punto de referencia inicial en /models/rankings, y el análisis de referencia de enrutamiento en /blog/ai-model-routing-benchmark-cost-per-task cubre cómo las decisiones de enrutamiento interactúan con el costo por tarea, lo cual se combina con las decisiones de almacenamiento en caché en lugar de reemplazarlas.

Limitaciones de este análisis

Esta guía describe la mecánica general del Prompt Caching según lo documentado por Anthropic y referenciado por OpenRouter a partir de las fechas observadas anteriormente. No incluye multiplicadores exactos de escritura/acierto, duraciones exactas de TTL o precios por modelo, porque esas cifras cambian y difieren según el modelo. Antes de crear un modelo de costos para el tráfico de producción, obtén los números actuales directamente de la documentación del proveedor vinculada anteriormente en lugar de confiar en cualquier cifra fija citada en contenido de terceros, incluido este artículo. El comportamiento de almacenamiento en caché para modelos orientados al razonamiento, prompts multimodales y ventanas de contexto muy largas también puede diferir del patrón general de almacenamiento en caché de prefijos descrito aquí; verifica con la documentación del modelo específico que planeas usar.

Preguntas frecuentes

¿El Prompt Caching siempre reduce el gasto en la API? No. Solo reduce el gasto cuando un prefijo estable se reutiliza con la frecuencia suficiente dentro de la ventana activa de la caché para compensar el costo de escritura. Los prompts esporádicos o altamente variables a menudo cuestan más con el almacenamiento en caché habilitado que sin él.

¿Qué rompe un acierto de caché? Cualquier cambio en el contenido del prompt antes del punto de interrupción de la caché, incluidos los espacios en blanco, el orden de los tokens o una sola variable insertada en un prompt del sistema que de otro modo sería estático. La coincidencia debe ser exacta hasta el punto de interrupción.

¿El Prompt Caching se implementa de la misma manera en todos los proveedores? No. Anthropic documenta un mecanismo de control de caché explícito con precios definidos de escritura y acierto. La documentación de OpenRouter señala que el soporte y los precios de la caché varían según el proveedor y el modelo subyacente, por lo que debes verificar el soporte por modelo en lugar de asumir que se transfiere.

Si estás evaluando si el Prompt Caching, el enrutamiento de modelos o una combinación de ambos se ajusta a tu patrón de tráfico, comienza con TokenLab para comparar las opciones de modelos y la estructura de costos antes de comprometer el gasto de producción.