Las páginas de precios de todos los vendors frontier hoy distinguen entre tokens de input con y sin cache en una relación cercana a diez a uno. La mayoría del código de agentes que auditamos lo ignora. Los agentes funcionan. Solo cuestan cinco a diez veces lo que deberían y corren dos a cuatro veces más lento de lo que deberían, 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.
La arquitectura consciente del cache es uno de los cambios de mayor palanca disponibles para un equipo que corre agentes en producción ahora mismo. La mayoría no lo ha hecho porque el cache es invisible hasta que lo instrumentas.
Por qué esto es un problema de 2026 y no de 2025
Dos cosas cambiaron. Los TTL de cache se hicieron lo bastante largos como para importar en flujos reales — la ventana práctica hoy está entre cinco minutos y una hora en los principales vendors, según el tier. Y los workflows agentic que de verdad necesitan esa ventana — agentes de horizonte largo, loops multi-turno con uso de tools, workers de background — pasaron de demo a producción.
La mayor parte del código de agentes en producción se escribió antes de que ninguna de esas dos cosas fuera cierta. La línea de costo en la factura es el síntoma visible. La cola de latencia es el síntoma operativo. Ninguno aparece hasta que se mira.
Qué significa "consciente del cache" en concreto
Tres reglas de diseño concretas.
Primera: el prefijo estático es sagrado. El system prompt, las definiciones de tools y las instrucciones duraderas tienen que ser byte-estables en cada llamada de una sesión. Hemos visto a equipos romper su propio cache inyectando un timestamp en el system prompt "para debug". Ese timestamp invalida el cache en cada llamada y duplica la factura sin que nadie lo note.
Segunda: la conversación crece por append, no por edit. Si la historia del agente se reescribe a mitad de sesión — se resume, se reordena, se prefija con instrucciones nuevas — el cache de todo lo que viene después del punto de edición se pierde. La compactación tiene que ocurrir en fronteras planificadas, no oportunísticamente.
Tercera: el loop del agente debería diseñarse alrededor del TTL, no contra él. Si la ventana de cache es de cinco minutos, un patrón de sleep-and-poll que despierta cada seis minutos paga el cache miss en cada iteración. Un patrón de sleep-and-poll que despierta cada cuatro minutos no. La diferencia es una línea de configuración y aproximadamente la mitad de la factura.
El ángulo de evaluación
El arnés de evaluación tiene que saber del cache. Una evaluación verde que corre en estado frío, sin cache, prueba que el agente funciona correctamente. No prueba que el agente funcione correctamente en producción, donde el estado del cache cambia el comportamiento del modelo en los márgenes — particularmente en contextos largos donde las lecturas con cache y las lecturas frescas pueden producir muestreos sutilmente diferentes.
Hoy corremos la evaluación dos veces en cada cambio: una en frío, una en caliente. Una regresión en la corrida en caliente que es invisible en la corrida en frío es una regresión real de producción. La mayoría de los equipos no la va a detectar porque sus evaluaciones son stateless por defecto.
Cómo se ve esto en el runbook
Cuando la guardia recibe una alerta por costo o latencia en un agente, la primera pregunta ya no es "¿cambió el modelo?" — es "¿cambió la tasa de hit del cache?" El runbook hoy incluye un dashboard de cache hit rate por ruta del agente, alertas para ventanas sostenidas de cache miss, y un camino de rollback para ediciones de prompt que rompieron el prefijo estático.
El modelo frontier sigue siendo el modelo. El cache es el sistema a su alrededor que decide si el agente es operable a la escala a la que de verdad planeas correrlo.