Recentemente concluímos a migração do agente camelAI para fora das máquinas virtuais. Agora, o agente é executado dentro de um Cloudflare Durable Object, seu sistema de arquivos reside em SQLite e R2, e ele escreve JavaScript em vez de bash. A maioria das equipes executa agentes de codificação em uma VM Linux completa ou em um contêiner em sandbox, e nós também fazíamos isso.
Queríamos sair das VMs porque dar a cada usuário uma máquina sempre ativa com disco anexado era caro demais para escalar. A parte difícil é que os agentes de codificação assumem Linux. Eles são treinados para usar bash, e a base que lançamos exigia uma VM completa, então levar três redesenhas para chegar até aqui. A compensação é que agora o agente só pode fazer aquilo para o qual construímos um método explícito, o que parece limitador, mas tem sido bom para o produto.
Sou Miguel, CTO da camelAI. Nosso código-fonte foi recentemente aberto ao público, então tudo neste post é código que você pode ler em github.com/qaml-ai/camelAI. Vou linkar para os arquivos relevantes ao longo do texto. Aqui está a progressão.
Passo zero: a era das VMs
Lançamos com a base do Claude Code, que precisa de uma máquina virtual completa para rodar. Testamos vários provedores de VM, nenhum atendia aos nossos requisitos de persistência e desempenho, e acabamos criando nosso próprio serviço de contêiner. Esse post ainda está no ar, mas não executamos mais nenhuma dessas infraestruturas.
O serviço de contêiner funcionava, mas era pesado. Uma VM sempre ativa para cada usuário é cara, e manter os arquivos de cada usuário em um disco rápido anexado também é. Escalar significa escalar máquinas reais com discos reais, o que seria proibitivamente caro para as quantidades de usuários que almejamos. Então, em vez de tentar soluções inteligentes de orquestração de VMs, começamos a projetar sem precisar de uma VM.
Passo um: tirar o agente da VM
A base do Claude Code é inseparável de sua VM, então o primeiro passo foi construir nossa própria base. Construímos sobre o pi, o agente de codificação de código aberto de Mario Zechner. pi é uma pilha de bibliotecas. A camada mais alta pressupõe um sistema operacional normal, mas as camadas inferiores fornecem os primitivos do agente, como o loop do agente e o gerenciamento de estado, sem se importar onde são executados. Não alteramos nenhum código do pi. Importamos essas camadas inferiores e construímos nossa própria base sobre elas, executando dentro de um Cloudflare Durable Object em vez de um ambiente Linux.
Um Durable Object é uma pequena instância de computação com estado que é iniciada na borda do Cloudflare, perto do usuário que a criou. Cada thread de chat recebe seu próprio Durable Object, o que por si só reduziu a latência em comparação com rotear tudo por meio de um host de VM centralizado.
Nessa fase, mantivemos as VMs, mas o agente não vivia mais dentro de uma. Ele chamava remotamente a VM quando precisava executar comandos. A Anthropic descreve essa mesma divisão para seus agentes gerenciados, o cérebro separado das mãos. Isso nos deu algumas propriedades interessantes:
- O agente começa a responder antes de a VM acordar, porque não espera uma máquina inicializar.
- A VM pode voltar a dormir enquanto o agente continua trabalhando, ou nunca acordar se a rodada não precisar de comandos.
- Um cérebro pode controlar várias mãos. Um único agente poderia operar várias VMs ao mesmo tempo.
Chamamos essas mãos de projetos. Cada projeto vinha com uma VM para executar comandos e um repositório git criado programaticamente por meio do Cloudflare Artifacts, que é um armazenamento compatível com git que você pode provisionar dinamicamente a partir de um Worker. O agente não sabia realmente que estava sendo executado fora da VM. Ele ainda tinha bash e funcionava como qualquer outro agente de codificação.
O problema é que isso corrigiu apenas a latência e nada mais. Ainda tínhamos uma VM por usuário, então ainda tínhamos todos os problemas de custo e escalabilidade do design original.
Passo dois: remover a VM
A próxima versão manteve a mesma estrutura de projetos, mas eliminou a VM por trás dela. Cada projeto agora é apoiado por um sistema de arquivos que vive dentro de um Durable Object, com R2 por trás para arquivos maiores.
Não inventamos isso. A equipe de agentes da Cloudflare construiu o Shell, um sistema de arquivos e runtime de execução experimental para Workers, e reutilizamos bastante o código deles. A mecânica é simples. O armazenamento de um Durable Object é um banco de dados SQLite com um limite de 10 GB, e cada linha tem um tamanho máximo. Arquivos pequenos vivem diretamente nas linhas SQLite. Arquivos com mais de aproximadamente 1,5 MB são gravados no R2, e a linha SQLite apenas contém um ponteiro. Para o agente, parece um sistema de arquivos normal, mas por baixo é um banco de dados e armazenamento de objetos, então a persistência são dados armazenados, não infraestrutura que precisamos manter ativa.
O histórico de versões ainda passa pelo Artifacts, então cada projeto mantém um histórico git sem que hospedemos um servidor git.
Passo três: remover o bash
Remover o bash pareceu drástico. Agentes de codificação são treinados para usar bash, e o bash é a razão pela qual todos os executam em VMs em primeiro lugar. Também era um problema além do custo. Um agente com bash e acesso à rede precisa de credenciais para fazer algo útil, e nossas tentativas de URLs de proxy autenticadas estavam ficando complicadas e difíceis de aplicar.
Então o removemos. Em vez de bash, o agente escreve JavaScript, executado por meio do Code Mode e dos carregadores dinâmicos de Worker da Cloudflare. Cada execução roda em um novo isolado V8 que inicializa em milissegundos e usa alguns megabytes de memória. O sandbox vem pré-carregado com as conexões de dados do usuário e com métodos para tudo que a plataforma pode fazer. As credenciais nunca entram no sandbox. O agente chama os métodos de uma conexão, e a autenticação acontece do nosso lado.
Quando você olha para o que os agentes realmente usam o bash, perder isso custa menos do que você esperaria. A maior parte são operações de arquivo, para as quais o agente possui ferramentas nativas. Damos a ele leitura, escrita e edição, além de nossas próprias implementações de grep e glob. Isso cobre os 80-20. O resto são comandos específicos para tarefas específicas, e esses se tornaram métodos explícitos:
- wrangler deploy através de um proxy tornou-se um método deploy_project que controlamos totalmente. Como sabemos exatamente quando uma implantação acontece, podemos interceptá-la e abrir uma prévia ao vivo automaticamente. Antes, tínhamos que farejar o tráfego de wrangler com proxy para adivinhar qual thread havia implantado algo.
- Construir o aplicativo do usuário e executar notebooks Python tornaram-se seus próprios métodos, ambos apoiados por contêineres de curta duração.
Mantivemos contêineres para essas duas tarefas porque elas realmente precisam de Linux. Os aplicativos dos usuários são construídos com Vite, Tailwind e React Router, e adicionar dependências significa executar bun install. Consideramos executar as builds dentro de um Worker, já que o que está sendo construído é em si um Worker, mas esse caminho não é bem suportado, e os Workers têm um limite de memória de 128 MB e uma fração de CPU. As builds seriam lentas e muitos projetos ultrapassariam o limite de memória. Então, em vez disso, uma build inicia um contêiner por meio do Cloudflare Sandbox SDK, copia o projeto para dentro, executa a tarefa, retorna o resultado e desliga o contêiner. Execuções de notebook funcionam da mesma forma. Ainda usamos Linux completo, mas apenas para os segundos de trabalho que realmente precisam.
A desvantagem honesta é que temos que antecipar o que o agente precisa. Com bash, ele poderia descobrir as coisas por conta própria. Agora, se uma capacidade está faltando, temos que adicioná-la. Na prática, essa pressão tem sido boa para o produto, porque nos força a pensar sobre o que os usuários estão fazendo e construir um caminho de primeira classe para isso, em vez de deixar o agente improvisar.
Houve também um benefício inesperado. Bash é aberto, e modelos baratos têm dificuldade em ambientes abertos. Com um conjunto menor de métodos explícitos, eles têm um desempenho visivelmente melhor, o que importa porque manter o camelAI barato para rodar é o objetivo dessa arquitetura.
Onde isso nos deixa
A pilha agora é Durable Objects para o agente e seu sistema de arquivos, R2 para arquivos grandes, Artifacts para histórico git, pi como base, e Code Mode com Workers dinâmicos para execução. Ele é implantado como qualquer outro aplicativo Cloudflare, e não há serviços de contêiner externos para gerenciar.
Workers dinâmicos são cobrados por execução, não por segundo de atividade. Milhares de execuções custam cerca do que alguns minutos de tempo de contêiner custam nos serviços que costumávamos avaliar. A latência é baixa porque tudo é executado na borda perto do usuário, e escalar é problema da Cloudflare, não nosso.
Os usuários ainda constroem e implantam aplicativos full-stack em URLs ativas, e o agente ainda lê, escreve, faz grep e implanta. Do lado do usuário, nada mudou.
Resumo
Começamos com a base do Claude Code em um serviço de VM construído internamente, que era caro e difícil de escalar. Primeiro, movemos o próprio agente para um Cloudflare Durable Object e permitimos que ele controlasse VMs remotamente, o que corrigiu a latência, mas não o custo. Em seguida, substituímos as VMs completamente por um sistema de arquivos armazenado em SQLite e R2 do Durable Object, baseado no projeto Shell da Cloudflare, com histórico git via Cloudflare Artifacts. Finalmente, removemos o bash e demos ao agente um sandbox JavaScript via Code Mode e Workers dinâmicos, com métodos explícitos para implantações, builds e notebooks. O resultado é ordens de magnitude mais barato, menor latência, mais simples de operar e mais fácil para modelos menores dirigirem. Tudo isso é código aberto em github.com/qaml-ai/camelAI.
