E2B vs Daytona vs Modal: 1.200 Sandbox-Starts im Vergleich

In unserem Benchmark brauchte E2B 264 ms, um eine Sandbox zu erstellen und den ersten Befehl abzuschließen. Daytona brauchte 819 ms, Modal 929 ms. Das sind die Mediane aus 300 Starts je Anbieter am 12. Oktober 2026. Lizard brauchte im selben Test 228 ms.

Wir verkaufen Lizard Sandboxes. Dies ist unser eigener Benchmark. Die Ergebnisse gelten für unseren Testrechner und die unten aufgeführten Einstellungen. Wir veröffentlichen die Rohdaten und das Testskript, damit Sie die Werte prüfen können. Wir zeigen auch, welche Funktionen E2B, Daytona und Modal bieten, die Lizard fehlen.

E2B vs Daytona vs Modal: die Ergebnisse

Jede Zeile umfasst 300 Starts von einem Testrechner in US East. Die Zeitmessung begann vor dem create-Aufruf und endete, sobald ein Python-Befehl eine vorgegebene Zeichenfolge zurückgab. Alle 1.200 Starts waren erfolgreich. Nach jedem Test löschten wir die Sandbox.

Der Median liegt in der Mitte dieser Stichprobe. Rund 95% der erfassten Starts waren innerhalb der p95-Zeit abgeschlossen: 603 ms bei E2B und 1.671 ms bei Daytona. Diese Perzentile beschreiben unseren Test. Sie sagen nicht voraus, wie viele langsame Starts Ihre Anwendung täglich haben wird.

Die angegebenen 95%-Konfidenzintervalle der Mediane liegen bei 225 bis 230 ms für Lizard, 260 bis 269 ms für E2B, 789 bis 856 ms für Daytona und 914 bis 940 ms für Modal. Sie beschreiben die Unsicherheit innerhalb dieser Stichprobe. Andere Regionen, Ressourcen, Zeitpunkte oder Lasten können die Ergebnisse verändern.

Was der create-Aufruf misst

Ein create-Aufruf kann zurückkehren, bevor eine Sandbox Code ausführen kann. Wie sich die Zeit auf diesen Aufruf und den ersten Befehl verteilt, hängt vom Anbieter ab:

Wir berechnen jeden Median einzeln. Die Mediane für create und den Befehl müssen daher in der Summe nicht dem Median der Gesamtzeit entsprechen. Die Befehlsphase enthält auch die Zeit für lokale Log-Ausgaben des Skripts nach der Rückkehr von create.

Bei Modal kehrte create nach 45 ms zurück, dem niedrigsten Median im Test. Der nächste Befehl brauchte im Median weitere 883 ms. Daytona verbrachte den Großteil der Zeit in create und lieferte danach das Ergebnis des ersten Befehls in 82 ms.

Für einen Agenten, der auf die Ausführung von Code wartet, zählt die Gesamtzeit. Ein Test nur des create-Aufrufs würde Modal an die erste Stelle setzen; unser Test setzte es an die letzte. Keiner der beiden Werte allein misst, wie schnell Code in einer bereits bereiten Sandbox läuft.

E2B vs Daytona

Die mediane Wartezeit betrug 264 ms bei E2B und 819 ms bei Daytona, also etwa das Dreifache. Auch die langsamen Starts dauerten bei Daytona länger. Sein p99 lag bei 2.332 ms und das Maximum bei 5.532 ms, gegenüber 736 ms und 1.260 ms bei E2B.

Nach der Rückkehr von create brauchte Daytonas erster Befehl im Median 82 ms, die kürzeste Befehlszeit im Test. Das machte Daytona aber nicht zum schnellsten Anbieter bis zum ersten Ergebnis: Der create-Aufruf dauerte 728 ms.

