ephemora-cell vs forkd
Capability-based WASM sandbox for MCP tools and agent-generated code: wasmtime + WASI with fuel, memory, time and I/O caps per run, sub-ms warm execution and signed (JCS/ES256) execution records. — versus — fork() for agent microVMs: children fork copy-on-write from a warm Firecracker parent — 100 KVM-isolated VMs in ~100ms, live-VM branching in ~56ms, portable snapshots from a hub.
forkd forks Firecracker microVMs copy-on-write for ms-scale agent sandboxes; Cell gets sub-ms by staying inside wasmtime - different trade-off on what code can run.
| ephemora-cell | forkd | |
|---|---|---|
| Stars | 40 | 2.9k |
| Forks | 5 | 220 |
| Language | Python | Rust |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | yesterday | 5 days ago |
| Topics | security, agents | agents, local |
| Curated connections | 6 | 3 |
ephemora-cell — the curator's take
Use Ephemora Cell when the thing you need to run is small, untrusted and frequent - an MCP tool, a plugin, a snippet the agent just wrote - and you want a receipt: every run returns status, fuel consumed, elapsed ms and the enforced policy in a canonicalized, signable record. 0.17 ms warm start beats any container or microVM by orders of magnitude. The catch is the WASM boundary: your workload has to compile to a .wasm/WASI module, so this is not 'run arbitrary Python or a Docker image'. For full-OS sandboxes (shell, packages, browsers) reach for cubesandbox, forkd, superserve or opensandbox instead; Cell sits *under* an MCP server as an execution primitive, not beside it as a platform. 40 stars, one author - solid tests (424) but treat the signing story as early.
forkd — the curator's take
The sandbox primitive agent fan-out actually wants: instead of cold-booting a kernel per child, a parent VM boots once with your runtime warm (deps imported, model loaded, JVM JITed) and children mmap its memory copy-on-write — so spawning 100 isolated environments costs ~100ms, and v0.4 can BRANCH a live running VM. Tree-search agents, parallel experiment runners and RL rollouts are the natural fits. NOT a managed platform: Linux/KVM only, you operate it, and there's no E2B-style API compatibility — this is a runtime primitive you build on, not a sandbox service you call.