Vercel Runtime Logs añade Cache Reason: por qué tu agente ve un MISS o STALE
Vercel añadió Cache Reason a Runtime Logs el 17 de julio de 2026. La señal explica por qué una respuesta no fue un hit fresco y ayuda a depurar latencia, datos viejos y costos en aplicaciones con agentes.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Un agente puede responder lento por el modelo, por una tool o por una caché que nunca fue un hit. Desde el 17 de julio de 2026, Vercel Runtime Logs añade Cache Reason, una señal que explica por qué una solicitud no se sirvió como contenido fresco. Para una aplicación con agentes, ese detalle permite separar un problema de inferencia de uno de entrega.
El cambio cubre respuestas que la CDN puede almacenar, incluidas ISR, Partial Prerendering y funciones que envían directivas como stale-while-revalidate. Una respuesta que se renderiza de forma dinámica en cada solicitud no tendrá razón de caché. Esa frontera es importante: no conviene interpretar la ausencia del campo como un fallo.
La diferencia entre MISS, BYPASS y STALE
Vercel separa el estado visible de la causa que lo produjo. Los casos que más ayudan a investigar agentes son:
- MISS: la entrada estaba fría, la solicitud fue colapsada o hubo un error.
- BYPASS: la respuesta quedó fuera por Draft Mode, un prerender bypass o un crawler.
- STALE: hubo revalidación por tiempo, invalidación por tag o un error al revalidar.
- REVALIDATED: una eliminación basada en tag produjo una nueva respuesta.
La distinción evita un diagnóstico flojo. Un STALE no dice que el modelo haya inventado información; dice que la solicitud recibió una entrada que necesitaba revalidación. Un MISS tampoco significa necesariamente que la aplicación esté mal: quizá es la primera consulta después de un deploy o una ruta con poca repetición.
Para un agente, la pregunta adicional es qué tipo de dato está detrás de la respuesta. Una página pública puede tolerar caché. Un panel de herramientas, una lista de permisos o el estado de una aprobación humana normalmente necesita una política mucho más estricta. Si mezclas ambos casos bajo el mismo endpoint, una optimización de caché puede terminar pareciendo un error de razonamiento.
Cómo usar la señal en una investigación
El changelog permite consultar el motivo desde Runtime Logs y desde la CLI. Un flujo mínimo para una solicitud sospechosa es:
vercel logs \
--request-id <request-id> \
--expand --json \
--project <project> \
--scope <team>
Después agrupa el tráfico para buscar una tendencia, no solo un caso llamativo:
vercel metrics vercel.request.count \
--group-by cache_reason \
--since <time> \
--project <project> \
--scope <team>
Para un agente que consulta documentos o APIs, añade a cada traza el identificador de sesión, la tool llamada, el modelo, el tamaño de la respuesta y el estado de caché. Así puedes comprobar si el costo viene de repetir una consulta, de invalidar demasiado pronto o de enviar al modelo el mismo contexto una y otra vez.
Tres controles antes de optimizar
Primero, separa datos públicos, datos por usuario y resultados de herramientas con efectos secundarios. Segundo, define qué evento invalida cada tag y comprueba que el agente no dependa de una respuesta anterior a una aprobación. Tercero, compara calidad y latencia: un hit de caché rápido no sirve si entrega un permiso vencido o un inventario incorrecto.
La búsqueda Vercel Cache Reason, Vercel Runtime Logs cache reasons y depurar caché en agentes tiene intención operativa; la demanda se infiere del changelog, la referencia oficial de estados y los comandos de observabilidad, no de volumen SEO inventado. La actualización complementa las decisiones de estado regional que Vercel ya documentó para Workflows durables: una ejecución puede estar bien ubicada y aun así diagnosticar mal sus respuestas si no ve por qué la caché decidió servirlas.