CubeSandbox vs. E2B für Produktions-Agenten

Ich bin Dora. Vor Kurzem hatten wir einen Agenten, der in der Produktion Tool-Calls ausführte. Der Orchestrator war in Ordnung. Das LLM war in Ordnung. Der Flaschenhals war die Sandbox-Schicht — jedes Mal, wenn der Agent ein Stück generierten Code ausführen musste, zahlten wir 200ms Kaltstart, manchmal mehr, manchmal wurde die Warteschlange launisch. Bei ~40 Tool-Calls pro Session summiert sich das zu einem spürbaren Anteil der Gesamtlaufzeit.

Also begann ich, die Alternativen zu untersuchen. Der Vergleich, den gerade alle zu führen scheinen, ist CubeSandbox vs E2B. Dieser Beitrag fasst zusammen, was ich nach zwei Wochen gefunden habe, in denen ich beide Projekte gelesen, eines davon deployed und das andere nicht deployen konnte (dazu komme ich noch).

Kurzer Hinweis vorab: Ich habe keine kommerzielle Beziehung zu einem der beiden Projekte. Beide sind Open Source. Das Bild unten ist ein Hosted-vs-Self-Hosted-Kompromiss, kein „Guter-gegen-Böser”-Vergleich.

CubeSandbox vs E2B auf einen Blick

Beide Projekte lösen dasselbe Problem auf ungefähr dieselbe Weise: eine MicroVM starten, nicht vertrauenswürdigen Code ausführen, sie wieder herunterfahren. Beide veröffentlichen Performance-Zahlen in derselben Größenordnung. Der eigentliche Unterschied liegt in der Produktform.

CubeSandbox ist ein Open-Source-Sandbox-as-a-Service-Stack von Tencent Cloud, veröffentlicht im April 2026 unter Apache 2.0. Basiert auf RustVMM und KVM. Headline-Zahlen aus ihrem Repo: unter 60ms Kaltstart, ~5MB Speicher pro Sandbox, native E2B SDK-Kompatibilität (eine URL-Umgebungsvariable austauschen). Er wird als vollständiger, selbst hostbarer Stack vertrieben, nicht nur als Bibliothek.

E2B ist ebenfalls Open Source (ebenfalls Apache 2.0), basiert auf Firecracker-MicroVMs. Gegründet 2023. Sandbox-Initialisierung liegt bei etwa 150–200ms mit vorgewärmten Snapshot-Pools. Self-Hosting ist über Terraform-Skripte möglich, aber die primäre Distribution ist die verwaltete Cloud — Hobby (kostenlos, $100 Credits), Pro ($150/Monat + Nutzung), Enterprise (BYOC, On-Prem). Self-Hosted-Nutzer sind eine Minderheit, Hosted ist die Standardlösung.

Die eigentliche Achse ist also nicht „welche Sandbox ist besser”, sondern:

Feature	CubeSandbox	E2B
Lizenz	Apache 2.0	Apache 2.0
Primärer Modus	Self-Hosted	Hosted SaaS (Self-Hosting möglich)
Zugrunde liegende VMM	RustVMM + KVM	Firecracker (KVM)
Veröffentlichter Kaltstart	`<60ms`	~150–200ms
Speicher pro Sandbox	~5MB	~5MB
SDK-Kompatibilität	E2B SDK Drop-in	Natives E2B SDK
GPU-Unterstützung	Erfordert KVM-fähiges x86_64 Linux; kein nativer Passthrough im Upstream	Gleiche Firecracker-GPU-Einschränkungen
Betriebsaufwand	Sie betreiben den Cluster	E2B betreibt den Cluster (verwaltet)

Die obigen Zahlen stammen aus dem eigenen Repo und den Release Notes jedes Projekts, nicht aus einem von mir durchgeführten Benchmark. Behandeln Sie sie als Herstellerangaben — richtungsweisend nützlich, aber kein Ersatz für eigene Tests.

Hosted vs. Self-Hosted: Kompromisse

Das ist die eigentliche Entscheidung, und sie ist größtenteils nicht technischer Natur.

