Los errores de almacenamiento en caché de prompts pueden costar a su organización casi 6x más en cada turno de IA

Desde entonces he llegado a entender parte de la razón. Una persona puede volver a una conversación al día siguiente, y cualquier hora que se le dio al inicio se vuelve obsoleta. Algo tiene que suministrarla de nuevo. Un arnés, el programa alrededor de un modelo que arma cada solicitud y ejecuta el bucle, puede hacer eso escribiendo la hora actual en las instrucciones del modelo antes de cada solicitud. El corredor de agentes que usamos en producción hizo exactamente eso.

He sabido sobre el almacenamiento en caché de prompts durante mucho tiempo. Los proveedores almacenan el inicio de una solicitud y la facturan a una fracción del precio cuando la siguiente solicitud comienza de la misma manera. No conocía bien su mecánica para ver lo que una línea como la hora le hace. Nos topamos con la respuesta en nuestros propios costos de producción, y dirigí un conjunto de experimentos para medirlo adecuadamente, a través de un modelo actual de cada uno de 4 labs y contra las cifras públicas de OpenRouter sobre lo que todos los demás están pagando.

La respuesta es cara. En GPT-6 Luna, la hora escrita en el lugar incorrecto hizo que cada turno de una conversación costara 5.7× lo que necesitaba, y nada generó un error. A través de las organizaciones de tráfico envían estos modelos, la entrada es 96–99% de los tokens y 66–87% de los dólares realmente pagados, así que la caché decide la mayor parte de la factura. Para una organización que construye su propio harness, ejecuta una plataforma interna de IA o envía productos de IA, un error como este multiplica el costo de cada turno, silenciosamente, mientras dure.

Cada número por turno aquí fue medido el 23 de septiembre de 2026, a través de OpenRouter. Las cifras del mercado son propias de OpenRouter, leídas el mismo día.

Cada llamada a un modelo envía toda la conversación de nuevo: las definiciones de la herramienta, el prompt del sistema (las instrucciones permanentes que escribe el arnés), cada turno anterior y el nuevo mensaje.

Los proveedores mantienen el comienzo procesado de las solicitudes recientes. Cuando la siguiente solicitud comienza con el mismo texto, el proveedor lee ese prefijo almacenado en lugar de procesarlo de nuevo. En GPT-6 Luna, OpenRouter facturó una lectura a 0.10× el precio de entrada listado y la primera escritura a 1.25×. Un prompt que se escribe de nuevo en cada turno por lo tanto cuesta más que un prompt sin caché en absoluto.

Solo el inicio de una solicitud puede reutilizarse. Un cambio en cualquier punto anula todo lo que sigue:

graph LR
    A[Definiciones de la herramienta] --> B[Prompt del sistema]
    B --> C[Turnos anteriores]
    C --> D[Nuevo mensaje del usuario]
    B -. a changed line here voids B, C and D .-> D

Cualquier cosa que el arnés escriba cerca del inicio y cambie en cada turno pone en riesgo toda la conversación detrás de ella. El tiempo actual es el ejemplo más sencillo.

El descubrimiento comenzó en un agente que ejecutamos en producción. Su libro de costos valoraba cada llamada al precio de lista y no mostraba ninguna caché en absoluto. Aléé la alarma y comencé a ponderar un cambio a un modelo diferente.

El agente con el que estaba trabajando descubrió primero que el propio libro estaba equivocado. Sobre 33 llamadas estimó $0.064; el proveedor facturó $0.023, 2.7× menos. Calcular cada llamada a partir de los recuentos de tokens había borrado cada descuento que el proveedor aplicaba. Leer el costo reportado por el proveedor en su lugar mostró que la caché funcionaba dentro de cada turno y fallaba al inicio de cada nuevo.

Su primera explicación fue una clave de sesión faltante que mantendría las solicitudes en el mismo servidor. Su propia prueba lo refutó: indicaciones idénticas ya se leían de la caché entre turnos en GPT-6 Luna, y agregar una clave de sesión, una clave de caché o un marcador de caché explícito no cambió nada. La causa estaba en el propio mensaje del sistema. Aproximadamente 95% del camino dentro, el corredor escribió dos líneas que cambiaban en cada turno: un directorio de trabajo por turno y un reloj al minuto. Cada primera llamada de un turno escribía el mensaje completo de nuevo en 1.25×.

