@cloudflare/computer: un runtime para agents que escala con isolates y contenedores

Introducción

Los agents modernos requieren más que un contenedor para escalar. Asignar un contenedor por agent no es sostenible: según Cloudflare, incluso los hyperscalers no tienen suficiente compute para manejar cientos de millones de agents concurrentes. El problema no es solo GPU, sino CPU: la demanda de recursos para ejecutar código en sandbox está superando la capacidad disponible.

Cloudflare propone una solución híbrida con su nueva librería open source @cloudflare/computer. En lugar de forzar a todos los agents a usar contenedores, el runtime selecciona dinámicamente entre isolates (livianos y ultra rápidos) y contenedores Linux completos, según las necesidades de cada tarea.

Qué ocurrió

Cloudflare lanzó en early preview la librería @cloudflare/computer, un runtime para agents que abstracta la complejidad de elegir entre diferentes entornos de ejecución. La librería provee:

• Un filesystem virtual persistente (backed por SQLite) que puede populese desde storage en la nube, repositorios git o archivos locales.
• Múltiples backends de ejecución: isolates (basados en Cloudflare Workers) y contenedores Linux, con una interfaz unificada (exec(command, options)).
• Herramientas integradas para agents (lectura/escritura de archivos, edición con «Code Mode», ejecución de bash), compatibles con SDKs de IA como @cloudflare/think.

El enfoque clave es que el agent mismo decide qué backend usar. En pruebas internas, los modelos frontaleros (como los de Cloudflare) seleccionaron correctamente el isolated para tareas como manipulación de archivos, testing de JavaScript o generación de documentación, reservando los contenedores solo para commands que requieren Linux, npm o binarios nativos.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de infraestructura, @cloudflare/computer abordan tres desafíos concretos:

Los isolates (el mismo primitivo usado en Workers y Durable Objects) se inician en milliseconds, hibernan cuando están idle y escalan a millones de instancias sin overhead. Cloudflare afirma que este modelo permite manejar billones de requests por día con recursos mínimos. Al usar isolates para el 90%+ de las tareas (según la meta de Cloudflare), se reduce la presión sobre el cluster de contenedores.

Ejecutar un isolated consume menos recursos que un contenedor Linux. En el modelo de Cloudflare, solo se incurre en el costo del container cuando es estrictamente necesario (ej.: instalar dependencias con npm install). Esto es crítico para workloads con spiky traffic, donde los agents se crean y destruyen masivamente.

Todas las operaciones sobre el filesystem están gated y registradas. El workspace define qué cambios puede hacer el agent (ej.: permitir writes en /src pero no en /config). Esto genera un paper trail detallado, útil para debugging y cumplimiento. Además, los isolates de Cloudflare corren en un sandbox basado en V8 con restricciones estrictas, mientras que los contenedores se ejecutan en un entorno aislado con kernel compartido (similar a AWS Firecracker).

Detalles técnicos

Arquitectura

• Filesystem: Virtual, basado en SQLite, con soporte para operaciones atómicas y snapshotting. Se puede inicializar desde:

– Un bucket de storage (R2, S3, etc.).

– Archivos uploadados manualmente.

• Backends de ejecución:

– Container backend: Levanta un contenedor Linux (usando Cloudflare Containers, compatible con imágenes OCI). Requerido para:

– Binarios nativos (ej.: ffmpeg, git).

– Runtime no-JS (Java, Python, etc.).

– Acceso a kernel features (ej.: iptables).

Interfaz para agents

La librería incluye un toolkit compatible con SDKs de IA como @cloudflare/think o LangChain.js. Las herramientas expuestas son:

// Herramientas disponibles para el agent
const tools = {
  filesystem: {
    read: workspace.tools.read,
    write: workspace.tools.write,
    edit: workspace.tools.edit, // Abre un editor de código en contexto
    ls: workspace.tools.ls,
  },
  shell: {
    exec: workspace.tools.exec, // Ejecuta commands en bash
  },
};

// Ejemplo de prompt para el agent
const response = await ai.exec({
  messages: [{
    role: "user",
    content: "Fix the TypeScript errors in src/index.ts"
  }],
  tools,
});

El exec tool acepta un parámetro backend (opcional). Si no se especifica, el agent decide automáticamente. Las descripciones de las herramientas (en el schema) guían esta decisión:

// Definición del tool 'exec' en el schema
{
  name: "exec",
  description: "Execute a command in a shell. Use the 'container' backend for commands that require Linux, npm, or native binaries. Use the 'worker' backend for JavaScript-only tasks.",
  parameters: {
    type: "object",
    properties: {
      command: { type: "string" },
      backend: { type: "string", enum: ["worker", "container"] },
    },
  },
}

Integración con Durable Objects

Cada workspace se asocia a un Durable Object (DO), lo que proporciona:

• Stateful: El filesystem persiste entre requests.
• Single-threaded: Evita race conditions en modificaciones concurrentes.
• Escalabilidad automática: Cloudflare escalan los DOs horizontalmente según la carga.

Ejemplo de inicialización en un DO:

// En un Durable Object (index.js)
import { Computer } from "@cloudflare/computer";

export class AgentEnvironment {
  async fetch(request) {
    // Crear un workspace para este agent
    const computer = new Computer();
    const workspace = await computer.createWorkspace({
      // Filesystem inicial desde un repo git
      root: "https://github.com/owner/repo",
    });

    // Exponer herramientas al agent
    const tools = workspace.tools;
    // ... lógica del agent ...
  }
}

Rendimiento

En benchmarks internos de Cloudflare:

• Tiempo de startup:

– Contenedor: ~500ms (cold start).

• Concurrency: Los isolates permiten millones de instancias concurrentes en un único node, mientras que los contenedores están limitados por la densidad de VMs.

Qué deberían hacer los equipos técnicos

• Agents que combinan tasks livianas (edición de files, análisis de código) con operaciones pesadas (ejecución de builds).
• Workloads con tráfico espiky donde el costo de cold starts de contenedores es prohibitivo.
• Equipos que ya usan Cloudflare Workers/Durable Objects y quieren extenderlos con capacidades de filesystem.

Instalar la librería y experimentar con los ejemplos:

npm install @cloudflare/computer

Clonar el repositorio con ejemplos y tutoriales:

git clone https://github.com/cloudflare/computer
cd computer
npm install
npm run example:triage-bugs  # Ejemplo de agent que triage issues de GitHub

• Default: Configurar el worker backend como default y usar container solo para commands específicos.
• Fallback: Implementar lógica para retry con container si el isolated falla (ej.: module not found).
• Cost control: Monitorear el uso de containers (via Cloudflare Analytics) y setear límites por agent.

• Comenzar con agents internos o de bajo riesgo.
• Comparar costos y performance vs. soluciones actuales (ej.: contenedores en Kubernetes).
• Aprovechar la auditabilidad para validar el comportamiento de los agents antes de escalar.

Conclusión

Queda por ver cómo se comportará en entornos multi-cloud (por ahora solo soporta backends de Cloudflare) y si el overhead de decidir el backend impacta la latencia. Sin embargo, el modelo híbrido y los resultados internos de Cloudflare lo convierten en una opción prometedora para la próxima generación de sistemas agentic.

Fuentes

• https://blog.cloudflare.com/cloudflare-computer/
• https://www.netbsd.org/changes/