Recientemente terminamos de migrar el agente de camelAI fuera de las máquinas virtuales. El agente ahora se ejecuta dentro de un Cloudflare Durable Object, su sistema de archivos vive en SQLite y R2, y escribe JavaScript en lugar de bash. La mayoría de los equipos ejecutan agentes de codificación en una máquina virtual Linux completa o en un contenedor sandbox, y nosotros también solíamos hacerlo.
Queríamos salir de las VMs porque dar a cada usuario una máquina siempre encendida con disco adjunto era demasiado costoso para escalar. La parte difícil es que los agentes de codificación asumen Linux. Están entrenados para recurrir a bash, y el harness con el que lanzamos requería una VM completa, así que llegar hasta aquí nos llevó tres rediseños. La contrapartida es que el agente ahora solo puede hacer cosas para las que hemos construido un método explícito, lo que suena limitante, pero ha sido bueno para el producto.
Soy Miguel, CTO de camelAI. Nuestro código base se volvió recientemente de código abierto, así que todo lo que se menciona en este artículo es código que puedes leer en github.com/qaml-ai/camelAI. Iré enlazando los archivos relevantes a medida que avanzamos. Aquí está la progresión.
Paso cero: la era de las VM
Lanzamos con el harness de Claude Code, que necesita una máquina virtual completa para funcionar. Probamos varios proveedores de VM, ninguno cumplía con nuestros requisitos de persistencia y rendimiento, y terminamos construyendo nuestro propio servicio de contenedores. Ese artículo sigue en línea, pero ya no ejecutamos nada de esa infraestructura.
El servicio de contenedores funcionaba, pero era pesado. Una VM siempre encendida por cada usuario es costosa, y también lo es mantener los archivos de cada usuario en un disco rápido adjunto. Escalarlo significa escalar máquinas reales con discos reales, lo que iba a ser prohibitivamente caro para los números de usuarios que buscamos. Así que, en lugar de ingeniar soluciones para la orquestación de VMs, empezamos a diseñar pensando en no necesitar una VM en absoluto.
Paso uno: sacar al agente de la VM
El harness de Claude Code es inseparable de su VM, así que el primer movimiento fue construir nuestro propio harness. Lo construimos sobre pi, el agente de codificación de código abierto de Mario Zechner. pi es una pila de librerías. La capa más alta asume un sistema operativo normal, pero las capas inferiores te dan las primitivas del agente, como el bucle del agente y la gestión de estado, sin importar dónde se ejecuten. No modificamos ningún código de pi. Importamos esas capas inferiores y construimos nuestro propio harness sobre ellas, ejecutándose dentro de un Cloudflare Durable Object en lugar de un entorno Linux.
Un Durable Object es una pequeña instancia de cómputo con estado que se activa en el borde de Cloudflare, cerca del usuario que lo creó. Cada hilo de chat tiene su propio Durable Object, lo que redujo la latencia por sí solo en comparación con enrutar todo a través de un host centralizado de VM.
En esta etapa mantuvimos las VMs, pero el agente ya no vivía dentro de una. Se comunicaba con la VM de forma remota cuando necesitaba ejecutar comandos. Anthropic describe esta misma división para sus agentes gestionados: el cerebro separado de las manos. Esto nos dio algunas propiedades interesantes:
- El agente comienza a responder antes de que la VM esté despierta, porque no espera a que arranque una máquina.
- La VM puede volver a dormirse mientras el agente sigue trabajando, o nunca despertarse si el turno no necesita ningún comando.
- Un cerebro puede controlar varias manos. Un solo agente podría operar varias VMs a la vez.
A esas manos las llamamos proyectos. Cada proyecto venía con una VM para ejecutar comandos y un repositorio git creado programáticamente a través de Cloudflare Artifacts, que es un almacenamiento compatible con git que puedes aprovisionar sobre la marcha desde un Worker. El agente realmente no sabía que se estaba ejecutando fuera de la VM. Todavía tenía bash y funcionaba como cualquier otro agente de codificación.
El problema es que esto solo solucionó la latencia, y nada más. Todavía teníamos una VM por usuario, así que seguíamos teniendo todos los problemas de coste y escalabilidad del diseño original.
Paso dos: eliminar la VM
La siguiente versión mantuvo la misma estructura de proyectos pero eliminó la VM detrás de ellos. Ahora cada proyecto está respaldado por un sistema de archivos que vive dentro de un Durable Object, con R2 detrás para archivos más grandes.
No inventamos esto. El equipo de agents de Cloudflare construyó Shell, un sistema de archivos experimental y runtime de ejecución para Workers, y reutilizamos su código en gran medida. La mecánica es simple. El almacenamiento de un Durable Object es una base de datos SQLite con un límite de 10 GB, y cada fila tiene un tamaño máximo. Los archivos pequeños viven directamente en las filas de SQLite. Los archivos de más de aproximadamente 1.5 MB se escriben en R2, y la fila de SQLite solo contiene un puntero. Para el agente, parece un sistema de archivos normal, pero por debajo es una base de datos y almacenamiento de objetos, por lo que la persistencia son datos almacenados en lugar de infraestructura que debemos mantener activa.
El historial de versiones sigue funcionando a través de Artifacts, por lo que cada proyecto mantiene un historial git sin que nosotros alojemos un servidor git.
Paso tres: eliminar bash
Eliminar bash parecía drástico. Los agentes de codificación están entrenados para recurrir a bash, y bash es la razón por la que todo el mundo los ejecuta en VMs. También era un problema más allá del coste. Un agente con bash y acceso a red necesita credenciales para hacer algo útil, y nuestros intentos de URLs proxy autenticadas se estaban volviendo endebles y difíciles de aplicar.
Así que lo eliminamos. En lugar de bash, el agente escribe JavaScript, ejecutado a través de Code Mode y los cargadores dinámicos de Workers de Cloudflare. Cada ejecución se ejecuta en un nuevo entorno aislado V8 que arranca en milisegundos y utiliza unos pocos megabytes de memoria. El sandbox viene precargado con las conexiones de datos del usuario y con métodos para todo lo que la plataforma puede hacer. Las credenciales nunca entran en el sandbox. El agente llama a los métodos de una conexión, y la autenticación ocurre en nuestro lado.
Cuando observas para qué usan realmente bash los agentes, perderlo cuesta menos de lo que esperas. La mayor parte son operaciones de archivos, para las cuales el agente tiene herramientas nativas. Le damos lectura, escritura y edición, además de nuestras propias implementaciones de grep y glob. Eso cubre el 80-20. El resto son comandos específicos para tareas específicas, y esos se convirtieron en métodos explícitos:
- wrangler deploy a través de un proxy se convirtió en un método deploy_project que controlamos completamente. Como sabemos exactamente cuándo ocurre un despliegue, podemos engancharlo y abrir una vista previa en vivo automáticamente. Antes, teníamos que olfatear el tráfico de wrangler proxy para adivinar qué hilo había desplegado algo.
- Compilar la aplicación del usuario y ejecutar notebooks de Python se convirtieron en sus propios métodos, ambos respaldados por contenedores de corta duración.
Mantuvimos contenedores para esos dos trabajos porque realmente necesitan Linux. Las aplicaciones de usuario se compilan con Vite, Tailwind y React Router, y añadir dependencias significa ejecutar bun install. Consideramos ejecutar las compilaciones dentro de un Worker, ya que lo que se compila es en sí mismo un Worker, pero ese camino no está bien soportado, y los Workers tienen un límite de memoria de 128 MB y una fracción de CPU. Las compilaciones serían lentas y muchos proyectos superarían el límite de memoria. Así que, en su lugar, una compilación inicia un contenedor a través del Cloudflare Sandbox SDK, copia el proyecto, ejecuta el trabajo, devuelve el resultado y apaga el contenedor. Las ejecuciones de notebooks funcionan igual. Todavía usamos Linux completo, pero solo para los segundos de trabajo que realmente lo necesitan.
La desventaja honesta es que tenemos que anticipar lo que el agente necesita. Con bash podía resolver las cosas por sí mismo. Ahora, si falta una capacidad, tenemos que añadirla. En la práctica, esa presión ha sido buena para el producto, porque nos obliga a pensar en lo que los usuarios están haciendo y construir un camino de primera clase para ello, en lugar de dejar que el agente improvise.
También hubo un beneficio inesperado. Bash es abierto, y los modelos baratos tienen dificultades en entornos abiertos. Con un conjunto más reducido de métodos explícitos, su rendimiento mejora notablemente, lo que importa porque mantener camelAI barato de ejecutar es el objetivo de esta arquitectura.
Dónde nos deja esto
La pila ahora es: Durable Objects para el agente y su sistema de archivos, R2 para archivos grandes, Artifacts para el historial git, pi como el harness, y Code Mode con Workers dinámicos para la ejecución. Se despliega como cualquier otra aplicación de Cloudflare, y no hay servicios externos de contenedores que gestionar.
Los Workers dinámicos se facturan por ejecución, no por segundo de actividad. Miles de ejecuciones cuestan aproximadamente lo que unos minutos de tiempo de contenedor en los servicios que solíamos evaluar. La latencia es baja porque todo se ejecuta en el borde cerca del usuario, y el escalado es problema de Cloudflare, no nuestro.
Los usuarios todavía compilan y despliegan aplicaciones full-stack a URLs en vivo, y el agente todavía lee, escribe, grepea y despliega. Desde el lado del usuario, nada ha cambiado.
Resumen
Empezamos con el harness de Claude Code en un servicio de VM propio, que era caro y difícil de escalar. Primero movimos el agente en sí mismo a un Cloudflare Durable Object y lo dejamos controlar VMs de forma remota, lo que solucionó la latencia pero no el coste. Luego reemplazamos las VMs por completo con un sistema de archivos almacenado en SQLite de Durable Object y R2, basado en el proyecto Shell de Cloudflare, con historial git a través de Cloudflare Artifacts. Finalmente eliminamos bash y le dimos al agente un sandbox de JavaScript mediante Code Mode y Workers dinámicos, con métodos explícitos para despliegues, compilaciones y notebooks. El resultado es órdenes de magnitud más barato, menor latencia, más simple de operar y más fácil de manejar para modelos más pequeños. Todo es código abierto en github.com/qaml-ai/camelAI.
