--- title: "Por qué nuestro agente en la nube fallaba su caché de prompts y qué cambió un TTL de una hora" description: "Cómo medir la tasa de aciertos de la caché de prompts de un agente con Claude, dónde poner los cuatro breakpoints y cuándo un TTL de una hora compensa o cuesta más." author: "Foxl Team" date_published: "2026-10-23" date_modified: "2026-10-27" canonical_url: "https://foxl.ai/es/blog/agent-prompt-cache-hit-rate" markdown_url: "https://foxl.ai/es/blog/agent-prompt-cache-hit-rate/index.md" image: "https://foxl.ai/blog/agent-prompt-cache-hit-rate-cover.png" social_image: "https://foxl.ai/blog/social/agent-prompt-cache-hit-rate.png" content_type: "Deep dive" topics: ["Prompt caching","AI agents","Amazon Bedrock","Cost","Measurement"] products: ["Foxl Agent"] --- # Por qué nuestro agente en la nube fallaba su caché de prompts y qué cambió un TTL de una hora > Nuestro agente en la nube leyó de la caché de prompts el 42,6 % de su entrada en sus primeros 19 turnos en producción, y cada escritura grande en la caché llegó tras una pausa más larga que los cinco minutos de vida de la caché. Un TTL de una hora llevó una sesión medida de nueve llamadas del 71,8 % al 85,7 % (93,9 % después de la primera llamada) y redujo su coste un 8 %, pero un chat que termina en menos de cinco minutos paga alrededor de un 23 % más. Cómo lo medimos, dónde van los cuatro breakpoints y cuándo compensa el TTL más largo. - Author: Foxl Team - Published: 2026-10-23 - Last reviewed: 2026-10-27 - Reading time: 16 minutes - Canonical HTML: [https://foxl.ai/es/blog/agent-prompt-cache-hit-rate]() ![Dos bocadillos de chat de papel muy separados, con dos tiras de papel que salen de debajo del primero: la corta está arrancada mucho antes del segundo bocadillo y la larga llega hasta debajo de él. Una entrada de caché de cinco minutos ya no está cuando la persona responde; una de una hora sigue ahí.]() El agente en la nube de Foxl responde a los chats que una persona envía desde el teléfono o la web mientras su ordenador está apagado. En sus primeros 19 turnos en producción, leyó de la caché de prompts el 42,6 % de su entrada. Al revisar las escrituras grandes en la caché, vimos que todas llegaban después de una pausa de más de cinco minutos, que es lo que dura por defecto una entrada de caché. Quien responde desde el teléfono a menudo tarda más que eso. Dimos a las entradas de caché del agente una vida de una hora y volvimos a ejecutar una sesión medida de nueve llamadas. La tasa de aciertos pasó del 71,8 % al 85,7 %, o al 93,9 % si se deja fuera la primera llamada, que siempre escribe. La sesión costó un 8 % menos en total y un 15 % menos en entrada, aunque una escritura de una hora cuesta el doble del precio base de entrada. Un chat que termina en menos de cinco minutos sale al revés: paga el doble por cada escritura y nunca vuelve a leer ninguna, y sin la pausa, las mismas nueve llamadas cuestan alrededor de un 23 % más con la opción de una hora que con la de cinco minutos. El cambio salió en Foxl v0.9.3-beta.5, y el método sirve para cualquier agente que llame a Claude a través de la Messages API, en Anthropic o en Amazon Bedrock. ## ¿Cómo se mide la tasa de aciertos de la caché de prompts? La tasa de aciertos es la proporción de los tokens de entrada de una llamada que el proveedor leyó de su caché en lugar de procesarlos de nuevo: `cache_read / (uncached input + cache_read + cache_write)`. La caché funciona con breakpoints. Un **breakpoint de caché** es una marca `cache_control` en un bloque de la petición, que pide al proveedor que guarde en caché todo lo que hay hasta ese bloque, el **prefijo**. La entrada vive durante su **TTL** (time to live, tiempo de vida), cinco minutos por defecto, y la siguiente petición que empiece con el mismo prefijo la lee en lugar de volver a pagarla. Bedrock llama checkpoints a los breakpoints. Cada respuesta de la Messages API informa de tres contadores de entrada, y la página de Anthropic da su relación: `total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens`. Así que `input_tokens` cuenta solo lo que ni se leyó de la caché ni se escribió en ella, y dividir `cache_read` entre `input_tokens` da un número distinto y mucho mayor. La Converse API de Bedrock documenta lo mismo para sus propios campos: con la caché activada, `inputTokens` «representa solo los tokens de entrada que no están en caché». Damos dos cifras para cada ejecución. La tasa de aciertos sobre todas las llamadas incluye la primera llamada después de que la caché haya caducado, que siempre escribe. La tasa de aciertos después de la primera llamada muestra lo que cuesta una conversación una vez que su caché está llena. Parte del prompt es idéntica para todos los usuarios (el primer breakpoint, más abajo), así que en producción la primera llamada de una persona puede leer lo que escribió la conversación de otra, y solo la cifra de todas las llamadas puede mostrarlo. Nuestra prueba se ejecutó como una sola persona, así que no lo mide. La referencia de producción sale de los registros de facturación de Foxl para el agente en la nube: 19 turnos en 8 conversaciones desde el lanzamiento, con 35.054 tokens leídos de la caché, 47.173 escritos y 72 sin caché. 35.054 / (35.054 + 47.173 + 72) es un 42,6 %. El agente escribió más de lo que leyó: al menos 12.119 tokens (47.173 menos 35.054), alrededor de una cuarta parte de lo que pagó por guardar en caché, nunca se volvieron a leer. ## Por qué un agente de chat falla su propia caché El relay de Foxl, el servidor que está entre las apps de Foxl y Bedrock, ya ponía tres breakpoints en cada petición a Claude: en la última herramienta, en el prompt de sistema y en el último mensaje del usuario, todos con el TTL predeterminado de cinco minutos. Cuando las llamadas llegaban seguidas, acertaban. Una pregunta de seguimiento enviada 15 segundos después de una respuesta leyó 3.616 tokens y escribió 44. Las escrituras grandes llegaron todas después de pausas de más de cinco minutos. Un mensaje enviado 26 minutos después de la respuesta anterior, o un chat abierto dos horas después del último, volvió a escribir el prefijo entero, unos 3,6K tokens de herramientas y prompt de sistema. La guía de AWS para la caché de una hora describe casi exactamente este caso: «cuando se almacena una conversación de chat larga con un usuario y, en general, se espera que ese usuario no responda en los próximos 5 minutos». Además, un acierto renueva la entrada gratis («La caché se renueva sin coste adicional cada vez que se usa el contenido almacenado»). Por eso un agente que trabaja en un bucle de herramientas rara vez choca con el límite de cinco minutos, salvo que una sola llamada o herramienta tarde más de cinco minutos. Un chat con una persona choca con él entre turnos, y ahí es donde un chat así pasa la mayor parte del tiempo. ## Dónde van los cuatro breakpoints Una petición a Claude puede llevar como máximo cuatro breakpoints (Anthropic: «Puedes definir hasta 4 breakpoints de caché»; Bedrock indica 4 para todos los modelos Claude de su tabla). El prefijo en caché se lee en el orden `tools`, `system`, `messages`, y un cambio en cualquier punto invalida todo lo que viene después. Los breakpoints del relay eran todos de cinco minutos, así que ahora el agente en la nube pone los cuatro él mismo, cada uno con su TTL. El relay no toca una petición que ya lleva breakpoints y no añade ninguno propio. ![Una petición a la Messages API dibujada como una fila: las herramientas, el prompt de sistema compartido, la parte del prompt de sistema propia de la persona, los mensajes anteriores, el mensaje anterior del usuario y el mensaje más reciente. Cuatro marcas numeradas están al final de la parte compartida del sistema, al final del prompt de sistema, en el mensaje anterior del usuario y en el mensaje más reciente. La primera cierra la parte que comparten todos los chats, la segunda cierra la parte de esta persona, la tercera es donde escribió la llamada anterior y la cuarta es la escritura que leerá la siguiente llamada.]() _Figura 1. Los cuatro breakpoints de una llamada en la nube. Todo lo que hay antes del primero es igual en todas las conversaciones de todas las personas con un mismo modelo._ 1. **El final de la parte compartida del prompt de sistema.** Dividimos nuestro prompt de sistema donde empieza la memoria de cada usuario, en un encabezado `## Memory`. Las herramientas y todo lo que hay por encima de ese encabezado (quién es el agente, qué puede y qué no puede hacer en la nube) son idénticos en todas las conversaciones de todas las personas con un mismo modelo, así que un chat completamente nuevo de cualquiera empieza leyéndolos. 2. **El final del prompt de sistema.** El segundo breakpoint añade la memoria de la propia persona y una línea con la fecha. La línea de la fecha da el día, no la hora, así que no cambia el prefijo entre llamadas. 3. **El último bloque almacenable en caché del mensaje anterior del usuario.** Aquí es exactamente donde escribió la llamada anterior, así que leerlo no depende de la búsqueda hacia atrás de la API. Sin este breakpoint, la API empieza en el más reciente y busca hacia atrás una entrada de caché anterior, pero solo hasta cierto punto («La ventana de búsqueda hacia atrás es de 20 bloques»), y un turno con muchas llamadas a herramientas puede dejar la escritura anterior fuera de su alcance. Cómo se cuentan esos bloques depende de dónde llames a Claude: la API de Anthropic cuenta una serie de bloques `tool_use` o `tool_result` consecutivos como una sola posición, mientras que la página de Bedrock dice solo «aproximadamente 20 bloques de contenido» y no hace esa excepción. 4. **El último bloque almacenable en caché del mensaje más reciente.** Esta es la escritura que leerá la siguiente llamada. Los cuatro usan el mismo TTL. Bedrock acepta los dos TTL en una misma petición siempre que todas las entradas de una hora vayan primero («una entrada de caché de 1 hora debe aparecer antes que cualquier entrada de caché de 5 minutos»), y un único TTL para los cuatro lo garantiza sin necesidad de comprobar nada. Los breakpoints van solo en bloques `text`, `image`, `document`, `tool_use` y `tool_result`, que es el contenido de mensaje que Anthropic indica como almacenable en caché. El TTL de una hora va solo a los modelos Claude que la tabla de Bedrock muestra con «Supported TTL: 5 minutes, 1 hour». Bedrock advierte de que enviar el campo a un modelo que solo admite cinco minutos «puede provocar una `ValidationException`», así que los demás modelos Claude reciben los mismos cuatro breakpoints sin `ttl`. A GPT-5.6 y posteriores en Bedrock no los tocamos: usan su propio campo `prompt_cache_breakpoint` y, según la misma página, un «TTL mínimo de 30 minutos». ``` // the marker on each of the four blocks, on a model that takes it "cache_control": { "type": "ephemeral", "ttl": "1h" } ``` También hay un tamaño mínimo. Bedrock solo guarda en caché un checkpoint si todo lo que hay antes alcanza la longitud mínima del modelo: 512 tokens en los modelos 5.5, y 1.024 o 4.096 en algunos más antiguos. Por debajo del mínimo, «la inferencia sigue funcionando, pero el prefijo no se almacena en caché». En un modelo con un mínimo de 4.096 tokens, un prompt de 3,6K tokens deja los breakpoints de herramientas y sistema sin guardar nada hasta que la propia conversación lleve el prefijo por encima del mínimo, así que consulta la tabla para cada modelo que sirvas. ## ¿Cuesta una caché de una hora más de lo que ahorra? Con los precios de Anthropic, una escritura de cinco minutos cuesta 1,25 veces el precio base de entrada, una de una hora cuesta 2 veces y una lectura cuesta 0,1 veces (0,05 veces en Opus 5.5 y Sonnet 5.5). Por tanto, una escritura de una hora cuesta 0,75 veces el precio base más que una de cinco minutos. Ese sobrecoste lo pagas por el prefijo una vez por hora, y por el contenido nuevo de cada llamada todas las veces. A cambio, una pausa de más de cinco minutos ya no vuelve a escribir el prefijo entero a 1,25 veces; el prefijo se lee. Para medirlo, ejecutamos el código de producción del agente en la nube a través de una copia local de nuestro relay contra Bedrock real. El escenario es un chat de cuatro turnos (un plan seguido con una herramienta, una pregunta de seguimiento, guardar un archivo y, 6,5 minutos después, una pregunta sobre el primer turno), seguido de un chat nuevo. Eso suma nueve llamadas al modelo en Sonnet 5.5, ya que un turno que usa una herramienta hace más de una llamada. El uso se leyó del stream que devolvió Bedrock, y la columna de coste usa los precios por token de Foxl para Sonnet 5.5. | configuración | lectura de caché | escritura de caché | aciertos, las 9 llamadas | aciertos, llamadas 2-9 | coste de la ejecución | | --- | --- | --- | --- | --- | --- | | cinco minutos (los breakpoints del relay) | 29.979 | 11.755 (5m) | 71,8 % | 78,7 % | 0,0538 $ | | una hora (cuatro breakpoints) | 35.859 | 5.974 (1h) | 85,7 % | 93,9 % | 0,0494 $ | | una hora, más archivos de memoria (explicado más abajo) | 177.347 | 20.108 (1h) | 89,8 % | 98,6 % | 0,1219 $ | Casi toda la diferencia está en la llamada posterior a la pausa de 6,5 minutos. Con entradas de cinco minutos, volvió a escribir su prefijo de 5.873 tokens. Con entradas de una hora, leyó 5.750 tokens y escribió 133, y Bedrock informó de cada escritura como `ephemeral_1h_input_tokens`, que es como sabemos que el TTL más largo se aplicó y no se ignoró en silencio. La ejecución de una hora leyó 5.880 tokens más que la de cinco minutos (35.859 menos 29.979); 5.750 vinieron de esa única llamada y los otros 130 o así, de mover los breakpoints. El escenario no tenía ningún turno con muchas llamadas a herramientas, el caso para el que existe el tercer breakpoint. La entrada sin caché fue de 28 tokens en todas las ejecuciones. La configuración de cinco minutos obtiene un 71,8 % en esta prueba frente al 42,6 % en producción porque la prueba tiene una sola pausa de 6,5 minutos, mientras que los 19 turnos de producción se repartían entre 8 conversaciones con pausas de 26 minutos y de dos horas. El mismo código puntúa de forma muy distinta con tráfico distinto, así que compara tasas de aciertos solo entre ejecuciones del mismo escenario. Sin la pausa, el resultado se invierte. Si se quita de las mismas mediciones, la configuración de cinco minutos nunca vuelve a escribir su prefijo, así que es la más barata: la ejecución de una hora cuesta alrededor de un 23 % más en total y un 48 % más en entrada, porque pagó el doble del precio base por cada escritura y nada después del minuto cinco las volvió a leer. Para tu propio tráfico en Sonnet 5.5 u Opus 5.5, compara dos números: - **Ahorro:** cada token del prefijo que una pausa te habría obligado a reescribir ahorra unas 1,2 veces el precio base (una reescritura a 1,25 sustituida por una lectura a 0,05). - **Sobrecoste:** cada token escrito en esa hora cuesta 0,75 veces el precio base más (2 en lugar de 1,25). El TTL de una hora sale ganando cuando el ahorro es mayor. Un chat con una pausa de entre cinco y sesenta minutos suele conseguirlo, y también un segundo chat iniciado dentro de la hora; un chat que termina en menos de cinco minutos, sin nada más en esa hora, no. Para las personas que responden desde el teléfono elegimos una hora. Para un agente cuyas llamadas llegan con segundos de diferencia, cinco minutos es la mejor opción. Si reservas crédito antes de cada llamada, el TTL también cambia la reserva. El relay de Foxl reserva para el peor caso, así que una petición que pide un TTL de una hora se reserva a la tarifa de escritura de una hora. Esa tarifa (2 veces) es 1,6 veces la de cinco minutos (1,25 veces), así que una llamada a Sonnet 5.5 con 100K tokens de contexto reserva unos 0,40 $ de entrada en lugar de 0,25 $. El cargo sigue siendo lo que usó la llamada, pero con un saldo casi vacío se puede rechazar una llamada antes. ## Qué marca el techo El contenido nuevo. Cada mensaje nuevo del usuario y cada respuesta se escriben en la caché una vez antes de poder leerse, así que ninguna colocación de breakpoints permite que una llamada lea los tokens que está añadiendo. En la ejecución de una hora, la primera llamada no leyó nada, porque las entradas de cinco minutos de la ejecución anterior habían caducado, así que los 35.859 tokens leídos vinieron todos de las llamadas 2 a 9: el 93,9 % de los aproximadamente 38.200 tokens de entrada que consumieron. Los otros 2.300 o así eran los mensajes y respuestas nuevos de esa ejecución, lo que hace del 93,9 % el techo de ese escenario. Un chat más largo lleva más historial por cada token nuevo, así que su techo es más alto. ![Barras de tres ejecuciones de la misma sesión de nueve llamadas. La configuración de cinco minutos leyó de la caché el 71,8 % de la entrada en total y el 78,7 % después de la primera llamada. La de una hora, el 85,7 % y el 93,9 %. Al añadir los archivos de memoria al prompt, el 89,8 % y el 98,6 %.]() _Figura 2. Las mismas nueve llamadas con tres configuraciones. La diferencia entre las dos barras de cada ejecución es la primera llamada, que siempre escribe._ Un prefijo estable más grande también sube el porcentaje, sin abaratar nada. Lo vimos cuando el agente en la nube ganó una opción para incluir los archivos de memoria del usuario: cuatro archivos Markdown (SOUL.md, USER.md, MEMORY.md y AGENTS.md) que la app de escritorio de Foxl pone en su propio prompt. El teléfono o el navegador los copia mientras el ordenador está conectado, los recorta con el mismo código que usa el escritorio y los envía con cada mensaje a la nube. Un conjunto real de estos archivos, recortado así, ocupaba unos 41K caracteres, aproximadamente 14K tokens de entrada por llamada; la tercera ejecución usó un archivo de prueba del mismo tamaño. En esa ejecución, la primera llamada escribió 17.619 tokens del prompt de la persona, todas las llamadas posteriores los leyeron y la tasa de aciertos después de la primera llamada llegó al 98,6 %. La ejecución también costó 0,1219 $ frente a 0,0494 $, porque el prompt es varias veces más grande; sin la caché, las mismas nueve llamadas habrían costado 0,4187 $. Tuvo la mejor tasa de aciertos de las tres ejecuciones y la factura más alta, y por eso ponemos el coste junto a cada tasa de aciertos que publicamos. ## Lo que no hemos medido - **Producción después del cambio.** A 23 de octubre de 2026 no se ha ejecutado ningún turno en la nube en producción desde que se desplegó el cambio, así que el 42,6 % es la única cifra de producción, y las cifras posteriores vienen del relay local contra Bedrock real. - **Otros modelos.** Solo ejecutamos Sonnet 5.5. Los demás modelos Claude que reciben el TTL de una hora lo reciben basándonos en la tabla de Bedrock y, en el caso de Opus 5.5, en una medición anterior a través de nuestro relay. - **Otros escenarios.** Nueve llamadas con un único patrón, ninguna de ellas un turno con muchas llamadas a herramientas. Un chat que pasa más de una hora inactivo vuelve a pagar la primera escritura, y una hora es el TTL más largo que ofrece cualquiera de los dos proveedores para Claude. Si tienes tus propios agentes con Claude, la tasa de aciertos es lo más barato de comprobar. Suma los tres contadores de cada llamada, divide las lecturas entre toda la entrada y mira qué hubo antes de cada llamada que escribió un prefijo grande. Si venía tras una pausa de más de cinco minutos, un TTL de una hora lo arregla, como pasó con casi toda la mejora de este escenario. Si venía tras una llamada hecha segundos antes, o el prefijo cambió entre las dos llamadas o la escritura anterior quedó fuera del alcance de la búsqueda hacia atrás, que es lo que evita el tercer breakpoint. Un artículo anterior explica cómo [mantener un subagente en la caché de su padre](), la misma regla del prefijo dentro de un solo turno. ## Referencias y lecturas recomendadas 1. [Anthropic: almacenamiento en caché de prompts]() - Documentation 2. [Amazon Bedrock: almacenamiento en caché de prompts para una inferencia más rápida]() - Documentation 3. [Versión v0.9.3-beta.5 de Foxl]() - Release