O que é OpenSandbox?
O OpenSandbox é um servidor e um conjunto de SDKs para criar ambientes isolados onde um agente de IA pode executar comandos, editar arquivos, rodar código gerado ou controlar um navegador ou um desktop. Você o inicia localmente no Docker e passa para o Kubernetes pela mesma API de ciclo de vida, com SDKs para Python, TypeScript, Java/Kotlin, C#/.NET e Go, uma CLI chamada osb e um servidor MCP para clientes como Claude Code e Cursor.
Ele nasceu na Alibaba (os pacotes ainda levam os nomes com.alibaba e @alibaba-group) e agora é um projeto da Agentic AI Foundation, na organização opensandbox-group. A versão 1.1.1 saiu em 9 de outubro de 2026 e a 1.2.0 está na segunda release candidate.
O isolamento é configurável, não fixo: contêineres comuns por padrão, com gVisor, Kata Containers ou Firecracker como runtimes seguros, políticas de saída por sandbox e um Credential Vault que injeta segredos nas requisições de saída para que a carga de trabalho nunca os veja.
OpenSandbox vale a pena?
O OpenSandbox resolve um problema diferente do srt da Anthropic ou do OpenShell da NVIDIA. Esses confinam um agente rodando na sua máquina; o OpenSandbox entrega, por meio de uma API, máquinas novas e descartáveis a agentes rodando em qualquer lugar. É a contrapartida auto-hospedada dos sandboxes de código hospedados que muitos produtos de agentes alugam por segundo, e reuniu cerca de 16,200 estrelas no GitHub em dez meses.
Os números principais são dos próprios mantenedores, que publicam o método junto. Em um cluster Kubernetes da Alibaba Cloud com dois nós de 192 CPUs cada, sandboxes Firecracker aquecidos a partir de um snapshot pré-construído ficaram prontos em 64 ms na mediana em uma execução serial e em 125.4 ms no p99 com dez criações simultâneas. Com 20 criações simultâneas contra um pool de 20 vagas, só 51 de 100 tentativas deram certo, o que o relatório diz com clareza. São números do caminho aquecido, com artefatos em cache; o primeiro uso custa mais.
O modelo de segurança recompensa o cuidado e pune os padrões. Sem um runtime seguro, um sandbox é um contêiner comum, então um exploit de kernel em código gerado chega ao host; gVisor, Kata ou Firecracker fecham essa brecha, mas cada um exige sua própria configuração de nós. Se server.api_key estiver vazio, o servidor roda sem nenhuma autenticação, e no Docker ou no Kubernetes é preciso definir OPENSANDBOX_INSECURE_SERVER=YES para permitir isso, o que pelo menos torna a escolha deliberada. As imagens de release são assinadas com Cosign, e a documentação pede que você as fixe por digest.
O projeto anda rápido: 153 issues e pull requests abertos, uma release candidate da 1.2 duas semanas depois da 1.1.1 e uma especificação de protocolo pensada para que outros construam runtimes sobre ela. Para uma equipe que já roda Kubernetes e paga contas por segundo de sandbox para avaliações de agentes ou rollouts de aprendizado por reforço, esse ritmo é uma vantagem; para um único agente de programação em um notebook, é muito mais maquinaria do que o trabalho exige.
Onde ele se destaca
Uma equipe de ML que roda avaliações noturnas de agentes com Harbor
Dar a cada um de vários milhares de testes seu próprio ambiente limpo
Usar pools de recursos e criação em lote no Kubernetes para que cada teste receba um sandbox novo, destruído ao final. O custo são os nós do seu cluster, não tarifas por segundo a um fornecedor de sandboxes hospedados.
Uma empresa SaaS que adiciona um interpretador de código ao seu agente voltado ao cliente
Rodar Python escrito pelo modelo para muitos inquilinos sem que um escape para o outro
Rodar os sandboxes sob Firecracker ou gVisor, definir políticas de saída por sandbox e injetar chaves de API pelo Credential Vault. Defina server.api_key antes de expor o servidor; por padrão ele fica aberto.
Um desenvolvedor testando Claude Code ou Codex CLI de forma isolada
Deixar um agente de programação trabalhar em um repositório dentro de um contêiner descartável
Iniciar o servidor com uvx opensandbox-server no Docker e seguir o exemplo do Claude Code; minutos até o primeiro sandbox, embora o srt faça esse trabalho em um notebook com muito menos configuração.
Antes de decidir
- Configuração
- Exige Docker e Python 3.10+: uvx opensandbox-server init-config ~/.sandbox.toml --example docker, depois uvx opensandbox-server e pip install opensandbox. O Kubernetes usa um operador; o Firecracker precisa de nós com virtualização.
- Integrações
- SDKs para Python, TypeScript, Java/Kotlin, C#/.NET e Go, a CLI osb, um servidor MCP (pip install opensandbox-mcp) com ferramentas de sandbox, comandos e arquivos, e exemplos para Claude Code, Codex CLI, Playwright, Chrome, desktops e Harbor.
- Dados e privacidade
- Roda na sua própria infraestrutura sob Apache 2.0; a exportação de métricas para OpenTelemetry é opcional; imagens assinadas com Cosign e com proveniência; nenhum aviso de segurança publicado no GitHub.
- Custo em escala
- O software é gratuito; o custo são os seus nós. O benchmark dos mantenedores usou dois nós Kubernetes com 192 CPUs e cerca de 742 GiB de memória cada para rodar um pool Firecracker de 20 vagas.
- Limites
- Runtimes seguros, entrada e saída exigem configuração separada; as credenciais de endpoint do secureAccess só funcionam com o gateway de ingress do Kubernetes; o sucesso caiu para 51 de 100 criações quando a concorrência igualou o tamanho do pool.
O que é bom
- A mesma API do Docker local a um cluster Kubernetes
- Isolamento com Firecracker, gVisor ou Kata, além de pausa e retomada
- O Credential Vault mantém os segredos reais fora do sandbox
- SDKs em cinco linguagens, uma CLI e um servidor MCP
O que não é
- Contêineres comuns, a menos que você configure um runtime seguro
- O servidor roda sem autenticação se nenhuma chave de API for definida
- Os números de velocidade no caminho rápido são dos próprios mantenedores, em nós grandes
- Configurar Kubernetes e Firecracker é trabalho de operações de verdade
Ideal para
Equipes de plataforma que rodam avaliações de agentes, rollouts de RL ou execução de código multi-inquilino e querem sandboxes na própria infraestrutura.
Alternativas ao OpenSandbox
OpenSandbox: perguntas frequentes
- OpenSandbox vale a pena?
- Uma resposta auto-hospedada aos sandboxes de código hospedados, que compensa o trabalho com Kubernetes quando você precisa de milhares de ambientes de agente de curta duração nas suas próprias máquinas. Damos nota 4.1 de 5.
- Quanto custa OpenSandbox?
- Gratuito e de código aberto sob Apache 2.0; os mantenedores não oferecem edição paga.
- Quais são as desvantagens de OpenSandbox?
- Contêineres comuns, a menos que você configure um runtime seguro; o servidor roda sem autenticação se nenhuma chave de API for definida; os números de velocidade no caminho rápido são dos próprios mantenedores, em nós grandes; configurar Kubernetes e Firecracker é trabalho de operações de verdade.
- Para quem OpenSandbox é indicado?
- Equipes de plataforma que rodam avaliações de agentes, rollouts de RL ou execução de código multi-inquilino e querem sandboxes na própria infraestrutura.
- Quanto custa OpenSandbox para uma equipe ou em produção?
- O software é gratuito; o custo são os seus nós. O benchmark dos mantenedores usou dois nós Kubernetes com 192 CPUs e cerca de 742 GiB de memória cada para rodar um pool Firecracker de 20 vagas.
- OpenSandbox é seguro para dados da empresa?
- Roda na sua própria infraestrutura sob Apache 2.0; a exportação de métricas para OpenTelemetry é opcional; imagens assinadas com Cosign e com proveniência; nenhum aviso de segurança publicado no GitHub.
- Quais são as melhores alternativas ao OpenSandbox?
- As alternativas mais próximas que analisamos são NVIDIA OpenShell e Anthropic Sandbox Runtime (srt).
Respostas verificadas em 26 de out. de 2026.