Amulet vs E2B storage
E2B and Amulet solve different problems, and most serious agent stacks need both. E2B answers "where does my agent's code run?" — its filesystem is a property of a running sandbox, persisted by pausing that sandbox, and cross-session state officially belongs in an external store like S3. Amulet is that external store done properly for agents: a real filesystem rather than an object API, with commits, provenance, and instant forks, mounted into each fresh sandbox in under 100 ms. Run your agents on E2B; keep their work in Amulet.
Amulet
Amulet is a storage-first file system for agent workloads: durable, versioned workspaces that mount into any sandbox in under 100 ms and outlive all of them.
E2B storage
E2B provides cloud sandboxes for AI agents to execute code, each with its own ephemeral filesystem that can be persisted by pausing and snapshotting the sandbox.
Capability by capability
Capability
Amulet
E2B storage
Storage decoupled from sandbox lifecycle
Amulet
Yes
Workspaces are durable objects; kill any sandbox and the work is still there, mountable from the next one.
E2B storage
No
The filesystem is the sandbox's disk; it persists only while the sandbox (or its paused snapshot) exists.
Cross-session persistence
Amulet
Yes
Mount the same workspace from session after session; history carries provenance across all of them.
E2B storage
Partial
Pause/resume snapshots the whole sandbox; durable cross-session state is expected to live in an external store you integrate yourself.
Sharing data between sandboxes
Amulet
Yes
Many sandboxes mount isolated sessions of one workspace concurrently; publishes merge conflict-safely.
E2B storage
No
Sandbox filesystems are isolated per sandbox; sharing means uploading to an external service.
Instant copy-on-write forks
Amulet
Yes
Fork a workspace per agent or per attempt in milliseconds; zero bytes copied.
E2B storage
Partial
Sandbox templates and snapshots clone an environment, but data forks aren't a storage primitive.
Version history
Amulet
Yes
Content-addressed commits; restore any revision of the workspace exactly.
E2B storage
No
A snapshot preserves one moment of one sandbox; there's no browsable, restorable history of the data.
Provenance
Amulet
Yes
Every commit records the actor, session, and run that produced it.
E2B storage
No
No per-change attribution on sandbox files.
Data scale
Amulet
Yes
Gigabytes to a full data estate behind one mount; mount time doesn't grow with size.
E2B storage
Partial
Bounded by sandbox disk allocations sized for code execution, not datasets.
Storage pricing
Amulet
Yes
$0.20/GiB-month for actively used data; API and transfers free; 10 GB free tier.
E2B storage
Partial
Storage rides on sandbox pricing — paused sandboxes keep consuming storage until deleted, and forgotten ones accumulate cost silently.
Code execution
Amulet
No
Amulet is storage — bring your own compute, E2B included.
E2B storage
Yes
Firecracker-isolated sandboxes with fast startup; this is what E2B is for.
When to choose E2B storage
- You need isolated compute for agent-generated code — that's E2B's product, and Amulet doesn't compete with it.
- Your agents' filesystem needs are ephemeral scratch space that can vanish with the sandbox.
- Pausing one sandbox and resuming it later covers all your persistence needs.
When to choose Amulet
- Agent work must survive sandboxes — killed, timed out, or scaled to zero — without hand-rolled S3 sync.
- Fan-out workloads need many sandboxes working on the same data with isolation and conflict-safe merges.
- You want to know which agent produced which file, from which base revision.
- The dataset is bigger than a sandbox disk.
Frequently asked questions
Does Amulet replace E2B?
No — it completes it. E2B is compute: isolated sandboxes where agent code runs. Amulet is storage: durable, versioned workspaces those sandboxes mount. E2B's own architecture expects durable cross-session state to live in an external store; Amulet is that store, shaped like a filesystem instead of an object API.
Can I mount Amulet inside an E2B sandbox?
Yes. Amulet mounts from any Linux environment in under 100 ms, so each fresh sandbox starts with the agent's full workspace already in place — no download step, no sync scripts, and everything written is preserved when the sandbox dies.
Why not just pause E2B sandboxes to persist state?
Pausing works for resuming one agent's session, but it preserves a whole sandbox, not versioned data: you can't mount a paused filesystem from elsewhere, share it between concurrent sandboxes, fork it per attempt, or restore an earlier revision — and paused sandboxes keep consuming storage until you remember to delete them. Amulet makes the data itself durable, versioned, and mountable from anywhere.
How do agents share files across E2B sandboxes?
Without Amulet: upload to S3 or a database and download in the next sandbox, with your own conflict handling. With Amulet: every sandbox mounts an isolated session of the shared workspace, reads are instant, and publishes are compare-and-swap — concurrent agents can't silently overwrite each other's work.