Cloudflare Computer: runtime para agents con isolates

En pocas palabras: Cloudflare anunció el 4 de agosto de 2026 @cloudflare/computer, un runtime que combina isolates ultrarrápidos y contenedores Linux, y deja que el modelo los elija. Menos del 10% de tareas justifican un contenedor, ahorrando costos y acelerando la ejecución.

Cloudflare acaba de sacudir el tablero de la infraestructura para agents. El 4 de agosto de 2026, la empresa anunció @cloudflare/computer, un runtime que no se conforma con meter cada agente en un contenedor y rezar — combina isolates ultrarrápidos con contenedores Linux on-demand, y deja que el modelo decida cuál usar en cada paso.

@cloudflare/computer es un runtime para agents cloudflare que orquesta dinámicamente entre dos entornos de ejecución: isolates de Workers (arrancan en ~10ms, escalan a millones de instancias por nodo) y contenedores Linux completos (para cuando posta necesitás npm, binarios nativos o un filesystem POSIX de verdad). La idea es simple: menos del 10% de las tareas de un agente justifican levantar un contenedor entero. El 90% restante — leer archivos, editar código, correr tests de JavaScript, generar docs — se resuelve en isolates que hibernan cuando no se usan y no te cobran por el tiempo muerto.

Cloudflare es una red de entrega de contenido y servicios de seguridad web creada por Cloudflare Inc., diseñada para acelerar y proteger sitios web, aplicaciones y APIs mediante una infraestructura de proxy inverso.

¿Qué problema resuelve @cloudflare/computer para los agents?

El problema no es nuevo, pero se volvió urgente. Si querés correr agents a escala — cientos de millones de instancias concurrentes procesando repositorios, editando archivos, ejecutando comandos — no podés asignarle un contenedor a cada uno. El costo se va al carajo y la latencia de spinning up un container por request te mata la experiencia.

Cloudflare ya tenía las piezas: Workers con isolates que arrancan en milisegundos, Durable Objects para persistencia, y una red global que llega a todos lados. Lo que faltaba era un runtime que uniera todo con una interfaz pensada para agents, donde el modelo de lenguaje elige en tiempo real si ejecuta cada comando en un isolate barato o en un contenedor con sistema operativo completo. Eso es @cloudflare/computer. La métrica que ellos mismos ponen sobre la mesa: menos del 10% del trabajo del agente necesita contenedor. El 90% restante — manipular archivos, testing básico de JavaScript, generación de documentación — se resuelve en isolates que hibernan cuando están idle (sí, hibernan de verdad, no es un eufemismo para “quedan colgados”).

¿Cómo funciona el runtime híbrido de Cloudflare?

La arquitectura se apoya en tres patas: Workspace, Isolate Runtime y Container Runtime. El Workspace es un filesystem virtual persistente con SQLite como backend, que puede poblarse desde repositorios git, buckets de storage o archivos locales. Se instancia en cualquier Durable Object, así que sobrevive a reinicios y se replica global. En gestionar secretos de forma segura profundizamos sobre esto.

Los dos runtimes comparten la misma interfaz exec(command, options). El isolate runtime usa just-bash para traducir llamadas de shell a JavaScript, lo que le da al agente un entorno donde leer, escribir, editar archivos y correr scripts de Node funciona sin levantar una VM. El container runtime, en cambio, monta un contenedor Linux con FUSE para sincronizar el filesystem del Workspace en ambas direcciones — el agente no se entera de que los archivos en realidad viven en un Durable Object. Lo interesante es que el modelo decide cuál backend usar guiado por la descripción de la herramienta: si el comando es npm install, va a contenedor; si es cat src/index.ts, va a isolate. Los modelos frontier, según Cloudflare, son buenos para elegir.

¿Qué herramientas incluye el toolkit para agents?

El paquete viene con un toolkit compatible con los AI SDKs más usados. Las herramientas base son cinco: read, write, edit (con un modo Code que entiende diff y contexto de archivo), ls y exec. Nada extravagante, pero cubren el 95% de lo que un agente hace en un entorno de desarrollo.

Lo que marca la diferencia es que todas las operaciones sobre el filesystem están gated, auditadas y observadas. El workspace define explícitamente qué cambios puede hacer el agente — por ejemplo, permitir writes en /src pero bloquear /config — y cada modificación genera un paper trail completo. Esto no es un detalle cosmético: cuando estás corriendo agents en producción y algo sale mal (spoiler: siempre sale mal en algún momento), necesitás saber exactamente qué archivo se tocó, cuándo y por qué.

¿Cuándo conviene un isolate y cuándo un contenedor?

La diferencia de arranque es brutal: ~10ms un isolate contra ~500ms de cold start un contenedor. Los isolates pueden escalar a millones de instancias concurrentes por nodo y hibernan cuando están idle; los contenedores están limitados por densidad de VMs y te cobran mientras existen, aunque no hagan nada.

Acá va una tabla con criterio de decisión, basada en lo que el equipo de Cloudflare documentó:

Tipo de tarea	Backend recomendado	Por qué
Leer/editar archivos	Isolate	No necesita binarios nativos ni sistema operativo
Testing de JavaScript/TypeScript	Isolate	Node corre en el isolate sin problema
Generación de docs	Isolate	Renderizado y markdown no requieren Linux
Procesamiento de datos	Isolate	Operaciones sobre archivos en el Workspace
npm install / dependencias nativas	Contenedor	Necesita binarios compilados y linker del SO
Binarios nativos (Go, Rust, C)	Contenedor	Requieren sistema operativo completo
Comandos que asumen Linux (git, curl, ffmpeg)	Contenedor	No hay traducción posible a JavaScript

Ponele que tu agente está refactorizando un proyecto React. Lee archivos con read, edita componentes con edit, corre tests con exec — todo eso va por isolates. Cuando necesita instalar una dependencia nueva con npm install, el runtime automáticamente levanta un contenedor, ejecuta el comando, sincroniza los cambios al Workspace vía FUSE y destruye el contenedor. El agente ni se entera del cambio de backend. (¿Funciona siempre tan limpio? Habría que verlo en producción con cargas reales, pero la arquitectura tiene sentido.) Tema relacionado: evitar caídas por DNS.

¿Cómo se instala y configura @cloudflare/computer?

La instalación es directa: npm install @cloudflare/computer. Instanciás un Workspace en un Durable Object, lo poblás desde un repositorio git o un bucket, y le pasás las herramientas al agente. El filesystem expone un wrapper compatible con node:fs, así que librerías de terceros funcionan sin modificaciones — al menos en teoría.

Un ejemplo mínimo que circuló en la preview técnica se ve así: importás el paquete, creás un workspace con new Workspace(), lo populás con workspace.populateFromGit(repoUrl), y pasás workspace.getTools() al agente. La magia está en que el mismo workspace se puede usar desde un isolate o desde un contenedor, y el estado persiste entre ejecuciones porque el Durable Object lo respalda con SQLite. Si alguna vez configuraste Workers con Durable Objects, la curva de aprendizaje es mínima. Si venís de un mundo de contenedores puros, te va a llevar un rato acostumbrarte a que el filesystem no es “real” sino virtualizado — pero el paper trail y la auditoría que ganás lo compensan.

¿Qué ventajas tiene este enfoque frente a los contenedores tradicionales?

La ventaja principal es económica y operativa: un contenedor por agente no escala a miles de millones de agents, por más plata que le pongas al clúster. Los isolates son el primitivo que Cloudflare viene usando en Workers hace años — arranque rápido, hibernación, estado del agente — y ahora podés attached contenedores on-demand solo cuando hacen falta. El runtime abstrae la complejidad de combinar ambos mundos en userspace, así que vos no tenés que escribir la lógica de “si el comando necesita Linux, levantá un container; si no, mandate por el isolate”.

Para equipos en Latinoamérica que corren agents sobre infraestructura cloud, la ecuación es directa: menos tiempo de cómputo ocioso, menos presión sobre el clúster de contenedores, y un modelo de costos que se alinea con lo que realmente ejecutás. Si estás armando un producto que depende de agents y ya usás Cloudflare Workers, esto te baja la complejidad operativa de un saque. Si tu stack de hosting es más tradicional — con donweb.com o similar para VPS y dominios —, probablemente no migres todo de golpe, pero el enfoque híbrido de isolates + contenedores es un norte interesante hacia dónde va la infraestructura para agents.

Qué está confirmado y qué no sobre Cloudflare Computer

Confirmado:

• @cloudflare/computer se anunció el 4 de agosto de 2026 y está en preview técnica.
• El Workspace usa SQLite como backend, se persiste en Durable Objects y se puede poblar desde git, buckets o archivos locales.
• Los dos runtimes — isolate y container — comparten la interfaz exec(command, options).
• El toolkit incluye read, write, edit (con Code Mode), ls y exec, compatibles con AI SDKs.
• Todas las operaciones sobre el filesystem están gated, auditadas y generan paper trail.
• Los isolates arrancan en ~10ms; los contenedores tienen cold starts de ~500ms.
• La instalación es vía npm: npm install @cloudflare/computer.

No confirmado / Sin datos:

• Precios y modelo de facturación. Cloudflare no publicó pricing al momento del anuncio.
• Fecha de disponibilidad general (GA). Solo se sabe que está en preview.
• Benchmarks independientes de latencia y throughput con cargas reales, más allá de los ~10ms y ~500ms declarados.
• Compatibilidad con otros AI SDKs más allá de los mencionados en el anuncio.
• Límites concretos del Workspace: tamaño máximo, cantidad de archivos, concurrencia de escrituras.

Errores comunes al usar @cloudflare/computer

Asumir que todo corre en contenedor. El reflejo de envolver cada agente en un container es difícil de sacarse. Si venís de Docker y Kubernetes, lo primero que vas a hacer es forzar todas las tareas por el container runtime. Error. Dejá que el modelo elija — para eso está la orquestación dinámica. El 90% de las operaciones no necesitan Linux y vas a pagar costo y latencia al pedo.

No definir bien los límites del workspace. El workspace tiene gating de escritura por path, pero si no lo configurás explícitamente, es como dejar la puerta sin llave. Definí desde el día uno qué directorios permiten escritura. Un agente que mete mano en /config sin que lo sepas es un problema que no querés debuggear un domingo a las 3 AM. Lo explicamos a fondo en comparamos los arranques en frío.

Ignorar el paper trail hasta que lo necesitás. Cada operación genera auditoría, pero si no la revisás periódicamente, estás acumulando logs que solo vas a mirar cuando algo explote. Integrá el paper trail en tu flujo de monitoreo desde el inicio, no como idea de último momento.

Tratar el Workspace como un filesystem POSIX tradicional. Está respaldado por SQLite y se sincroniza vía FUSE con los contenedores. Las operaciones de I/O intensivas no van a tener la misma performance que un disco local. No es un problema para el 95% de los casos de uso de agents, pero si tu flujo depende de leer y escribir gigabytes por minuto, vas a notar la diferencia.

Preguntas Frecuentes

¿Qué es @cloudflare/computer?

Es un runtime para agents anunciado por Cloudflare el 4 de agosto de 2026 que orquesta dinámicamente entre dos entornos de ejecución: isolates rápidos (arranque en ~10ms) y contenedores Linux completos. El agente decide en tiempo real cuál backend usar según la tarea, con menos del 10% de las operaciones requiriendo contenedor.

¿Cómo se diferencia un isolate de un contenedor en Cloudflare Computer?

Los isolates arrancan en ~10ms, escalan a millones de instancias concurrentes por nodo y hibernan cuando están idle. Los contenedores tardan ~500ms en cold start y están limitados por densidad de VMs. El isolate runtime traduce comandos shell a JavaScript con just-bash; el container runtime monta un Linux completo con FUSE para sincronizar el filesystem. Relacionado: sin costo de egreso en R2.

¿Cuánto cuesta @cloudflare/computer?

Cloudflare no publicó precios al momento del anuncio en agosto de 2026. El producto está en preview técnica y no hay modelo de facturación confirmado. Lo lógico sería un pricing basado en tiempo de cómputo diferenciado entre isolates (más baratos) y contenedores (más caros), pero es especulación hasta que salga el anuncio oficial.

¿Cómo se instala @cloudflare/computer?

Se instala con npm install @cloudflare/computer. El Workspace se instancia en un Durable Object, se pobla desde un repositorio git o bucket de storage, y las herramientas se pasan al agente vía AI SDK. El paquete expone un wrapper compatible con node:fs para que librerías de terceros funcionen sin modificaciones.

¿@cloudflare/computer reemplaza a Docker para agents?

No en todos los casos. Para el 90% de las tareas — manipulación de archivos, testing de JavaScript, generación de docs — los isolates reemplazan al contenedor con mejor performance y menor costo. Pero cuando necesitás binarios nativos, npm install con dependencias compiladas o comandos que asumen Linux, el contenedor sigue siendo necesario y el runtime lo levanta automáticamente.

Conclusión

Cloudflare metió un gol donde pocos estaban mirando. Mientras el resto de la industria sigue empaquetando agents en contenedores como si fueran microservicios del 2019, @cloudflare/computer plantea una arquitectura que reconoce algo obvio pero ignorado: la mayoría de las operaciones de un agente no necesitan un sistema operativo completo. Usar isolates para el 90% de las tareas y contenedores solo cuando posta hacen falta no es un truco de optimización — es sentido común.

Lo que falta, y no es poco, es ver cómo se comporta en producción con cargas reales, qué pricing le ponen y cuándo sale de preview. Pero la dirección es la correcta. Si estás construyendo productos con agents y tu stack ya pasa por Cloudflare, ponelo en el radar. Si todavía no, igual vale la pena seguir de cerca cómo evoluciona: el patrón de isolates + contenedores on-demand probablemente se convierta en estándar en los próximos dos años.

Fuentes

• Cloudflare Blog — Anuncio oficial de @cloudflare/computer
• Blog Sied — Cloudflare Computer: un runtime para agents que escala con isolates y contenedores
• Developers Digest — Cloudflare Computer Agent Runtime Preview 2026