Mover ambas líneas al final del mensaje del usuario lo arregló en producción. Los turnos 2 y 3 ahora se abren a 0.47–0.51× en lugar de 1.25×. El resto es un bloque de contexto por turno que el corredor todavía envía en el mensaje del usuario.

Mi suposición, antes de que se midiera cualquiera de esto, era que una verificación determinista podría suministrar el tiempo solo cuando se había vuelto obsoleto, como un mensaje separado, y dejar el resto del prompt en caché. Se mantiene, con una condición, y esa condición es la regla en la que se basa el resto del artículo.

Para probarlo directamente, construimos una sonda que ejecuta la misma conversación con el reloj en diferentes lugares, gira 65 segundos de separación para que el minuto cambie entre cada par. GPT-6 Luna, un prompt de sistema de 8.5K tokens, 3 replica:

Mi mensaje separado mantuvo la caché en ambas formas, cada turno y solo cuando está obsoleta. La condición es donde se encuentra el mensaje. Después de las instrucciones estables, el proveedor lee todo lo que está antes de él. Como segundo mensaje del sistema, se ubica entre las instrucciones, y GPT-6 Luna escribió todo el prompt nuevamente en 12 de 12 turnos.

La regla que sigue es corta. Todo lo que cambia entre turnos va después de todo lo que no cambia.

La caché compara texto, así que un reloj es inofensivo mientras su texto permanezca igual. En el mismo probe con giros de 4 segundos de separación, un reloj de minuto en el prompt del sistema se lee de la caché cada vez. Con giros de 65 segundos de separación, forzaba una reescritura completa en cada turno.

La resolución determina con qué frecuencia eso ocurre. Un reloj de hora y una línea de fecha en el prompt del sistema ambos se leen de la caché en todas las aperturas de turno de 12 de los runs de 65 segundos, porque ninguno se volvió a girar. También se rompen, una vez por hora y una vez por día. Un reloj de minuto se rompe en cada turno que comienza en un minuto posterior al anterior.

La propia caché también expira. En ejecuciones con tiempo único, GPT-6 Luna todavía leía su prefijo almacenado después de 30 minutos de inactividad y escribía todo el prompt de nuevo en 1.25× después de 60. DeepSeek V4.1 Flash leía después de 10 minutos y falló después de 60. Claude Opus 5.5 ya había fallado después de 10, ya que la caché por defecto de Anthropic dura 5 minutos y su caché de 1 horas cuesta 2× para escribir. La persona que regresa a una conversación al día siguiente, el caso con el que comenzó este artículo, encuentra tanto un tiempo obsoleto como una caché fría en los tres. Ese primer turno de regreso paga por todo el prompt sin importar lo que haga el harness. La colocación decide si las vueltas después de ella también lo hacen.

GPT-6 Luna es la respuesta de un proveedor. Para ver cuán general es la lección, ejecutamos las mismas colocaciones en un modelo actual de cada uno de 4 labs, con un mensaje de 2.5K tokens idéntico, cada uno fijado a un solo proveedor:

GPT-6 Luna almacena en caché mensajes completos. Una línea cambiada anula el mensaje que la contiene y todo lo que sigue.

Claude Opus 5.5 almacena en caché donde el llamador lo marca. Los modelos de Anthropic solo almacenan en caché hasta un marcador cache_control que el arnés coloca. Sin marcador, el mismo mensaje se facturaba al precio completo en cada llamada. Con el marcador en el mensaje del sistema, un reloj dentro de ese bloque costó 1.24×, mientras que un reloj en un segundo mensaje del sistema después de él leía a 0.08×. La colocación que GPT-6 Luna penaliza es segura en Opus. En los precios de Opus la diferencia por apertura de turno fue $0.0214 contra $0.0023. Opus también contó el mensaje idéntico como 4,056 tokens donde GPT-6 Luna contó 2,395, por lo que el mismo texto cuesta 1.69× más tokens antes de que se aplique cualquier precio.

