Cloud Computers for AI Agents: exe.dev vs Sprites vs Shellbox vs E2B vs Blaxel
AI agents need somewhere to run, and neither your laptop nor a traditional VPS is a good answer. Running agents locally puts your credentials and host system at risk, and a VPS is designed for long-running web services, not for agent sessions that are quickly spun-up and torn down.
A new category of tools has been built specifically for this. Some give you a remote machine the agent lives and works inside. Others give your agent a sandboxed environment it can call via API to execute code without touching the host.
We looked at five tools across both categories to find out how they compare on specs, startup time, security, pricing, and which use cases each is actually suited for:
- exe.dev — a subscription-based remote VM service with a built-in LLM gateway, credential injection, and a pre-installed web agent
- Sprites — a Fly.io remote VM product with usage-based pricing, autoscaling RAM, and a checkpoint system for rolling back agent operations
- Shellbox — a minimal SSH-only remote VM that pauses when you disconnect and bills at a low idle rate
- E2B — an open-source agent execution sandbox with sub-200ms cold starts and broad agent framework support
- Blaxel — an agent execution sandbox where environments suspend rather than stop, resuming in 25ms, with additional products for agent hosting and LLM routing
In this guide we cover:
- Why a traditional VPS or Docker container does not work well for agent workflows
- What remote agent machines and agent execution sandboxes are and when to use each
- How all five tools compare across specs, startup time, access methods, pre-installed software, networking, persistence, security, scale, and pricing
- Which tool to use for your specific use case
What is a cloud computer for AI agents?
A cloud computer for AI agents means one of two things, depending on what you are building.
A remote agent machine: a virtual machine the agent runs inside
The agent lives in the machine and uses it as its working environment.
- Running Claude Code remotely so it does not touch your laptop
- Letting an agent clone a repo, install dependencies, run tests, and open a pull request
- Giving an agent a persistent workspace it can return to across sessions
- Running multiple agent sessions in parallel, each in its own isolated machine
An agent execution sandbox: a virtual machine the agent calls from the outside
The agent itself runs somewhere else, but it spins up a sandbox via an API call whenever it needs to execute code safely.
- An agent that generates Python code and needs to run it without exposing the host server
- A coding assistant that executes user-submitted snippets in an isolated environment
- An autonomous pipeline that spins up a fresh sandbox for each task, then destroys it
- A multi-agent system where each sub-agent gets its own isolated execution environment
Can I just use a VPS or Docker container to run my AI agent?
In the past, developers reached for a VPS or a Docker container whenever they needed remote compute. Provision a machine on DigitalOcean or Hetzner, SSH in, install your tools, and run your process. This model worked well for web servers and long-running background services.
Agent workflows are a different kind of workload, and a traditional VPS runs into problems at each point.
Agents run a task and then they are done
A developer might ask Claude Code to read a codebase, implement a feature, write tests, and open a pull request. That task runs autonomously and then it is done. Other common workflows look similar:
- An agent that triages a backlog of GitHub issues overnight
- A coding assistant that spins up to answer a question and then stops
A traditional VPS bills 24 hours a day regardless. Every idle hour between sessions is compute you are paying for and not using.
Each agent session needs a fresh machine
Each of those workflows is best run in a fresh environment. You spin up a machine, the agent does its work, and when it is done you delete the machine. The next task gets another fresh machine.
A traditional VPS takes 45 to 60 seconds to provision before any setup. If every session needs its own machine, that overhead adds up across every run.
VPSes are also not designed to be thrown away, which means previous session state can accumulate.
Agents need hardware-level isolation
Agents run code autonomously and respond to external inputs like emails or API responses. Those inputs can be crafted to manipulate what the agent does next, including running commands on the host machine.
Running an agent on your laptop or a shared server means your credentials and environment files are within reach of whatever the agent does.
Docker reduces the surface but containers share the host kernel, and container escapes are a documented attack class with real CVEs.
Which companies are building cloud infrastructure for AI agents?
The tools covered in this article split across two distinct use cases.
Remote agent machines
A traditional VPS requires manual setup, bills whether it is in use or not, and gives agents no built-in way to handle credentials, context files, or session isolation.
The tools in this category address that by building machines that start in seconds, include AI tooling pre-installed, stop billing when idle, and are designed from the start to be handed off to an agent.
- exe.dev — a subscription-based VM service with a built-in LLM gateway, credential injection, and a pre-installed web-based agent called Shelley
- Sprites — a Fly.io product with usage-based pricing, autoscaling RAM, and a checkpoint system for rolling back agent operations
- Shellbox — a minimal SSH-only machine that pauses when you disconnect and bills at a low idle rate, built for solo developers and low-cost unattended sessions
Agent execution sandboxes
Running LLM-generated code on a host server or inside a Docker container exposes the host to whatever the model produces.
The tools in this category address that by providing isolated microVM environments that agents call via SDK. The agent runs elsewhere, spins up a sandbox to execute code, and gets the result back without anything running on the host.
- E2B — an open-source sandbox platform with sub-200ms cold starts, wide agent framework support, and self-hosting options for enterprise teams
- Blaxel — a sandbox platform where environments go to standby rather than being destroyed, resuming in 25ms, with additional products for agent hosting, MCP servers, and LLM routing
How much CPU and RAM do you actually get?
The hardware model varies across all five tools.
- exe.dev sells a shared pool across all your VMs
- Sprites autoscales per session
- Shellbox gives each VM dedicated resources
- E2B and Blaxel let you configure size at creation time
Remote agent machines
| Tool | Base CPU | Base RAM | Disk | Resource model | Max RAM |
|---|---|---|---|---|---|
| exe.dev | 2 vCPU | 8 GB | 25 GB | Shared pool across all VMs | 64 GB (16 vCPU plan) |
| Sprites | up to 8 vCPU | 2 GB | 100 GB | Dynamic, autoscales to cap | 16 GB |
| Shellbox | 2 vCPU | 4 GB | 50 GB | Dedicated per VM | 32 GB (x8) |
exe.dev
exe.dev sells you a pool, not a machine. On the base plan, you get 2 vCPUs and 8 GB of RAM shared across every VM in your account simultaneously. Spin up ten VMs and they all draw from the same pool. If you are running several heavy sessions at once, they compete for the same resources.
Sprites
Sprites starts each environment at 2 GB of RAM and scales up automatically as demand grows, up to 16 GB. You pay for what the process actually uses.
Shellbox
Shellbox gives each VM its own dedicated allocation. An x1 box always has 2 vCPUs and 4 GB to itself. You pick a size at creation time and that is what you get.
Agent execution sandboxes
| Tool | Default sandbox | Max vCPU | Max RAM | Disk | GPU support |
|---|---|---|---|---|---|
| E2B | 2 vCPU, 1 GB RAM | 8 | 8 GB | 10 GB (Hobby) / 20 GB (Pro) | No |
| Blaxel | XS to XL at creation | proportional to RAM | 32 GB (XL) | RAM-dependent | No |
E2B sandboxes default to 2 vCPUs and 1 GB of RAM. You can configure up to 8 vCPUs and 8 GB on paid plans.
Blaxel lets you choose a size when you create the sandbox. CPU is allocated proportionally to the memory tier you select and is not billed separately. The XL tier at 32 GB RAM is the largest available across any of the five tools.
How fast do these machines start up?
A traditional VPS takes 45 to 60 seconds just to provision, before any setup. All five tools here are measured in seconds or milliseconds.
Remote agent machines
| Tool | New machine | Wake from idle | How |
|---|---|---|---|
| exe.dev | ~2 seconds | Never sleeps | Container-image VMs on bare metal |
| Sprites | ~1-2 seconds | 100-500ms | Pre-warmed pool of empty VMs |
| Shellbox | Sub-second | Sub-second | Memory-mapped snapshot on NVMe |
exe.dev
exe.dev creates a new VM in about 2 seconds. It uses container images rather than traditional disk images, which removes the unpacking step. VMs never sleep, so there is no wake time.
Sprites
Sprites keeps a pool of empty pre-warmed VMs running on every physical worker. Creating a new Sprite is just starting one of those waiting VMs rather than provisioning from scratch. Waking a recently idle Sprite takes 100 to 500ms.
Shellbox
Shellbox takes a memory snapshot when you disconnect and maps it directly to NVMe. Resuming reads that snapshot back in under a second. You get the full state of the machine exactly as you left it.
Agent execution sandboxes
| Tool | Cold start | Resume from standby | Idle behaviour |
|---|---|---|---|
| E2B | Under 200ms (80ms same-region) | ~1 second | Keeps running until timeout or explicit kill |
| Blaxel | ~0.5-1 second | ~25ms | Auto-suspends after ~15 seconds of inactivity |
E2B cold starts at under 200ms using Firecracker microVMs. Once running, a sandbox keeps going until it times out or you kill it explicitly.
Blaxel takes slightly longer on a cold start but suspends automatically after about 15 seconds of inactivity, preserving full memory and filesystem state. Resuming a suspended sandbox takes around 25ms, which means a sandbox can sit paused for weeks and come back mid-session.
How do you connect to these environments?
Remote agent machines are accessed the way you would access any remote machine: SSH, a web shell, or an IDE integration. Agent execution sandboxes are accessed from code via an SDK.
Remote agent machines
| Tool | SSH | Web shell | Built-in agent | VSCode/IDE | SDK/API | MCP server | Mobile |
|---|---|---|---|---|---|---|---|
| exe.dev | Yes (primary) | Yes (Shelley) | Yes (Shelley) | VSCode Remote SSH | HTTPS API | No | Yes |
| Sprites | No (manual install + proxy) | No | No | No | JS/Go/Python/Elixir SDKs + REST | Yes | No |
| Shellbox | Yes (only interface) | No | No | VSCode Remote SSH, Zed | No | No | No |
Sprites and SSH
Sprites does not expose SSH directly. If you need an SSH connection, you install an SSH server inside the Sprite yourself and tunnel it through sprite proxy. For developers who rely on SSH as their primary workflow, this is a meaningful gap compared to exe.dev and Shellbox.
exe.dev integrations
exe.dev has two integrations worth knowing about beyond basic SSH access.
The GitHub integration lets you connect your GitHub account and clone private repos or use the gh CLI without storing tokens on the VM. The VM never holds your credentials.
The HTTP proxy integration injects secrets such as bearer tokens and API keys into outbound HTTP requests from inside the VM, without exposing those secrets to the VM itself. You configure the proxy once and it handles injection transparently on every request.
Agent execution sandboxes
Agent execution sandboxes are not accessed interactively. You call them from your agent code via an SDK. The sandbox sits between the LLM and your host system: the model generates code, the sandbox executes it, and the result comes back. Your host never runs the generated code directly.
| Tool | Primary interface | CLI | REST API | Web dashboard | Interactive SSH | MCP server |
|---|---|---|---|---|---|---|
| E2B | Python + JS/TS SDKs | e2b CLI | Yes | Yes | No | Yes |
| Blaxel | TS/Python/Go SDKs | bl CLI | Yes | Yes (app.blaxel.ai) | Yes (bl connect) | Yes |
E2B Desktop Sandbox
E2B has a separate product for agents that need to interact with a graphical interface rather than just run code. The Desktop Sandbox runs Ubuntu 22.04 with an XFCE desktop streamed over VNC. Agents can click buttons, fill forms, and navigate a browser. The SDK is @e2b/desktop.
E2B distributed sandbox access
Any running E2B sandbox can be reconnected to by ID from any environment using Sandbox.connect(sandboxId). The sandbox persists independently of whatever created it, so multiple serverless functions or machines can connect to the same sandbox at different points in a pipeline.
What software comes pre-installed?
The three remote agent machines ship with different amounts of pre-installed tooling. The two agent execution sandboxes focus on framework integrations rather than pre-installed CLIs.
Remote agent machines
| Tool | OS | Claude Code | Other AI CLIs | Docker | Custom images | LLM gateway | Agent context files |
|---|---|---|---|---|---|---|---|
| exe.dev | Ubuntu (exeuntu) | Yes | Codex | Yes | Yes (any container image) | Yes | CLAUDE.md, AGENTS.md, DEAR_LLM.md |
| Sprites | Ubuntu 25.10 | Yes | Gemini CLI, Codex, Cursor | No | No (universal image only) | No | /.sprite/llm.txt, agent-context.md |
| Shellbox | Ubuntu 24.04 LTS | No | No | Yes | Yes (any public OCI image) | No | No |
exe.dev
exe.dev's default image comes with Claude Code, Codex, and Docker pre-installed. It also includes an LLM gateway that lets agents call Anthropic, OpenAI, and Fireworks APIs using exe.dev plan credits. The agent never sees an API key. Agent context files at the standard paths are read automatically.
Sprites
Sprites comes with the most AI CLIs pre-installed: Claude Code, Gemini CLI, OpenAI Codex, and Cursor. It does not support custom images — every Sprite runs from the same universal image. There is no LLM gateway, but Sprites pre-creates context files at known paths so agents understand their environment.
Shellbox
Shellbox does not pre-install Claude Code. It ships Ubuntu 24.04 LTS with Docker and little else. You can bring any public OCI image as your base. There is no LLM gateway and no agent context files. A 4-hour x1 session costs $0.08.
Agent execution sandboxes
| Tool | OS | Pre-built templates | Custom images | Docker-in-Docker | Agent framework integrations |
|---|---|---|---|---|---|
| E2B | Ubuntu | Custom templates + Desktop Sandbox | Yes | Via Desktop Sandbox | LangChain, LangGraph, LlamaIndex, AutoGen, CrewAI, Vercel AI SDK, OpenAI Agents SDK |
| Blaxel | Linux microVM | nextjs, py-app, Docker-in-Docker | Yes | Yes (Feb 2026) | LangChain, LangGraph, CrewAI, Google ADK, LlamaIndex, Mastra, n8n, OpenAI Agents SDK, Claude Agent SDK, PydanticAI, Vercel AI SDK |
Both tools support custom images and have broad agent framework integrations. Blaxel has a slightly wider list of supported frameworks including the Claude Agent SDK and Google ADK. E2B's Docker-in-Docker support requires using the Desktop Sandbox template; Blaxel added a dedicated Docker-in-Docker template in February 2026.
Do these machines get a public URL automatically?
With a traditional VPS you need a domain, DNS records, a reverse proxy, and TLS certificates before your agent's web server is reachable. All five tools handle this automatically.
Remote agent machines
| Tool | Automatic HTTPS URL | Public ports | Custom domains | Inbound email | Port forwarding |
|---|---|---|---|---|---|
| exe.dev | vmname.exe.xyz | Ports 3000-9999, one fully public | Yes (CNAME + auto TLS) | anything@vmname.exe.xyz | Yes |
| Sprites | name.sprites.app | Port 8080 only | No | No | Via sprite proxy |
| Shellbox | boxname-id.shellbox.dev | Port 80 only, public by default | No | boxname-id@in.shellbox.dev | Yes (-L/-R/-D flags) |
exe.dev
exe.dev forwards ports 3000 to 9999 automatically, each accessible at vmname.exe.xyz:PORT. One port can be made fully public without requiring visitors to log into exe.dev. Custom domains are supported via a CNAME record with TLS issued automatically. The VM also receives inbound email at any address at its domain.
Sprites
Sprites routes incoming requests to port 8080 inside the Sprite. That is the only publicly routable port. Sprites added an API gateway in March 2026 that connects to external OAuth services like Slack and GitHub, with tokens encrypted at rest. Agents can call those external APIs through the gateway without credentials stored on the Sprite.
Shellbox
Shellbox exposes port 80 and makes it public by default — no login required for visitors. Inbound email is supported, delivered as an HTTP POST to the box's endpoint. SSH port forwarding with -L, -R, and -D flags gives access to any other port locally.
Agent execution sandboxes
| Tool | Public URLs | Access control | Custom domains | Dedicated egress IPs | Outbound internet | VPC |
|---|---|---|---|---|---|---|
| E2B | https://PORT-id.e2b.app (any port) | Public by default, lockable with token | No | No | Yes (can disable) | No |
| Blaxel | Preview URLs | Configurable | Yes | Private preview | Yes | Enterprise |
When executing untrusted or LLM-generated code, outbound internet access is a real concern. E2B lets you disable outbound entirely or restrict it to IP and CIDR allowlists. Blaxel is adding MITM proxy and domain filtering controls, currently in private preview. Neither of these controls exist in Docker without significant manual configuration.
What happens to your machine when you disconnect?
This is where the remote agent machines diverge most. The agent execution sandboxes have a separate persistence story around session length limits.
Remote agent machines
| Tool | VM keeps running | Processes survive | Filesystem survives | RAM state survives | Cost while idle |
|---|---|---|---|---|---|
| exe.dev | Yes | Yes | Yes | Yes | Full plan rate |
| Sprites | No (sleeps) | No (registered Services restart) | Yes | No | Storage only |
| Shellbox | No (pauses by default) | No (frozen) | Yes | Yes (snapshot) | Idle rate |
exe.dev
exe.dev VMs never stop unless you explicitly delete them. Close your SSH session and everything keeps running: background jobs, servers, databases. The tradeoff is that you pay the full plan rate whether the machine is active or not.
Sprites
Sprites sleeps when idle. Compute charges stop and only storage is billed. Running processes stop on sleep, so you need to register any process you want to restart on wake as a Service. Only registered Services restart automatically.
Sprites also has a checkpoint feature that captures the full filesystem state in around 300ms using copy-on-write. Restoring takes under a second. The pattern for risky agent operations is: checkpoint before the agent runs, let it run, roll back if needed.
Shellbox
Shellbox pauses on SSH disconnect by default. A full memory snapshot is written to NVMe and billing drops to the idle rate. Reconnecting resumes exactly where you left off, same shell, same processes, same state.
For tasks that need to keep running after disconnect, Shellbox has three modes:
- Keepalive — VM stays running after disconnect, billed at the running rate
- Wakeup — starts on an incoming HTTP request, stops after a configurable idle timeout
- Cron — wakes on a schedule, runs a webhook, then stops
Agent execution sandboxes
| Tool | Max runtime (free) | Max runtime (paid) | Workaround | Paused sandbox TTL | Long-term storage |
|---|---|---|---|---|---|
| E2B | 1 hour | 24 hours | Pause and resume to reset the window | No TTL | No separate volume product |
| Blaxel | No limit | No limit | No workaround needed | No TTL | Volumes (persist after sandbox deletion) |
E2B
E2B has session length limits: 1 hour on Hobby and 24 hours on Pro. For longer tasks, you pause the sandbox and resume it, which resets the window. Pausing takes around 4 seconds per GB of RAM and preserves full memory and filesystem state. Resuming takes about 1 second. Cycling pause and resume gives you indefinite session length on any plan.
Blaxel
Blaxel has no session length limit. The standby model means there is no continuous session to manage. The sandbox suspends automatically and resumes on demand. For data that needs to outlive individual sandbox sessions entirely, Blaxel offers Volumes: persistent block storage that survives even if the sandbox is deleted.
Is it safe to run AI agents in these environments?
All five tools use hardware-level VM isolation rather than containers. This is a deliberate choice for agentic workloads.
The problem with containers
Docker containers share the host kernel. Every container on a machine runs on the same Linux kernel, which means a container escape can reach the host. Container escapes are a documented attack class with real CVEs, not a theoretical concern. When an agent is executing LLM-generated code, you cannot trust that code. If it finds a kernel vulnerability, Docker does not stop it reaching your host system.
Why microVMs are different
Firecracker microVMs give each environment its own kernel inside a hardware virtualization boundary. There is no shared kernel surface. Sprites, E2B, and Blaxel all use Firecracker. E2B's documentation explicitly states that containers are "not considered secure enough" for LLM-generated code. exe.dev uses Cloud Hypervisor on bare metal hardware it owns. Shellbox uses Firecracker by default, with Cloud Hypervisor available as an option.
Prompt injection is a real attack vector
Security researcher Simon Willison describes a "lethal trifecta" for agent attacks: an agent with access to private data, exposure to untrusted content, and an external communication channel. All three together make an agent exploitable.
In July 2025, the Pynt security team demonstrated this against Claude Desktop. They sent a crafted email that was ingested via a Gmail MCP server, which then triggered a shell command on the host. No user interaction was required. No individual tool had a vulnerability. Three legitimate tools composed into an attack. Willison cited similar prompt injection exploits reported against Microsoft 365 Copilot, GitHub's official MCP server, and GitLab Duo Chatbot in production in June 2025.
Running inside a microVM-backed environment contains the blast radius of these attacks. It does not eliminate the attack surface entirely.
Security posture by tool
| Tool | Isolation | Separate kernel | --dangerously-skip-permissions safe | API key handling |
|---|---|---|---|---|
| exe.dev | Cloud Hypervisor (bare metal) | Yes | Yes | LLM gateway: keys never on VM |
| Sprites | Firecracker (Fly.io) | Yes | Yes (pre-configured) | Keys must be stored on Sprite |
| Shellbox | Firecracker or Cloud Hypervisor | Yes | Yes | Keys must be stored on box |
| E2B | Firecracker | Yes | Yes | Keys passed via SDK, never in sandbox |
| Blaxel | MicroVMs (kernel-level) | Yes | Yes | Keys passed via SDK, never in sandbox |
How many machines can you run at once?
Remote agent machines
exe.dev allows up to 50 VMs per account. Sprites and Shellbox have account-level limits in the same range. None of the three expose a sandbox creation rate or concurrency limit suited to running thousands of parallel agent tasks.
Agent execution sandboxes
| Tool | Max concurrent (free) | Max concurrent (paid) | Creation rate | Notable customers |
|---|---|---|---|---|
| E2B | 20 | 100-1,100 (Pro), custom Enterprise | 1/sec (Hobby), 5/sec (Pro) | Perplexity, Hugging Face, Manus, Groq, Lindy |
| Blaxel | 10 | Up to 100,000+ (top tier) | Tier-dependent | - |
E2B's concurrency limits scale from 20 on the free tier up to 1,100 on Pro, with custom limits on Enterprise. The creation rate is 1 sandbox per second on Hobby and 5 per second on Pro.
Blaxel uses a tier system where concurrency limits unlock based on your trailing 30-day top-up volume. TIER 0 on the free plan gives 10 concurrent sandboxes. The top tier supports 100,000 or more.
Blaxel's broader platform
Blaxel offers five products beyond sandboxes that run on the same network backbone.
| Product | What it does | Max runtime | Cost |
|---|---|---|---|
| Sandboxes | Isolated microVM compute | No limit (standby model) | Usage-based |
| Agent Hosting | Serverless HTTP endpoints for agent code | 15 minutes | Usage-based |
| MCP Server Hosting | Host and serve MCP servers, 30+ pre-built integrations | 10 minutes | Usage-based |
| Batch Jobs | Parallel tasks in isolated sandboxes with cron scheduling | 24 hours | Usage-based, cron free |
| Model Gateway | Route LLM requests to 10+ providers with telemetry | - | Free |
For a developer building a full agent pipeline, Blaxel covers the whole stack: agent logic in Agent Hosting, tools in MCP Server Hosting, code execution in Sandboxes, scheduled runs via Batch Jobs, and LLM calls via the Model Gateway. E2B requires you to bring your own hosting for the agent itself and connect to model providers separately.
How much does it cost?
The pricing models differ significantly across all five tools. The right choice depends on how often you are actually using the machine.
Remote agent machines
| Tool | Model | Entry price | Free tier | Cost while idle |
|---|---|---|---|---|
| exe.dev | Flat monthly subscription | $20/month | No | Full rate |
| Sprites | Usage-based, pay per second | $0 (trial credits) | $30 credits at signup | $0 compute, storage only |
| Shellbox | Usage-based, pay per minute | $0 (top-up) | No ($10 minimum top-up) | $0.50/month per x1 slot |
exe.dev
exe.dev charges a flat monthly fee tied to your pool size. The base plan is $20/month for a 2 vCPU / 8 GB pool, scaling to $160/month for 16 vCPU / 64 GB. Up to 50 VMs are included on all plans. Additional disk costs $0.08/GB/month and additional transfer costs $0.07/GB/month. The flat fee is the same whether you use the machine for 10 hours or 700 hours that month.
Sprites
Sprites bills per second of actual use: $0.07 per CPU-hour, $0.04375 per GB-hour of RAM, and around $0.02 per GB-month for cold storage. When a Sprite is stopped you pay nothing for compute. A 4-hour Claude Code session costs approximately $0.44. New accounts get $30 in trial credits.
Shellbox
Shellbox bills per minute. An x1 box (2 vCPU, 4 GB RAM) costs $0.02/hour while running and $0.50/month while stopped. A 4-hour x1 session costs $0.08. There is no free tier. The minimum top-up is $10 and promo codes are available.
Which pricing model fits your usage
exe.dev is the better value if you use it heavily every day. One machine running constantly costs $20/month regardless.
Sprites and Shellbox are better for sporadic use. At one 4-hour session per week, Shellbox costs around $0.32/month, Sprites around $1.76/month, and exe.dev $20/month regardless.
Agent execution sandboxes
| Tool | Model | Free tier | Paid entry | Cost while idle |
|---|---|---|---|---|
| E2B | Usage-based + monthly plan fee | $100 one-time credits, no card required | $150/month (Pro) + usage | $0 when killed or paused |
| Blaxel | Pure usage-based, no subscription | Up to $200 credits, no card required | Pay-as-you-go after credits | $0 compute in standby, storage only |
E2B
E2B charges per second while a sandbox is running, plus a flat monthly plan fee on paid plans. The default sandbox (2 vCPU, 1 GB RAM) costs roughly $0.12/hour. The Hobby plan is free with $100 one-time credits. Pro is $150/month plus usage, with higher concurrency and longer session limits. You pay nothing when a sandbox is killed or paused.
Blaxel
Blaxel has no subscription fee. You pay only for what you use, with sandbox rates ranging from $0.000023/second for an XS (2 GB) sandbox to $0.000368/second for an XL (32 GB). Compute costs nothing while a sandbox is in standby. Only snapshot storage is charged. New accounts get up to $200 in free credits with no credit card required.
Do these tools support teams and enterprises?
Shellbox is explicitly solo-only. The other four tools all have team or enterprise tiers, but with significant differences.
Remote agent machines
| Tool | Team plan | SSO | Admin access to team VMs | Enterprise | Regions |
|---|---|---|---|---|---|
| exe.dev | Yes ($25/user/month) | Google OAuth + OIDC | Yes | Yes (AWS VPC integration) | 8 |
| Sprites | Yes ($20-$2,000/month tiers) | No | No | No | Not publicly listed |
| Shellbox | No | No | No | No | Helsinki only |
exe.dev has admin SSH access to team member VMs, SSO via Google OAuth or any OIDC provider, and an enterprise tier with AWS VPC integration. It is available in 8 regions.
Sprites has organizational plans with seat-based tiers and API token restrictions including maximum sprite counts, name prefix requirements, and expiry dates. Regional availability is not publicly listed.
Shellbox uses your SSH key as your identity. There are no org accounts, no shared billing, and no team management.
Agent execution sandboxes
| Tool | Compliance | HIPAA BAA | Self-hosting | Enterprise features |
|---|---|---|---|---|
| E2B | SOC 2, HIPAA | Included | Yes (Terraform on AWS/GCP/Azure/on-prem) | Custom pricing, custom limits |
| Blaxel | SOC 2, HIPAA, ISO 27001 | $250/month add-on | No | Dedicated infra, private network, SSO (SAML), SCIM, custom SLA |
E2B's standout enterprise feature is self-hosting. Organizations with data residency requirements can run E2B on their own infrastructure via Terraform. HIPAA is included on enterprise plans.
Blaxel holds SOC 2, HIPAA, and ISO 27001 certifications. Its enterprise tier adds dedicated infrastructure, a private network, SSO via SAML, and SCIM directory sync. Support costs extra: email support is $800/month plus 3% of usage, and live Slack support is $1,600/month plus 10% of usage. HIPAA BAA is a $250/month add-on.
Which tool should you use for running AI agents in the cloud?
The right choice depends on whether you need a machine the agent lives inside, or a sandbox it calls via API to execute code safely.
Why exe.dev is the best remote agent machine for AI development
exe.dev is the most complete remote agent machine available. It is the only tool in this category that combines all of the following:
- Built-in LLM gateway so agents call Anthropic, OpenAI, and Fireworks APIs without API keys on the VM
- Credential injection that keeps GitHub tokens and bearer tokens off the machine entirely
- Shelley, a pre-installed web-based agent that works without any local setup
- VMs that never stop unless you explicitly delete them, with no process restart required
- Team features including admin SSH access to member VMs, SSO, and AWS VPC integration
- Flat $20/month pricing that does not change whether the machine runs for 10 hours or 700 hours
If you want usage-based pricing, use Sprites
Sprites bills by the second and charges nothing while a Sprite is idle. It has the best specs of the three, autoscaling to 16 GB RAM and 8 vCPU, and the checkpoint feature lets you roll back a risky agent operation in under a second. At one 4-hour session per week, Sprites costs around $1.76/month compared to $20/month for exe.dev. If minimizing cost is the only priority, Shellbox costs $0.08 for a 4-hour session.
Why E2B is the best sandbox for executing LLM-generated code
E2B is the best choice for executing LLM-generated code safely. It stands out from Blaxel on several points:
- Cold starts under 200ms (80ms same-region) so the sandbox adds no meaningful latency to the agent loop
- The broadest agent framework support, including LangChain, LangGraph, LlamaIndex, AutoGen, CrewAI, Vercel AI SDK, and OpenAI Agents SDK
- An open-source codebase you can inspect and contribute to
- Self-hosting via Terraform on AWS, GCP, Azure, or on-premises for organizations with data residency requirements
- HIPAA included on enterprise plans with no extra fee
If your agent needs persistent sandbox state, use Blaxel
Blaxel sandboxes suspend rather than stop, resuming in 25ms with full memory and filesystem state preserved. Compute costs nothing while in standby. It also covers agent hosting, MCP servers, batch jobs, and an LLM gateway if you want a single platform for the full stack.