Shells vs E2B
Agent sandboxes, two philosophies.
E2B popularized cloud sandboxes for AI agents and has a mature SDK ecosystem around its Firecracker-based runtime. Shells approaches the same problem from the platform side: one isolation product with selectable runtime classes, hard tenancy boundaries, and MCP as a first-class door rather than an integration.
The matrix
Dimension by dimension.
Green check marks where we believe one side has a real edge. A dash means it's genuinely close — read the words, not just the dots.
Isolation model
Shells
Three runtime classes per shell — wasm, container, microvm — chosen at create time.
E2B
Firecracker microVMs as the single isolation substrate.
Agent / MCP integration
Shells
First-party MCP server (shells_list / create / action / term); every call gated by the shells.agent.invoke entitlement plus instance permission.
E2B
Rich Python/JS SDKs and many framework integrations; MCP available through community/secondary tooling.
Lifecycle safety
Shells
Explicit capability set: snapshot, wipe_state, reinstall_os, restart, stop, logs — destructive ones confirmed and recorded.
E2B
Sandbox lifecycle (create, pause/resume, kill) with persistence options; fewer explicit destructive-state controls.
Credentials handling
Shells
Short-lived term credentials, masked in the console, minutes-long TTL by design.
E2B
API-key based access to sandboxes; long-lived keys managed by you.
Ecosystem maturity
Shells
Young product, one platform, deliberately small surface.
E2B
Large template gallery, code-interpreter patterns, broad framework adoption.
Pricing model
Shells
Per-second runtime metering, rates by isolation class; lifecycle actions free.
E2B
Usage-based compute pricing per sandbox resources.
Choose E2B when…
- You want the largest ecosystem of agent-sandbox templates and examples today.
- Your stack is built around their Python/JS SDK patterns and you have no MCP requirement.
- You need features of a several-years-mature hosted product right now.
Yes, we mean it. Wrong-fit customers are expensive for everyone.
Choose Shells when…
- MCP is your agent interface and you want it first-party, not bolted on.
- You want to pick isolation strength per workload instead of paying microVM cost for everything.
- You want explicit snapshot/wipe semantics and credential TTLs measured in minutes.
- Your org needs tenancy boundaries enforced by the platform (Keystone), not by convention.
Migration notes
Moving from E2B
The honest version: most migrations are a week of mapping calls, not a quarter of replatforming.
Map sandbox creation: their SDK create call → ShellsClient.create({ language, runtime, network }).
Replace long-lived API keys with minted term credentials where agents connect to live sessions.
Their kill/pause flows map to stop/restart; add snapshot before risky steps — it's free.
Point MCP-capable agents at npx @l1fe/shells-mcp and delete your custom tool wrappers.