DeepSeek V4.1 Flash almacena en caché en bloques de 256 tokens y no cobra nada extra por escribir. Las lecturas regresaron en múltiplos exactos de 256: 2,560 tokens para el mensaje sin cambios, 2,304 con el reloj al final del mensaje del sistema. Una línea cambiada cuesta solo el bloque que la contiene. Las primeras llamadas se facturaron al precio de entrada simple, y las lecturas a 0.03–0.04×. En 8 ejecuciones por colocación, 2 llamadas individuales perdieron la caché en un turno que la misma ejecución luego leyó, lo que se interpreta como la solicitud aterrizando en un servidor diferente en lugar de como un efecto de colocación. El propio endpoint de DeepSeek es el único que OpenRouter marca como caché automáticamente, y la configuración de privacidad de mi cuenta lo excluye porque ese endpoint entrena con tráfico pagado. Las ejecuciones pasaron por DeepInfra, que almacenó en caché, al igual que Fireworks y Morph en una verificación de 2 llamadas.

Muse Spark 1.3 lee su caché dentro de un bucle de herramienta y falla al inicio de cada nuevo turno. Nuestras primeras pruebas, que hacen una pregunta fresca contra el mismo mensaje del sistema, sirvieron como máximo 113 tokens de la caché en 10 llamadas, en 2.9K, 8.9K y 19.4K tokens. Cuando una llamada de seguimiento extendió la solicitud anterior, como un bucle de herramientas de un agente, Muse leyó 2,801 de 2,966 tokens y facturó 0.17×. La siguiente vuelta del usuario, con todo el historial delante de ella, no leyó nada. OpenRouter informa de una tasa de aciertos de caché 86.1% para Muse en tráfico en vivo, que se ajusta a una carga de trabajo dominada por bucles de herramientas. Al inicio de una vuelta el reloj no hace diferencia en Muse, ya que esa llamada falla de todos modos.

La misma decisión de arnés cuesta una cantidad diferente en cada modelo. Saber qué mecanismo usa tu proveedor viene antes de afinar cualquier cosa.

Esperábamos que las vueltas en caché respondieran más rápido. En 10 pares secuenciales de llamadas GPT-6 Luna a 8.5K tokens, la primera llamada mediana tomó 437 ms de la caché y 490 ms sin ella. Ese intervalo se sitúa dentro de la dispersión de las muestras. A este tamaño, la caché cambia lo que cuesta una vuelta y deja que el tiempo que tarda sea aproximadamente el mismo.

Así que la pausa que recuerdo al preguntar por la hora tiene alguna otra causa. Lo que cuesta un reloj en el lugar equivocado es dinero.

Un reloj en el mensaje del sistema se coloca delante de toda la conversación, por lo que cada reescritura cubre el historial creciente detrás de él así como las instrucciones. Aquí está el costo medido de una conversación GPT-6 Luna de 12 vueltas, con la factura completa reportada por el proveedor, incluyendo la salida y las llamadas dentro de cada vuelta:

Las dos líneas comparten su primera vuelta, cuando ambos escriben la caché. A partir de entonces, cada vuelta con el reloj en el mensaje del sistema cuesta 5.7× lo que la misma vuelta cuesta con el reloj al final del mensaje del usuario. Para la vuelta 12 la conversación había costado 4.1× tanto, y la brecha se amplía con cada vuelta.

Fracciones de centavo se convierten en un ítem de línea a escala. Esta proyección fija el precio de la primera llamada de cada vuelta para un producto que sirve 10,000 conversaciones al día, cada una con un mensaje del sistema de 8.5K tokens, 20 vueltas, y un historial que crece 1,500 tokens por vuelta. Cada modelo usa su precio listado y el comportamiento de caché que mostró arriba:

Los bloques de DeepSeek mantienen el mensaje del sistema cuando el reloj cambia, y el modelo sigue resultando 13× más caro, porque el historial detrás del reloj supera las instrucciones en pocos turnos. Muse Spark muestra el otro lado: falló al inicio de cada turno en nuestras ejecuciones, por lo que la colocación no salvó nada allí y cada apertura de turno pagó el precio completo, $2.1M al año por el mismo tráfico.

Nuestras mediciones usan un mensaje controlado. OpenRouter publica lo que los mismos modelos cuestan en el tráfico de todos, y el mismo mecanismo aparece allí a escala. Casi todo lo enviado a estos modelos es entrada: 96.3% de los tokens de GPT-6 Luna en su primer día, 98.5% de Claude Opus 5.5 y DeepSeek V4.1 Flash, y 98.9% de Muse Spark 1.3. La entrada es donde se aplica la caché, por lo que la tasa de aciertos establece la mayor parte de lo que paga un negocio.

