Hoy las páginas de precios de todos los vendors frontier distinguen entre tokens de input con cache y sin cache, en una relación cercana a diez a uno. Casi todo el código de agentes que auditamos lo ignora. Los agentes funcionan. Solo que cuestan entre cinco y diez veces lo que deberían y van entre dos y cuatro veces más lentos, porque cada iteración del loop vuelve a leer el mismo system prompt, las mismas definiciones de tools y el mismo contexto largo como si fuera el primer turno.
Diseñar el agente pensando en el cache es uno de los cambios con mayor palanca disponibles hoy para cualquier equipo con agentes en producción. Casi nadie lo ha hecho porque el cache es invisible hasta que lo instrumentas.
Por qué esto es un problema de 2026 y no de 2025
Cambiaron dos cosas. Los TTL de cache se hicieron lo bastante largos como para importar en flujos reales —la ventana práctica hoy va de cinco minutos a una hora en los vendors principales, según el tier. Y los workflows agénticos que de verdad necesitan esa ventana —agentes de horizonte largo, loops multiturno con uso de tools, workers en background— pasaron de la demo a producción.
Casi todo el código de agentes que hay en producción se escribió antes de que ninguna de esas dos cosas fuera cierta. La línea de la factura es el síntoma visible. La cola de latencia es el síntoma operativo. Ninguno de los dos aparece hasta que alguien mira.
Qué significa «consciente del cache», en concreto
Tres reglas de diseño.
Primera: el prefijo estático es sagrado. El system prompt, las definiciones de tools y las instrucciones permanentes tienen que ser idénticas byte a byte en cada llamada de una sesión. Hemos visto a equipos romperse su propio cache metiendo un timestamp en el system prompt «para depurar». Ese timestamp invalida el cache en cada llamada y duplica la factura sin que nadie se entere.
Segunda: la conversación crece por append, no por edición. Si el historial del agente se reescribe a mitad de sesión —se resume, se reordena, se le antepone una instrucción nueva—, se pierde el cache de todo lo que venga después del punto editado. La compactación tiene que ocurrir en fronteras planificadas, no cuando toque.
Tercera: el loop se diseña alrededor del TTL, no contra él. Si la ventana de cache dura cinco minutos, un patrón de sleep-and-poll que despierta cada seis paga un cache miss en cada iteración. Uno que despierta cada cuatro, no. La diferencia es una línea de configuración y más o menos la mitad de la factura.
El ángulo del eval
El arnés de evaluación tiene que saber del cache. Un eval en verde que se ejecuta en frío, sin cache, demuestra que el agente funciona bien. No demuestra que funcione bien en producción, donde el estado del cache cambia el comportamiento del modelo en los márgenes, sobre todo en contextos largos, donde una lectura cacheada y una fresca pueden muestrear de forma sutilmente distinta.
Hoy ejecutamos el eval dos veces en cada cambio: una en frío y otra en caliente. Una regresión que aparece en caliente y es invisible en frío es una regresión real de producción. Casi ningún equipo la va a detectar, porque sus evals son stateless por defecto.
Cómo se traduce esto al runbook
Cuando a la guardia le entra una alerta de costo o latencia en un agente, la primera pregunta ya no es «¿cambió el modelo?», sino «¿cambió la tasa de aciertos del cache?». El runbook incluye hoy un dashboard de cache hit rate por ruta de agente, alertas para ventanas sostenidas de cache miss y una vía de rollback para las ediciones de prompt que rompieron el prefijo estático.
El modelo frontier sigue siendo el modelo. El cache es el sistema a su alrededor, y es lo que decide si el agente se puede operar a la escala a la que de verdad piensas ejecutarlo.