CubeSandbox vs E2B para Agentes em Produção

Meu nome é Dora. Recentemente, tínhamos um agente fazendo chamadas de ferramentas em produção. O orquestrador estava bem. O LLM estava bem. O gargalo era a camada de sandbox — toda vez que o agente precisava executar um trecho de código gerado, pagávamos 200ms de inicialização a frio, às vezes mais, às vezes a fila ficava caprichosa. Com ~40 chamadas de ferramentas por sessão, isso representa um pedaço significativo do tempo total.

Então comecei a olhar para as alternativas. A comparação que todo mundo parece estar fazendo agora é CubeSandbox vs E2B. Este artigo é o que encontrei após duas semanas lendo os dois projetos, implantando um deles e sendo incapaz de implantar o outro (vou chegar nisso).

Aviso rápido: não tenho nenhum relacionamento comercial com nenhum dos projetos. Ambos são de código aberto. A imagem abaixo é um trade-off entre hospedado e auto-hospedado, não uma questão de “bom vs mau”.

CubeSandbox vs E2B em Resumo

Ambos os projetos resolvem o mesmo problema de forma aproximadamente igual: iniciar uma microVM, executar código não confiável, encerrá-la. Ambos publicam números de desempenho na mesma faixa. A diferença real é a forma do produto.

O CubeSandbox é uma stack de sandbox-como-serviço de código aberto da Tencent Cloud, lançada em abril de 2026 sob a licença Apache 2.0. Construído sobre RustVMM e KVM. Números de destaque do repositório: inicialização a frio abaixo de 60ms, ~5MB de memória por sandbox, compatibilidade nativa com o SDK E2B (troque uma variável de ambiente de URL). É distribuído como a stack completa auto-hospedável, não apenas uma biblioteca.

O E2B também é de código aberto (também Apache 2.0), construído sobre microVMs Firecracker. Fundado em 2023. Inicialização de sandbox em torno de 150–200ms com pools de snapshots pré-aquecidos. Auto-hospedagem existe via scripts Terraform, mas a distribuição principal é a nuvem gerenciada — Hobby (gratuito, $100 em créditos), Pro ($150/mês + uso), Enterprise (BYOC, on-prem). Usuários auto-hospedados são uma minoria da base de usuários; hospedado é a história padrão.

Portanto, o eixo real não é “qual sandbox é melhor”. É:

Recurso	CubeSandbox	E2B
Licença	Apache 2.0	Apache 2.0
Modo principal	Auto-hospedado	SaaS hospedado (auto-hospedagem possível)
VMM subjacente	RustVMM + KVM	Firecracker (KVM)
Inicialização a frio publicada	`<60ms`	~150–200ms
Memória por sandbox	~5MB	~5MB
Compatibilidade com SDK	Drop-in do SDK E2B	SDK E2B nativo
Suporte a GPU	Requer Linux x86_64 com KVM habilitado; sem passthrough nativo no upstream	Mesmas restrições de GPU do Firecracker
Carga operacional	Você gerencia o cluster	E2B gerencia o cluster (gerenciado)

Os números acima foram extraídos do repositório e das notas de lançamento de cada projeto, não de um benchmark que eu executei. Trate-os como publicados pelo fornecedor — úteis como indicação, não como substituto para seus próprios testes.

Trade-offs entre hospedado e auto-hospedado

Esta é a decisão real, e é na maioria das vezes não técnica.

Ir hospedado com E2B significa que você para de pensar em kernels de microVM, pools de snapshots, hosts KVM e failover de orquestrador. Você também para de pensar em otimização de custos, porque os preços são definidos para você. A equipe em que estava tentou o E2B Pro por duas semanas — a integração genuinamente leva cerca de uma hora, o SDK é limpo e as horas de engenharia economizadas são reais.

Ir auto-hospedado com CubeSandbox significa que você possui a máquina. O custo se torna “quanto custa o servidor subjacente” em vez de “quanto custa nossa curva de uso”. A conformidade fica mais fácil porque nenhum dado cruza seu perímetro. Mas você também possui o plantão, as atualizações de kernel, o ajuste de políticas eBPF. O CubeSandbox vem com implantação com um clique para configurações de nó único e cluster, o que ajuda, mas “implantação com um clique” e “cluster pronto para produção” não são a mesma frase.

Pausei aqui por alguns dias, porque a resposta genuinamente depende da composição da equipe. Uma startup de quatro pessoas lançando agentes no próximo trimestre provavelmente não deveria estar gerenciando sua própria frota de microVMs. Uma equipe com engenheiros de infraestrutura e restrições de conformidade provavelmente deveria.