Wer E2B hosted nutzt, hört auf, über MicroVM-Kernel, Snapshot-Pools, KVM-Hosts und Orchestrator-Failover nachzudenken. Man hört auch auf, über Kostenoptimierung nachzudenken, weil der Preis für einen festgelegt ist. Das Team, in dem ich war, testete E2B Pro zwei Wochen lang — die Integration dauert tatsächlich etwa eine Stunde, das SDK ist sauber, und die eingesparten Engineering-Stunden sind real.

Wer CubeSandbox selbst hostet, besitzt die Maschine. Die Kosten werden zu „was kostet der zugrundeliegende Server” statt „was kostet unsere Nutzungskurve”. Compliance wird einfacher, weil keine Daten den eigenen Perimeter verlassen. Aber man übernimmt auch die On-Call-Rotation, die Kernel-Updates, das eBPF-Policy-Tuning. CubeSandbox liefert ein One-Click-Deployment für Einzelknoten- und Cluster-Setups, was hilft, aber „One-Click-Deployment” und „produktionsreifer Cluster” sind nicht dasselbe.

Ich hielt hier ein paar Tage inne, weil die Antwort wirklich von der Teamstruktur abhängt. Ein vierköpfiges Startup, das im nächsten Quartal Agenten ausliefert, sollte wahrscheinlich keine eigene MicroVM-Flotte betreiben. Ein Team mit Infra-Engineers und Compliance-Anforderungen wahrscheinlich schon.

Kompatibilitäts- und Migrationsfragen

Die CubeSandbox-E2B-Kompatibilitäts-Geschichte ist der technisch interessanteste Anspruch im CubeSandbox-Release. Laut ihrer Dokumentation kann ein bestehender E2B-basierter Agent eine einzige Umgebungsvariable austauschen und den Traffic zu einem selbst gehosteten CubeSandbox-Cluster routen — ohne Code-Änderungen. Ich habe persönlich noch keine E2B-Produktionsworkload migriert, nehme den Anspruch also vorerst auf Treu und Glauben, aber er ist durch Lesen der SDK-Calls, die beide Seiten akzeptieren, verifizierbar. Die Oberfläche ist klein. Beide sprechen denselben Sandbox-Lebenszyklus: erstellen, Befehl ausführen, Code ausführen, beenden.

Hier wird es nützlich: Es bedeutet, dass CubeSandbox im Wesentlichen ein Bring-your-own-Infrastructure-Backend für das E2B SDK ist. Man kann auf E2B’s gehosteter Cloud entwickeln und dann auf den eigenen Cluster umzeigen, wenn das Volumen es rechtfertigt. Das Lock-in-Argument wird für beide Seiten schwächer — was ich für gesund für die Kategorie halte.

Wo CubeSandbox gewinnt

Kontrolle, Kostenstruktur und Infrastruktur-Ownership

Für jedes Agenten-Team, das genug Volumen betreibt, dass verwaltete Sandbox-Preise in der Monatsrechnung auftauchen, ist CubeSandbox die ehrlichere Option. Man zahlt für Hardware, die man bereits versteht. Egress-Filterung über eBPF (CubeVS) ist auf Kernel-Ebene konfigurierbar. Wenn die Datenschutzregeln sagen „das darf unsere VPC nicht verlassen”, ist das ein 30-Sekunden-Gespräch mit einer selbst gehosteten Sandbox und ein wesentlich längeres Gespräch mit einer verwalteten.

Was zu selten gesagt wird: Ein selbst gehostetes Agent-Runtime ist kein kostenloses Mittagessen. Die Grenzkosten pro Ausführung sinken, die Fixkosten steigen. Der Break-even-Punkt ist für jedes Team mit seiner eigenen Nutzungskurve einzigartig. Rechnen Sie nach, bevor Sie entscheiden. Wenn die Antwort lautet „wir sparen $300/Monat und fügen zwei Stunden wöchentlicher Betriebsarbeit hinzu”, ist das kein Gewinn.

Performance- und Dichteansprüche, die Teams testen sollten

CubeSandbox veröffentlicht einen Kaltstart unter 60ms, den die Tencent Cloud Release Notes via HPCwire als “ein Drittel des Branchendurchschnitts (150ms)” beschreiben. Sie behaupten auch 2.000+ Sandboxes auf einer einzigen physischen Maschine. Diese Zahlen stammen aus Produktions-Workloads innerhalb von Tencent Cloud, nicht aus einem synthetischen Benchmark — was besser als synthetisch ist, aber es ist immer noch deren Workload, nicht Ihrer.