E2B und Daytona nennen dieselben CPU- und Speicherpreise: $0.0504 pro vCPU-Stunde und $0.0162 pro GiB-Stunde, sekundengenau abgerechnet. Die Standardgrößen unterscheiden sich. Daytona startet mit 1 vCPU, 1 GiB Arbeitsspeicher und 3 GiB Festplattenspeicher. E2Bs Dokumentation der Basisvorlage nennt 2 vCPU und 512 MiB; die Preisseite bezeichnet dagegen 2 vCPU und 4 GiB als Standard. Prüfen Sie vor der Kostenrechnung die Vorlage, die Sie verwenden wollen. Siehe E2B-Preise und Daytona-Preise.

E2B nutzt Firecracker-MicroVMs mit jeweils eigenem Kernel. Daytona nutzt standardmäßig Linux-Container und bietet auch Linux-VMs und Windows-Sandboxes an. E2B veröffentlicht seinen Code unter Apache-2.0. Daytona verlagerte die Entwicklung seines Produktkerns im Juni 2026 in eine private Codebasis und archivierte das öffentliche Repository. E2B kommt daher infrage, wenn Sie den aktuellen Sandbox-Code prüfen oder selbst betreiben müssen. Unser Leitfaden zu E2B-Sandboxes beschreibt die Tarife und Limits.

Daytona wirbt mit weniger als 90 ms von der Erstellung bis zur Codeausführung. Unser Median für create lag bei 728 ms. Wir maßen von einem externen Client aus über die öffentliche API; die veröffentlichte Zahl kann auf einem anderen Ablauf oder Aufbau beruhen. Unser Test erklärt nicht, warum die Werte voneinander abweichen.

Daytona vs Modal

Daytona hatte mit 819 ms den niedrigeren Median, gegenüber 929 ms bei Modal. Bei Modal fielen die langsamen Starts kürzer aus: p99 lag bei 1.593 ms und das Maximum bei 1.932 ms, gegenüber 2.332 ms und 5.532 ms bei Daytona.

Modal unterstützt gVisor-Container und VMs mit eigenem Kernel. VM Sandboxes sind seit dem 1. Oktober 2026 allgemein verfügbar. Wir überließen Modal die Wahl der Laufzeitumgebung. Dieser Test vergleicht die beiden Laufzeitumgebungen daher nicht. Siehe den Leitfaden zu Modal Sandboxes und die Ankündigung von VM Sandboxes.

Modals eigener Benchmark nennt einen Median von unter einer halben Sekunde zwischen create-Anfrage und Bereitschaft zur Ausführung von Nutzercode. Unser Test brauchte 929 ms bis zur Ausgabe des ersten Befehls. Wir setzten region="us-east"; aus dem Test geht nicht hervor, ob diese Wahl die Startzeit beeinflusste. Modal berechnet für diese Regionseinstellung das 1.75-Fache des Basistarifs und beschränkt die Platzierung auf diese Region. Der Leitfaden zur Regionswahl erklärt die Optionen.

Daytona berechnet $0.0504 pro vCPU-Stunde. Die Sandbox-Preise von Modal beginnen bei $0.1419 pro physischem Kern und Stunde; ein physischer Kern entspricht zwei vCPUs. Modal fordert standardmäßig 0.125 CPU-Kerne und 128 MiB Arbeitsspeicher an. Für die Abrechnung zählt der höhere Wert aus angeforderten und genutzten Ressourcen. Vergleichen Sie gleiche Größen sowie Speicher- und Regionskosten, bevor Sie nach dem Preis entscheiden.

E2B vs Modal

E2B lieferte das erste Ergebnis früher: nach 264 ms im Median gegenüber 929 ms bei Modal. Modal brauchte etwa 3.5-mal so lange. Beim p99 waren es 736 ms für E2B und 1.593 ms für Modal.

E2B gibt für das Laden einer Sandbox aus einem Snapshot etwa 80 bis 150 ms an. Wir maßen über die öffentliche API einen create-Median von 162 ms. Die Werte erfassen unterschiedliche Arbeitsschritte. Unser Ergebnis bestätigt daher nicht die Angabe zur Snapshot-Ladezeit. Die Vorlagendokumentation beschreibt den Ablauf.

Wenn Sie Modal und Daytona als E2B-Alternativen prüfen: Beide bieten GPU-Sandboxes. Bei Modal stehen außerdem Regionen in den USA, Europa und im asiatisch-pazifischen Raum zur Wahl. Der Starter-Tarif hat keine Monatsgebühr und enthält jeden Monat Rechenleistung im Wert von $30. E2Bs Hobby-Tarif enthält ein einmaliges Guthaben von $100; Pro kostet $150 pro Monat zuzüglich Nutzung. Der schnellere E2B-Start in diesem Test entscheidet die Wahl nicht, wenn Ihre Aufgabe eine GPU braucht. Siehe Modal-Preise sowie Abrechnung und Limits bei E2B.

Lizard-Ergebnisse aus fünf Testläufen

Lizard hatte in jeder Spalte des Haupttests den niedrigsten Wert. Der langsamste Start dauerte 693 ms, weniger als E2Bs p99 von 736 ms. Lizard Sandboxes nutzen Firecracker-MicroVMs mit getrennten Kerneln und starten aus einem vorbereiteten Pool.

Wir führten den Test zwischen dem 8. und 12. Oktober fünfmal an drei Tagen aus. Die Haupttabelle oben zeigt den ersten Lauf vom 12. Oktober:

Am 8. Oktober war E2B schneller als Lizard. Bis zum 10. Oktober war der create-Median von Lizard von 210 ms auf 104 ms gesunken. In den vier späteren Läufen hatte Lizard den niedrigsten Gesamtmedian. Daytonas Median blieb in allen fünf Läufen unter Modals Wert. Die Tests zeigen die Schwankungen in diesem Zeitraum, belegen aber keine langfristige Leistung.

Wann E2B, Daytona oder Modal passen

Manche Anforderungen wiegen schwerer als der Unterschied bei der Startzeit. E2B, Daytona und Modal decken jeweils Aufgaben ab, für die Lizard nicht geeignet ist.

Lizard Pro erlaubt 100 laufende Sandboxes, 24 neue Starts pro Minute und 400 pro Tag. Höhere Limits erfordern Enterprise. E2B Hobby erlaubt eine neue Sandbox pro Sekunde und 20 gleichzeitig. Daytonas erste Stufe erlaubt 300 Erstellungen pro Minute. Modal Starter erlaubt 100 gleichzeitige Container; das ist ein Limit für gleichzeitigen Betrieb, keine Erstellungsrate. Prüfen Sie Limits von Lizard, E2Bs Limits und Daytonas Limits für die jeweiligen Tarife.

So haben wir gemessen

Als Testrechner diente ein Container auf Railway in US East (us-east4). Er rief E2B, Daytona und Modal über deren offizielle SDKs auf und Lizard über seine REST API.

In jeder Runde mischte das Skript die Reihenfolge der Anbieter und startete parallel je eine Sandbox. Pro Anbieter lief höchstens ein Start zur selben Zeit. Wir verwarfen drei Aufwärmrunden und zeichneten dann 300 Runden auf.

Die Zeitmessung begann vor create. Sie endete, sobald python3 -c "print('arena-startup-ready-20261001')" diese Zeichenfolge mit Exit-Code 0 zurückgab. Nach der Messung löschten wir die Sandbox. Das Skript wiederholte keine fehlgeschlagenen Versuche; alle Starts waren erfolgreich.

Wir verwendeten e2b-code-interpreter 2.8.1, e2b 2.34.0, daytona 0.200.0 und modal 1.5.2. Die Regionseinstellungen unterscheiden sich; wir haben nicht alle Anbieter auf dieselbe Region festgelegt. Auch Vorlagen, Ressourcen und Python-Versionen sind verschieden. Das Skript setzt Modal auf cpu=(2, 2). Modal zählt physische Kerne, wobei ein Kern zwei vCPUs entspricht. Diese Anfrage entspricht also 4 vCPU. Siehe den Leitfaden zu Sandbox-Ressourcen.

