Cloudflare lanzó el 6 de julio de 2026 Workers Cache, una caché tiered que se coloca delante de un Worker y se controla con Cache-Control. En un hit, Cloudflare devuelve la respuesta desde caché sin ejecutar el Worker. En un miss, el Worker corre y, si la respuesta es cacheable, queda guardada para la siguiente solicitud.

Esto no es una noticia "de IA" en la superficie. Pero para builders que despliegan agentes, tool endpoints, previews generados o APIs de soporte en Workers, sí cambia una parte práctica del costo: no todo request repetido debería volver a invocar lógica, modelos, fetches internos o backends.

Ruta editorial de Workers Cache con lower tier, upper tier, hit, miss y ejecución del Worker solo cuando hace falta

Qué cambia frente al Cache API

La documentación nueva marca dos diferencias que importan. Primero, la caché vive delante del Worker: Cloudflare puede revisar caché antes de ejecutar tu código. Segundo, Workers Cache es tiered por defecto. La primera respuesta cacheable puede llenar una capa superior y luego servir solicitudes desde distintos data centers sin volver a correr el Worker.

Cloudflare también destaca request collapsing: cuando muchas solicitudes simultáneas llegan para la misma clave y no hay respuesta cacheada, el Worker se ejecuta una vez y las demás esperan ese resultado. Para un endpoint de agente, eso evita el patrón caro donde una ráfaga de usuarios provoca cien ejecuciones idénticas.

La configuración es mínima: habilitas caching en Wrangler y expresas comportamiento con headers estándar. La documentación aclara que aplica a invocaciones fetch(): requests de usuarios, service bindings y loopback fetch() vía ctx.exports. Los métodos RPC custom no pasan por esta caché.

Dónde sí usarlo en agentes

No cachearía una respuesta generada por un modelo si depende de datos privados, memoria de usuario o estado vivo. Pero sí hay superficies de agente que suelen ser repetibles:

manifiestos de herramientas y metadata pública;
previews estáticos generados por una tarea;
respuestas de documentación o catálogos versionados;
resultados de endpoints internos que cambian cada cierto tiempo;
assets o snapshots de evaluaciones no sensibles;
páginas de estado que reciben tráfico repetido.

Panel editorial de service bindings, ctx.exports, headers Cache-Control y endpoints de agente separados por cacheabilidad

El diseño correcto es separar rutas. Un endpoint /agent/run probablemente no debe cachearse. Un endpoint /tools/catalog, /preview/:id, /docs/context/:version o /evals/report/:sha puede tener max-age o stale-while-revalidate si no contiene datos sensibles.

El riesgo: cachear contexto equivocado

La caché reduce CPU, pero también puede amplificar errores. Si olvidas Vary, si mezclas tenants en una misma key o si mandas Cache-Control demasiado agresivo en una respuesta personalizada, puedes servir contexto equivocado. En agentes, eso es más grave que una página vieja: puede alimentar una decisión automática con datos de otro usuario o versión.

Por eso el checklist mínimo sería:

listar rutas cacheables y no cacheables;
revisar si la respuesta contiene identidad, tokens o memoria;
definir keys por tenant o versión cuando aplique;
observar Cf-Cache-Status antes de celebrar ahorro;
purgar o versionar cuando cambie el contrato de la herramienta.

La demanda se infiere por señales actuales: lanzamiento oficial del 6 de julio, docs actualizadas el mismo día, adopción fuerte de Workers para agentes y búsquedas como Cloudflare Workers Cache, Workers Cache Cache-Control, Cloudflare agent endpoints cache y Workers service bindings cache.

Agente IA puede competir porque la pregunta en español no es "cómo activar caché", sino qué partes de un sistema agentic son cacheables sin romper privacidad, frescura ni trazabilidad. Si estás desplegando tu primer agente, primero ordena el flujo base en el curso gratis; luego usa caché donde el contrato sea explícito.