Was ich testen würde, bevor ich den Headline glaube:

Kaltstart bei Ihrer tatsächlichen Snapshot-Größe (ein 5GB-Template verhält sich anders als eines mit 200MB)
Konkurrenzverhalten bei p99, nicht nur Durchschnitt — CubeSandbox veröffentlicht eine durchschnittliche Antwortzeit von 67ms bei 50 gleichzeitigen Anfragen, was ermutigend, aber nicht dasselbe wie p99 ist
Ob Ihre spezifischen Abhängigkeiten den schlanken RustVMM-Kernel ohne Überraschungen überleben

Hier enden meine Daten. Ich habe CubeSandbox auf einer einzelnen KVM-fähigen VM deployed und es in etwa einem halben Nachmittag zum Ausliefern von Sandboxes gebracht. Ich habe es nicht bei den Dichtezahlen aus dem Release Stress-getestet. Wer Ihnen sagt, das getan zu haben, drei Wochen nachdem das Projekt öffentlich ist, übertreibt wahrscheinlich.

Wo E2B noch gewinnt

Die andere Hälfte des CubeSandbox-vs-E2B-Bildes: Wenn Sie nicht über Infrastruktur nachdenken wollen, gewinnt E2B. Dieser Satz klingt abweisend, ist aber die eigentliche Schlussfolgerung.

Konkret:

Das gehostete E2B SDK ist ausgereifter. Mehr Cookbook-Beispiele, mehr LangChain/LlamaIndex-Integrationen, längere Erfolgsbilanz.
Manus, Perplexitys Code-Analyse, Hugging Faces Open R1 — Produktionsreferenzen in großem Maßstab existieren. CubeSandbox hat Produktionsreferenzen innerhalb von Tencent Cloud, was real ist, aber die externen Fallstudien werden noch geschrieben.
Die E2B-Dokumentation deckt Desktop-Sandboxes, Templates aus Dockerfiles, File-Persistenz und 24h-Session-Lifetimes out of the box ab. CubeSandbox ist spartanischer — README und Beispiele decken den Kern-Lebenszyklus ab, nicht den langen Schwanz.
Firecracker selbst ist eine bekannte Größe. AWS Lambda läuft darauf. Das Firecracker-Projekt ist seit 2018 in Produktion. CubeSandboxs RustVMM-basierter Stack ist in der Öffentlichkeit neuer, auch wenn er schon eine Weile innerhalb von Tencent lief.

Wer im nächsten Quartal ein v1-Agenten-Produkt ausliefert und keine Infra-Person hat, findet in E2B’s gehostetem Plan den reibungsärmeren Weg. Die Stunden, die nicht mit dem Kampf gegen den eigenen Sandbox-Cluster verbracht werden, sind Stunden, die für den Agenten selbst genutzt werden. Das ist für viele Teams $150/Monat wert.

Ein Entscheidungsrahmen für Agenten-Teams

Nach zwei Wochen der Betrachtung ist hier der Rahmen, den ich tatsächlich verwenden würde. Dies ist eine der nützlichsten KI-Agenten-Sandbox-Vergleichs-Abkürzungen, die ich gefunden habe:

Volumen unter ~50.000 Sandbox-Stunden/Monat, keine Compliance-Anforderungen, kein Infra-Team → E2B hosted. Aufhören zu lesen.
Volumen darüber, oder strenge Datenschutzpflichten, oder Sie betreiben bereits Kubernetes/MicroVMs → CubeSandbox self-hosted. Die Wirtschaftlichkeit dreht sich um, und Sie haben die Kompetenz, es zu betreiben.
Irgendwo dazwischen → Auf E2B hosted starten. Mit dem SDK entwickeln. Wenn die Rechnung anfängt zu schmerzen oder Compliance Fragen stellt, bedeutet die SDK-Kompatibilität, dass die Migration eine URL-Änderung entfernt ist. Diese Optionalität ist die am meisten unterschätzte Eigenschaft dieses gesamten Vergleichs.
Sie benötigen GPU-Passthrough für Agent-Inferenz innerhalb der Sandbox → Keines der beiden ist großartig. Upstream Firecracker unterstützt GPU-Passthrough nicht nativ, und CubeSandbox erbt eine ähnliche Einschränkung. Schauen Sie sich gVisor oder Daytona für diese Workload an.

Der Rahmen, dem ich widerstehen würde: „CubeSandbox ist die bessere Technologie, also gewinnt sie.” Eine MicroVM-Sandbox-Wahl ist eine Produktform-Entscheidung. Die Technologie ist in den veröffentlichten Spezifikationen ungefähr gleichwertig. Die täglichen Kosten sind operativer Natur.

FAQ

Dies sind die Fragen, die mir Teamkollegen immer wieder stellten, während ich die CubeSandbox-vs-E2B-Evaluierung durchführte.

Ist CubeSandbox ein Drop-in-Ersatz für E2B?

Für die E2B SDK-Oberfläche, ja — by design. Das Projekt vermarktet sich als E2B-kompatibles Runtime, bei dem man eine Umgebungsvariable austauscht. Für Features jenseits des Kern-Sandbox-Lebenszyklus (Templates aus Dockerfiles, Desktop-Sandboxes, gehostete Observability) lautet die Antwort „noch nicht”.

Was fügt Self-Hosting dem Arbeitsaufwand tatsächlich hinzu?

Einen KVM-fähigen Host (oder eine Flotte), Kernel/Image-Management, Monitoring, Snapshot-Pool-Tuning, Netzwerk-Egress-Policy und On-Call. Tencent Clouds Release beschreibt „One-Click-Deployment” für Einzelknoten- und Cluster-Setups, aber das als identisch mit einem produktionsreifen Cluster zu behandeln, ist optimistisch. Planen Sie 1–2 Wochen für das Setup und einen wiederkehrenden kleinen Anteil an jemandes Aufmerksamkeit.

Welche Workloads profitieren am meisten von MicroVM-Sandboxes?

Alles, wo man model-generierten Code gegen nicht vertrauenswürdige Eingaben im großen Maßstab ausführt. Das Shared-Kernel-Risiko von normalem Docker ist das Standardargument gegen Container hierfür — jede große Agenten-Plattform hat aus diesem Grund auf Shared-Kernel-Isolation verzichtet. Wenn der Agent nur sandboxed Code aus einer festen Allowlist vertrauenswürdiger Skripte ausführt, braucht man möglicherweise überhaupt keine MicroVM.

Was sollten Teams zuerst benchmarken?

Drei Dinge, in dieser Reihenfolge: p99-Kaltstart bei der tatsächlichen Template-Größe; Sandbox-Dichte pro Dollar Hardware (für self-hosted) oder pro Dollar Rechnung (für hosted); Fehlerverhalten bei Burst-Load. Die Headline-Zahlen — unter 60ms vs. ~150ms — sind real, aber sie beschreiben Durchschnittswerte unter herstellergünstigen Bedingungen. Ihre Workload wird keiner der beiden Anbieterworkloads entsprechen, was der einzige Grund ist, überhaupt zu benchmarken.

Fazit

Die CubeSandbox-vs-E2B-Debatte ist real, aber leicht falsch eingerahmt. Es geht nicht darum, „welche Sandbox technisch überlegen ist”. Beide nutzen Hardware-Level-Isolation, beide veröffentlichen glaubwürdige Performance-Zahlen, beide sind Apache 2.0, beide sprechen dasselbe SDK. Die Entscheidung ist: Wollen Sie, dass jemand anderes die Infrastruktur betreibt, oder wollen Sie sie selbst betreiben?

Das ist eine Produktfrage, keine technische. Und die ehrliche Antwort für die meisten Teams lautet „hosted starten, Migration günstig halten”. Die SDK-Kompatibilität zwischen den beiden Projekten ist das Nützlichste an diesem gesamten Release — sie bedeutet, dass die Lock-in-Steuer für alle in der Agenten-Infrastruktur gerade kleiner geworden ist.

Mehr folgt, sobald ich CubeSandbox unter echter Last getestet habe. Beide Projekte entwickeln sich schnell — dieser Vergleich wird nicht so gut altern wie die zugrundeliegende Technologie.

Vorherige Beiträge: