Activar el almacenamiento en caché de prompts no me ahorró nada; de hecho, mi factura de la OpenAI-API aumentó aproximadamente una cuarta parte. El culpable fue una sola línea que cambiaba con cada solicitud: una marca de tiempo (timestamp) incrustada en el prompt del sistema.
Los proveedores de LLM permiten a los desarrolladores almacenar en caché fragmentos de prompts para reducir los costes de procesamiento de tokens. Una lectura de caché (un «hit») cuesta apenas una décima parte de la tarifa regular, mientras que una escritura en caché (un «miss») cuesta aproximadamente 1.25 × el precio normal. Si se produce una escritura pero el fragmento almacenado nunca se lee, el cargo adicional del 25 % se desperdicia. Eso fue exactamente lo que ocurrió cuando la marca de tiempo impidió que el prompt coincidiera con cualquier entrada de caché existente.
Por qué el almacenamiento en caché puede ser contraproducente
El almacenamiento en caché de prompts funciona mediante la coincidencia de la secuencia de bytes exacta de la parte almacenada. El proveedor aplica un hash a la entrada; si el hash coincide con una entrada almacenada, el sistema reutiliza el cálculo anterior y aplica la tarifa de lectura económica. Cualquier variación —incluso un solo carácter— rompe la coincidencia y obliga a realizar un nuevo cálculo, facturado a la tarifa de escritura más alta.
En mi caso, el prompt del sistema comenzaba con:
Current session started: 2026-07-14T09:41:07Z
Debido a que la marca de tiempo se actualizaba en cada llamada a la API, los primeros bytes de la solicitud nunca eran idénticos. El proveedor trataba cada llamada como una nueva entrada de caché, cobraba la prima de escritura y nunca registraba una lectura. El resultado fue un aumento constante de cache_creation_input_tokens mientras que cache_read_input_tokens se mantenía en cero, una señal clara de que nunca se estaba produciendo un acierto en la caché.
Cómo detectar una caché defectuosa
Los registros de uso proporcionados por la API ofrecen dos contadores clave:
- cache_creation_input_tokens – tokens que activaron una escritura.
- cache_read_input_tokens – tokens que se beneficiaron de una lectura.
Cuando el primero aumenta y el segundo permanece plano, la caché no se está reutilizando. Una prueba rápida de control consiste en repetir exactamente la misma solicitud dos veces; la segunda llamada debería mostrar un pico en los tokens de lectura si la caché está funcionando.
Cómo solucionar el problema
La solución es sencilla: asegúrese de que la región almacenada en caché sea estática en todas las llamadas. Siga estas dos reglas:
- Coloque el contenido inmutable primero. Los prompts del sistema, las definiciones de herramientas o cualquier instrucción que nunca cambie deben ocupar los primeros bytes de la solicitud.
- Añada el contenido mutable al final. Las marcas de tiempo, el texto generado por el usuario, los IDs de solicitud o cualquier dato que varíe por llamada deben ir después del segmento almacenado en caché.
Si incluso un solo carácter cambia de posición, el hash cambia y el error de caché (cache miss) persiste. Reorganizar el prompt para que la marca de tiempo se sitúe al final restaura la tasa de aciertos de la caché y reduce la factura al nivel de bajo coste esperado.
Cuándo ayuda realmente el almacenamiento en caché
El almacenamiento en caché de prompts destaca en escenarios donde el mismo conjunto de instrucciones se reutiliza muchas veces:
- Bucles de agentes (agent loops) donde una IA llama repetidamente a un conjunto fijo de herramientas.
- Sesiones de chat que hacen referencia a un documento largo y estático, mientras que solo cambia la última consulta del usuario.
- Extracción de datos masiva donde el mismo prompt de análisis se aplica a muchos registros.
Para llamadas de un solo uso (single-shot) que incluyen un contexto nuevo cada vez —como una pregunta puntual con un preámbulo único—, el almacenamiento en caché no ofrece ningún beneficio e incluso puede aumentar el coste si la solicitud activa involuntariamente una escritura.
Trampas ocultas
Incluso si el prompt en sí es estático, la solicitud puede alterarse en etapas posteriores:
- Proxies o agregadores que reordenen o inyecten espacios en blanco pueden romper la coincidencia byte por byte.
- Servicios de puerta de enlace (gateway services) que antepongan encabezados de autenticación o modifiquen el formato JSON pueden cambiar involuntariamente el fragmento almacenado en caché.
Realizar pruebas a través de la puerta de enlace enviando una solicitud idéntica dos veces y comprobando los contadores de lectura ayuda a verificar que la ruta de almacenamiento en caché permanece intacta.
El panorama general de costes
El recargo del 25 % en las escrituras no es una penalización por usar el almacenamiento en caché; refleja el cómputo adicional necesario para almacenar el fragmento para su reutilización futura. Cuando ocurre un acierto en la caché (cache hit), el coste disminuye drásticamente, a menudo a una fracción de la tarifa regular. La clave es permitir que el sistema realmente acierte en la caché. De lo contrario, pagará la prima sin obtener ningún ahorro.
Contraargumento: el almacenamiento en caché no ha muerto
Algunos desarrolladores argumentan que la complejidad de gestionar las partes estáticas frente a las dinámicas de un prompt supera el ahorro obtenido. Esa visión pasa por alto el hecho de que muchos pipelines de producción ya separan la configuración (estática) de los datos del usuario (dinámicos). Al estructurar los prompts de esta manera, se puede aprovechar el mismo mecanismo de caché que salvó a los desarrolladores originales de la API sin esfuerzo adicional. El compromiso es una disciplina modesta en el diseño de prompts, no un fallo fundamental en la tecnología.
Qué vigilar a continuación
- Monitorea los dos contadores de caché en tu panel de uso semanalmente.
- Audita la construcción de los prompts para confirmar que cualquier elemento variable se encuentre después del bloque en caché.
- Realiza pruebas A/B con y sin caché en una carga de trabajo representativa para cuantificar el ahorro real.
- Valida el gateway comparando los payloads de las solicitudes sin procesar antes y después de cualquier proxy.
Conclusión
El almacenamiento en caché de prompts puede reducir drásticamente los costes de la API de LLM, pero solo si el segmento en caché es verdaderamente idéntico en todas las llamadas. Una marca de tiempo perdida o cualquier otro token dinámico al inicio de un prompt obliga a una escritura costosa cada vez, inflando la factura. Al colocar las instrucciones estáticas al principio y relegar los datos cambiantes al final, permites que la caché haga su trabajo y mantienes tus gastos bajo control.