Los clientes pagaron $0.87 por millón de tokens de entrada para Claude Opus 5.5 contra un listado $4.00, $0.30 contra $1.25 para Muse Spark 1.3, y $0.036 contra $0.10 para GPT-6 Luna. En los puntos finales que sirven al mismo modelo el mismo día, el precio pagado sigue la tasa de aciertos:

Precios cada fallo como una escritura de caché y cada acierto como una lectura predicen cada uno de los precios publicados de los 5 puntos finales principales dentro de 2–13%. La tasa de aciertos sola explica la dispersión. En GPT-6 Luna el mismo patrón corre desde $0.025 a una tasa de aciertos de 88.1% hasta $0.075 a 49.4%, un factor de 3.

La misma decisión de colocación llega de manera diferente a cada tipo de organización que construye sobre estas APIs.

Los constructores de harness establecen la tasa de aciertos para todos los usuarios al mismo tiempo. Las 5 apps que enviaron Claude Opus 5.5 el mayor tráfico en su primer día fueron todos agentes, entre 2.9B y 16.3B tokens cada uno. Para un harness con 10B tokens de entrada al día en ese modelo, cada punto de tasa de aciertos de caché vale $175K al año. La brecha entre los puntos finales 92.2% y 77.4% anteriores llega a $2.07M al año a ese volumen. Un reloj en el prompt del sistema que reescribe cada apertura de turno cuesta entre $1.75M y $8.76M al año, dependiendo de si las aperturas de turno son 1 llamada en 10 o 1 en 2. La decisión también viaja: cada producto construido sobre un harness hereda su colocación. Mientras escribíamos esto encontramos el mismo reloj de prompt del sistema en un segundo harness nuestro, que ejecuta una versión más antigua del mismo runner.

Las empresas que ejecutan una plataforma AI interna lo establecen para cada equipo detrás de ellas. Un gateway que marca el prompt del sistema de cada solicitud con una marca de tiempo o ID de solicitud para auditoría convierte cada apertura de turno de cada aplicación en escrituras, sin importar lo que los equipos construyan encima. La contabilidad es la segunda exposición. Facturado al precio de lista, los costos de entrada parecen 2.8× mayores que la factura en GPT-6 Luna, 4.1× en Muse Spark 1.3 y 4.6× en Claude Opus 5.5. Nuestro propio libro mayor sobrestimó las llamadas 33 en 2.7×, y casi cambié de modelo por su fuerza.

Las empresas que lanzan productos AI lo pagan en cada conversación. Dentro de una conversación, el reloj mal colocado costó 5.7× por turno. En un mercado, las apuestas son mayores. El 21 de septiembre, Muse Spark 1.3 tomó 88.5B tokens de entrada a través de OpenRouter. Al precio de lista eso es $110.6K; los clientes pagaron $26.9K, y cada punto de tasa de aciertos en ese tráfico vale $355K al año. DeepSeek V4.1 Flash tomó 2.68T tokens de entrada ese mismo día, y a los precios de DeepInfra cada punto vale $1.33M al año. Esas cifras cubren un router. El tráfico enviado directamente a los proveedores no aparece en ellos.

Cada uno de esos costos se remonta al mismo mecanismo, y lo mismo ocurre con la solución. Las convenciones de harnesses de agentes bien construidos se leen como sus consecuencias:

La solución anterior es una sola edición. Las condiciones a su alrededor siguen moviéndose. Un arnés gana un nuevo gancho, una puerta de enlace comienza a marcar las solicitudes con un ID, un equipo se traslada a un modelo con un mecanismo de caché diferente, un proveedor cambia cuánto tiempo permanece caliente un prefijo inactivo. Los cuatro modelos aquí almacenan en caché de cuatro maneras diferentes, y Claude Opus 5.5 dejó que una caché se enfriara dentro de 10 minutos de tiempo inactivo. El segundo arnés donde encontramos el mismo reloj simplemente se quedó en una compilación anterior. Nada de esto genera un error.

Cada llamada ya devuelve lo que necesita para verla: tokens de prompt, tokens en caché, tokens de escritura en caché y el costo facturado. Registrado por llamada, junto con si la llamada abrió un turno o continuó uno, esos campos dan tres números que vale la pena vigilar para cada ruta y modelo:

Un umbral en esos números detecta una caída repentina. Nombrar la causa a lo largo de semanas de datos es un problema de clasificación, y una clase más nueva de modelo lo satisface. Jev, de TypeSafe, es lo que su creador llama un modelo System One. No genera texto. Toma un estado y preguntas tipadas y devuelve respuestas tipadas con una distribución de probabilidad y una confianza: una elección entre opciones, una probabilidad de sí, o una posición en una escala ordenada. Dado el perfil diario de caché de una ruta, puede nombrar el patrón que coincide con el día (saludable, reescritura de aperturas de turno, caducidad de caché entre turnos, tráfico alcanzando un punto final que no hace caché) y decir cuán seguro está, de modo que un cambio de categoría se convierta en la alerta. Lo usamos en producción para clasificar documentos y, en observación, para puntuar episodios terminados de agentes. OpenRouter lo lista en $0.042 por millón de tokens de entrada sin cargo por salida. A ese precio, clasificar un perfil diario de 2K tokens para cada una de las rutas 1,000 cuesta alrededor de $31 al año, frente a $175K al año por un solo punto de tasa de aciertos a la escala de enganche anterior.

Un sistema que sigue reescribiendo su caché paga la prima en cada turno de cada conversación, mientras esté en funcionamiento, y la factura rara vez indica por qué. La corrección puede ser tan pequeña como donde se escribe la hora. Mantenerla fija requiere un número que alguien observa.

Cada cifra medida arriba proviene de los propios campos por llamada de OpenRouter (tokens en caché, tokens de escritura en caché y costo facturado) el 23 de septiembre de 2026. Las cifras de mercado provienen de las páginas públicas del modelo de OpenRouter leídas ese día: el precio de entrada ponderado realmente pagado, el precio efectivo de cada punto final y la tasa de aciertos de caché, y un día de actividad de tokens por modelo. Claude Opus 5.5 y GPT-6 Luna se lanzaron el 22 de septiembre, por lo que sus cifras de actividad cubren un primer día parcial, y el artículo las usa solo como participaciones. Los experimentos costaron $0.63 en total, y la sonda se negó a iniciar una vez que el uso de la cuenta se acercó a un límite $1 cap. Los precios son los precios listados de OpenRouter leídos el mismo día. La guía de caché de OpenRouter lista OpenAI lecturas de caché a 0.25–0.50×; GPT-6 Luna facturó sus lecturas a 0.10×, y este artículo informa lo que se facturó.

Todavía abierto: el punto exacto en el que expira la caché inactiva de cada modelo, que solo enmarca ejecuciones con tiempo; cuántas veces por hora o por fecha el reloj se rompe sobre brechas reales de conversación; por qué Muse Spark falló al inicio de cada turno cuando su historial no cambió; y el comportamiento de DeepSeek en su propio punto final. La corrección por turno está en vivo en nuestro agente de producción, y el mismo hallazgo se ha programado para un segundo arnés que ejecuta una versión más antigua del mismo corredor.

Por mí. La pregunta detrás del artículo: por qué la IA nunca pareció conocer bien la fecha y hora, y tardó segundos en decirla cuando debería ser instantánea. La idea de que el tiempo se vuelve obsoleto a lo largo de una sesión y debe suministrarse de nuevo, mi suposición de que un mensaje determinista, solo cuando esté obsoleto, dejaría el prompt en caché, y la llamada para probarlo por experimento. El encuadre de costos: cuantificado para las empresas que construyen sobre estos modelos, desde constructores de harness hasta compañías que ejecutan sus propias plataformas internas de IA, tal como está hoy y a medida que se compone. El cierre sobre la observación continua, con un modelo System One como Jev clasificando el perfil de caché con el tiempo, porque la solución solo funciona mientras alguien siga observando.

Por Claude Opus 5.5. Descubrió que nuestro libro de costos ocultaba la caché, 2.7× en llamadas 33, y rastreó la causa a líneas 2 en el prompt del sistema que cambiaban en cada turno. Construyó la corrección del runner que ahora está en producción, la sonda, el análisis y el modelo de costos detrás de cada número aquí, y comparó el mecanismo con las cifras públicas de mercado de OpenRouter. En los modelos 4 identificó 3 comportamientos de caché diferentes, incluido el comportamiento de mensaje completo de GPT-6 Luna, y un cuarto modelo sin caché utilizable.