Questões de compatibilidade e migração

A história de compatibilidade E2B do CubeSandbox é a afirmação técnica mais interessante no lançamento do CubeSandbox. De acordo com sua documentação, um agente baseado em E2B existente pode trocar uma única variável de ambiente e rotear o tráfego para um cluster CubeSandbox auto-hospedado — sem alterações de código. Não migrei pessoalmente uma carga de trabalho E2B de produção, então estou aceitando a afirmação por fé por enquanto, mas é verificável lendo as chamadas SDK que cada lado aceita. A área de superfície é pequena. Ambos falam o mesmo ciclo de vida do Sandbox: criar, executar comando, executar código, encerrar.

É aqui que as coisas ficam úteis: significa que o CubeSandbox é essencialmente um backend de infraestrutura própria para o SDK E2B. Você pode desenvolver na nuvem hospedada do E2B e depois redirecionar para seu próprio cluster quando o uso justificar. O argumento de lock-in fica mais fraco para ambos os lados — o que acho saudável para a categoria.

Onde o CubeSandbox Vence

Controle, estrutura de custos e propriedade da infraestrutura

Para qualquer equipe de agentes executando volume suficiente para que os preços de sandbox gerenciado comecem a aparecer na conta mensal, o CubeSandbox é a opção mais honesta. Você está pagando por hardware que já entende. A filtragem de saída via eBPF (CubeVS) é configurável no nível do kernel. Se suas regras de residência de dados dizem “isso não pode sair do nosso VPC”, essa é uma conversa de 30 segundos com um sandbox auto-hospedado e uma conversa muito mais longa com um gerenciado.

O que não é dito com frequência suficiente: um runtime de agente auto-hospedado não é um almoço grátis. O custo marginal por execução cai, o custo fixo sobe. O ponto de equilíbrio é único para a curva de uso de cada equipe. Faça as contas antes de decidir. Se a resposta for “vamos economizar $300/mês e adicionar duas horas de trabalho operacional semanal”, isso não é uma vitória.

Afirmações de desempenho e densidade que as equipes devem testar

O CubeSandbox publica uma inicialização a frio abaixo de 60ms, que as notas de lançamento da Tencent Cloud via HPCwire descrevem como “um terço da média do setor (150ms)”. Eles também afirmam 2.000+ sandboxes em uma única máquina física. Esses números vêm de cargas de trabalho de produção dentro da Tencent Cloud, não de um benchmark sintético — o que é melhor que sintético, mas ainda é a carga de trabalho deles, não a sua.

O que eu testaria antes de acreditar nos números de destaque:

Inicialização a frio com seu tamanho real de snapshot (um template de 5GB se comporta de forma diferente de um de 200MB)
Comportamento de concorrência em p99, não apenas na média — o CubeSandbox publica uma resposta média de 67ms em 50 simultâneos, o que é encorajador, mas não é o mesmo que p99
Se suas dependências específicas sobrevivem ao kernel reduzido do RustVMM sem surpresas

É aqui que meus dados terminam. Implantei o CubeSandbox em uma VM única com KVM habilitado e o coloquei servindo sandboxes em cerca de meio período da tarde. Não o testei sob estresse nos números de densidade do lançamento. Qualquer pessoa que diga ter feito isso, após três semanas do projeto ser público, provavelmente está exagerando.

Onde o E2B Ainda Vence

A outra metade do cenário CubeSandbox vs E2B: se você não quer pensar em infraestrutura, o E2B vence. Essa frase parece desdenhosa, mas é a conclusão real.

Especificamente:

O SDK E2B hospedado é mais maduro. Mais exemplos de cookbook, mais integrações com LangChain/LlamaIndex, histórico mais longo.
Manus, análise de código da Perplexity, Open R1 da Hugging Face — referências de produção em escala existem. O CubeSandbox tem referências de produção dentro da Tencent Cloud, o que é real, mas os estudos de caso externos ainda estão sendo escritos.
A documentação do E2B cobre sandboxes de desktop, templates a partir de Dockerfiles, persistência de arquivos e durações de sessão de 24h prontas para uso. O CubeSandbox é mais espartano — o README e os exemplos cobrem o ciclo de vida principal, não a cauda longa.
O próprio Firecracker é uma quantidade conhecida. O AWS Lambda roda sobre ele. O projeto Firecracker está em produção desde 2018. A stack baseada em RustVMM do CubeSandbox é mais recente aos olhos do público, mesmo que tenha estado rodando dentro da Tencent por algum tempo.

