ephemora-cell vs superserve
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 — Persistent, secure sandboxes for AI agents on Firecracker microVMs — TypeScript and Python SDKs, CLI and console; the runtime is a hosted service, the SDK stack is Apache-2.0.
superserve offers persistent Firecracker sandboxes with SDKs; Cell is ephemeral, stateless per-execution WASM with signed records instead of persistence.
| ephemora-cell | superserve | |
|---|---|---|
| Stars | 40 | 460 |
| Forks | 5 | 53 |
| Language | Python | TypeScript |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | yesterday | 3 days ago |
| Topics | security, agents | agents |
| Curated connections | 6 | 2 |
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.
superserve — the curator's take
The pitch is persistence: sandboxes that survive between agent runs instead of being disposable, on Firecracker isolation. Know what the repo is before starring: this is the SDK/CLI/console monorepo — the actual sandbox runtime lives behind the hosted service at superserve.ai, and the README is a contributor doc, not a product doc (the substance is at docs.superserve.ai). Use it when you want managed microVM sandboxes with a clean SDK and don't want to run KVM hosts; NOT for air-gapped or self-hosted requirements — that's CubeSandbox's territory. Young project, small community — evaluate the service's durability before building on it.