Der Test misst, wie schnell diese vorbereiteten Sandboxes ein erstes Ergebnis liefern. Er misst weder Massenerstellung noch den Bau eigener Images, andere Regionen, CPU-Leistung oder Kosten. Ein Anbieter kann Kapazität vor dem create-Aufruf vorbereiten. „Kaltstart“ bedeutet hier deshalb nicht, dass eine neue Maschine ohne Cache oder vorbereiteten Pool bootet.

Laden Sie alle 1.200 Messwerte als CSV, die Statistik als JSON und das Benchmark-Skript herunter.

Installieren Sie vor dem Start die Abhängigkeiten httpx, E2B, Daytona und Modal. Setzen Sie die Zugangsdaten der Anbieter sowie LIZARD_PROJECT_ID und richten Sie die Modal-Authentifizierung ein. Prüfen Sie Pfade und Prozessverhalten: Das Skript erwartet /app/results, schreibt raw.jsonl statt der veröffentlichten CSV- und Statistikdateien und lässt nach den Tests einen HTTP-Statusserver weiterlaufen. Passen Sie diese Teile an Ihren Testrechner an.

Welche Sandbox eignet sich am besten für KI-Agenten?

Wenn ein Agent eine neue Sandbox startet, während ein Nutzer wartet, hatten E2B und Lizard in diesem Test die kürzesten Wartezeiten: 264 ms und 228 ms im Median. E2B veröffentlicht außerdem seinen Sandbox-Code, was für eigenen Betrieb oder Code-Prüfungen wichtig sein kann.

Modal und Daytona unterstützen GPU-Aufgaben. Daytona bietet auch Windows und Sandboxes auf Ihren eigenen Rechnern. Wenn die Sandbox stundenlang laufen soll, vergleichen Sie neben der Startzeit auch laufende Kosten und Limits.

Was eine laufende Sandbox pro Stunde kostet

Die Tabelle schätzt die Kosten einer Sandbox mit 2 vCPU / 4 GiB anhand der am 12. Oktober 2026 veröffentlichten Preise. Sie vergleicht eine einheitliche Größe, nicht die unterschiedlichen Einstellungen unseres Startzeit-Tests. Alle vier Anbieter rechnen laufende Ressourcen sekundengenau ab. Dies sind Rechenkosten vor zusätzlichen Gebühren für Speicher, Netzwerk oder Tarife.

Für E2B und Daytona lautet die Rechnung: 2 × $0.0504 pro vCPU-Stunde + 4 × $0.0162 pro GiB-Stunde. Bei Modal ist es ein physischer Kern, entsprechend zwei vCPUs, zu $0.1419 pro Stunde + 4 × $0.0240 pro GiB-Stunde. Modals Summe enthält nicht den Regionsfaktor von 1.15x oder 1.75x. Lizard berechnet einen festen Satz für eine Small-Sandbox.

Nicht genutztes Inklusivvolumen von Lizard Pro verfällt am Monatsende. Zusätzliche Nutzung folgt dem Modell pay as you go.

Speicher- und Netzwerkgebühren können den Rechnungsbetrag verändern. Unser Preisleitfaden für Vercel Sandbox zeigt, wie Sie eine monatliche Sandbox-Rechnung durchrechnen. Prüfen Sie für die hier verglichenen Anbieter vor der Budgetplanung die verlinkten Preisseiten.

Die Startzeit einer Sandbox bei Lizard messen

Installieren Sie Lizard SDK, setzen Sie LIZARD_API_KEY und ersetzen Sie die Projekt-ID durch Ihre eigene. Dieses Beispiel misst einen Start über das Python SDK; der Benchmark oben nutzte die REST API von Lizard.

import time
from lizard import Sandbox

start = time.perf_counter()
sandbox = Sandbox.create("base", project_id="proj_123", size="small", region="us-east-1", timeout_ms=300_000)
try:
    result = sandbox.process.exec_("python3 -c \"print('ready')\"")
    print(result.stdout.strip(), f"{(time.perf_counter() - start) * 1000:.0f} ms")
finally:
    sandbox.kill()

Eine Small-Sandbox kostet $0.0162 pro Betriebsstunde, sekundengenau abgerechnet. Preise finden Sie auf der Sandboxes-Seite, Vorlagen und Limits in der Sandboxes-Dokumentation.

Häufige Fragen

Welche Sandbox eignet sich am besten für KI-Agenten? E2B und Lizard lieferten in unserem Test mit 1.200 Starts den ersten Befehl am schnellsten zurück, mit Medianen von 264 ms und 228 ms. E2B ist auch eine Option für offenen Code und eigenen Betrieb. Modal und Daytona unterstützen GPUs. Daytona bietet zudem Windows-Sandboxes und eigene Regionen auf Ihren Rechnern. Wählen Sie nach der Aufgabe des Agenten und testen Sie Ihre eigenen Einstellungen.

Was ist ein Sandbox-Kaltstart? In diesem Benchmark ist es die Zeit von der Anfrage einer neuen Sandbox bis zur Rückgabe des ersten Befehls. Sie enthält API- und Netzwerkzeit und kann Kapazität nutzen, die der Anbieter schon vorbereitet hat. Ein create-Aufruf allein kann enden, bevor die Sandbox Code ausführen kann.

Ist die Daytona-Sandbox kostenlos? Daytona bietet kostenlose Rechenleistung im Wert von $200 ohne Kreditkarte. Danach berechnet es reservierte Ressourcen sekundengenau. Das aktuelle Angebot und die Tarife finden Sie unter Daytona-Preise.

Ist Daytona Open Source? Daytona verlagerte die Entwicklung seines Produktkerns im Juni 2026 in eine private Codebasis und archivierte das öffentliche Repository. Der letzte öffentliche Code bleibt unter AGPL-3.0 verfügbar, seine SDKs unter Apache-2.0. Die Mitteilung im Repository erklärt die Änderung.

Was kostet die Daytona-Sandbox? Daytona berechnet für Sandboxes $0.0504 pro vCPU-Stunde und $0.0162 pro GiB-Stunde Arbeitsspeicher, sekundengenau abgerechnet. Eine Standard-Sandbox mit 1 vCPU / 1 GiB kostet $0.0666 pro Betriebsstunde, also etwa $0.067. Speicher über die ersten 5 GiB hinaus kostet $0.000108 pro GiB-Stunde.

Was ist eine Modal-Sandbox? Eine Modal-Sandbox führt nicht vertrauenswürdigen Nutzer- oder Agentencode in einer getrennten Umgebung auf Modal aus. Modal unterstützt gVisor-Container und seit Oktober 2026 VMs mit eigenem Kernel. Der Sandboxes-Leitfaden erklärt Erstellung und Nutzung.

Kann man Modal kostenlos nutzen? Modal Starter hat keine Monatsgebühr und enthält jeden Monat Rechenleistung im Wert von $30, auch für Sandboxes. Nutzung über diesen Betrag hinaus kostet extra und wird sekundengenau abgerechnet. Siehe Modal-Preise.

Ist E2B sicher? E2B führt jede Sandbox in einer Firecracker-MicroVM mit eigenem Kernel aus, um sie von anderen Sandboxes und dem Host zu trennen. E2B gibt an, einen SOC 2 Type II-Bericht zu haben. Sandboxes erlauben standardmäßig ausgehenden Internetzugriff. Beschränken Sie ihn für Code, der das Netzwerk nicht erreichen soll. Siehe E2Bs Sicherheitsdokumentation.

Quellen

• Benchmark-Daten: samples.csv, summary.json, startup.py
• E2B: Preise, Abrechnung und Limits, Preisberechnung, Sicherheit, Startzeiten der Vorlagen, Quellcode
• Daytona: Preise, Sandboxes, Limits, Mitteilung im Repository
• Modal: Preise, Sandboxes-Leitfaden, Ressourcen, Sandbox-Ressourcen, Regionswahl, Blogbeitrag zur Startzeit, VM Sandboxes
• Lizard: Sandboxes-Dokumentation, Größen, Preise und Limits

Preise und Limits geprüft am 12. Oktober 2026.