Se você está lançando um produto de agente v1 no próximo trimestre e não tem uma pessoa de infraestrutura, o plano hospedado do E2B é o caminho de menor atrito. As horas não gastas lutando com seu cluster de sandbox são horas gastas no próprio agente. Isso vale $150/mês para muitas equipes.

Um Framework de Decisão para Equipes de Agentes

Após duas semanas analisando isso, aqui está o framework que eu realmente usaria. Este é um dos atalhos de comparação de sandbox de agente de IA mais úteis que encontrei:

Volume abaixo de ~50k horas de sandbox/mês, sem restrições de conformidade, sem equipe de infraestrutura → E2B hospedado. Pare de ler.
Volume acima disso, ou residência de dados estrita, ou você já executa Kubernetes/microVMs → CubeSandbox auto-hospedado. A economia muda e você tem a capacidade para operá-lo.
Em algum lugar no meio → Comece no E2B hospedado. Construa com o SDK. Quando a conta começar a doer ou a conformidade fizer perguntas, a compatibilidade do SDK significa que a migração é uma mudança de URL. Essa opcionalidade é a propriedade mais subestimada de toda essa comparação.
Você precisa de passthrough de GPU para inferência de agente dentro do sandbox → Nenhum dos dois é ótimo. O Firecracker upstream não suporta passthrough de GPU nativamente, e o CubeSandbox herda uma restrição similar. Veja gVisor ou Daytona para essa carga de trabalho.

O enquadramento que eu resistiria: “CubeSandbox é a melhor tecnologia, portanto vence”. Uma escolha de sandbox de microvm é uma escolha de forma de produto. A tecnologia é aproximadamente equivalente em especificações publicadas. O custo do dia a dia é operacional.

FAQ

Estas são as perguntas que continuei recebendo dos colegas de equipe durante a avaliação do CubeSandbox vs E2B.

O CubeSandbox é um substituto drop-in para o E2B?

Para a superfície do SDK E2B, sim — por design. O projeto se comercializa como um runtime compatível com E2B onde você troca uma variável de ambiente. Para recursos além do ciclo de vida principal do sandbox (templates a partir de Dockerfiles, sandboxes de desktop, observabilidade hospedada), a resposta é “ainda não”.

O que a auto-hospedagem realmente adiciona à carga de trabalho?

Um host com KVM habilitado (ou frota), gerenciamento de kernel/imagem, monitoramento, ajuste de pool de snapshots, política de saída de rede e plantão. O lançamento da Tencent Cloud descreve “implantação com um clique” para configurações de nó único e cluster, mas tratar isso como idêntico a um cluster de nível de produção é otimista. Planeje de 1 a 2 semanas de configuração e uma parcela recorrente pequena da atenção de alguém.

Quais cargas de trabalho se beneficiam mais dos sandboxes de microVM?

Qualquer coisa em que você esteja executando código gerado por modelo contra entradas não confiáveis em escala. O risco de kernel compartilhado do Docker simples é o argumento padrão contra contêineres para isso — toda grande plataforma de agentes migrou do isolamento de kernel compartilhado por essa razão. Se seu agente executa apenas código em sandbox a partir de uma lista de permissões fixa de scripts confiáveis, talvez você não precise de uma microVM.

O que as equipes devem fazer benchmark primeiro?

Três coisas, nesta ordem: inicialização a frio p99 no seu tamanho real de template; densidade de sandbox por dólar de hardware (para auto-hospedado) ou por dólar de fatura (para hospedado); modo de falha sob carga de pico. Os números de destaque — abaixo de 60ms vs ~150ms — são reais, mas descrevem médias sob condições favoráveis ao fornecedor. Sua carga de trabalho não corresponderá a nenhum dos fornecedores, que é o único motivo para fazer benchmark.

Conclusão

O debate CubeSandbox vs E2B é real, mas ligeiramente mal enquadrado. Não é “qual sandbox é tecnicamente superior”. Ambos usam isolamento no nível de hardware, ambos publicam números de desempenho credíveis, ambos são Apache 2.0, ambos falam o mesmo SDK. A decisão é: você quer que outra pessoa gerencie a infraestrutura, ou você quer gerenciá-la você mesmo.

Essa é uma pergunta de produto, não de engenharia. E a resposta honesta para a maioria das equipes é “comece hospedado, mantenha a migração barata”. A compatibilidade de SDK entre os dois projetos é a coisa mais útil sobre todo este lançamento — significa que o imposto de lock-in acabou de ficar menor para todos na infraestrutura de agentes.

Mais por vir assim que eu tiver executado o CubeSandbox sob carga real. Ambos os projetos são atualizados rapidamente — esta comparação não envelhecerá tão bem quanto a tecnologia subjacente.

Posts Anteriores: