e2b-dev/code-interpreter: Python- und JS-SDK für Sandboxes, die KI-Code ausführen
Python & JS/TS SDK for running AI-generated code/code interpreting in your AI app
Auf einen Blick
- Was ist das?
- Das Repository liefert zwei SDKs, mit denen sich KI-generierter Python-Code in isolierten Cloud-Sandboxes ausführen lässt. Der wichtigste Vorbehalt steht im README selbst: Der SDK-Quellcode liegt nicht mehr hier, sondern im E2B-Monorepo.
- Für wen ist es gedacht?
- Wer KI-generierten Python-Code ausführen muss und dafür keine eigene Container-Infrastruktur betreiben will, findet hier ein schlankes SDK mit klarer Trennung zwischen Sandbox und Laufzeit. Wer den SDK-Quellcode lesen, patchen oder forken will, ist im falschen Repository: Er muss ins E2B-Monorepo unter packages/code-interpreter-python und packages/code-interpreter-js.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 5 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein SDK, kein Interpreter: was das Repository heute noch beherbergt
Der Name führt in die Irre. Wer hier einen ausführbaren Code-Interpreter erwartet, findet stattdessen ein Repository, das laut README nur noch zwei Dinge hält: das Sandbox-Template und den Chart-Data-Extractor. Der Quellcode der beiden SDKs, @e2b/code-interpreter für JavaScript und TypeScript sowie e2b-code-interpreter für Python, ist in das E2B-Monorepo gewandert, konkret unter packages/code-interpreter-js und packages/code-interpreter-python. Issues und Pull Requests zu den SDKs sollen dort geöffnet werden, nicht hier.
Das ist die erste Tatsache, die man kennen muss, bevor man dieses Repository klont. Ein Fork auf Basis des hier sichtbaren Stands erfasst die SDK-Logik nicht. Wer den Code lesen will, der runCode implementiert, muss in ein anderes Repository wechseln. Für Anwender, die nur die veröffentlichten Pakete installieren, ändert sich dadurch nichts: Die Releases @e2b/code-interpreter@2.7.1 und @e2b/code-interpreter-python@2.9.1 vom 13. August 2026 erscheinen weiterhin, sie werden nur aus dem Monorepo gebaut. Die Versionsnummern laufen auseinander, 2.7.x auf der JS-Seite und 2.9.x auf der Python-Seite, was bei gemischtsprachigen Teams zu Verwirrung führen kann, wenn beide Seiten als gleichwertig angenommen werden.
Das Problem: fremder Code braucht eine Wegwerf-Umgebung
Ein Sprachmodell, das auf eine Datenanalyse-Anfrage mit Python-Code antwortet, liefert zunächst nur Text. Damit dieser Text nützlich wird, muss er ausgeführt werden, und zwar mit Zugriff auf Dateien, Bibliotheken und Rechenzeit. Ihn im eigenen Prozess auszuführen ist keine Option: Der Code ist nicht geprüft, kann Endlosschleifen enthalten, das Dateisystem verändern oder Netzwerkzugriffe starten.
Genau diese Lücke adressiert das Projekt. Das README beschreibt E2B als Infrastruktur, die KI-generierten Code in sicheren, isolierten Sandboxes in der Cloud ausführt. Der Anwendungsfall ist damit klar umrissen: Anwendungen, die Nutzereingaben oder Modellausgaben in ausführbaren Code übersetzen und das Ergebnis zurück in die Oberfläche spielen wollen. Typische Beispiele sind Datenanalyse-Chats, bei denen Diagramme entstehen, oder Assistenten, die kurze Skripte ausprobieren. Wer dagegen deterministischen, selbst geschriebenen Code ausführt, braucht dieses Projekt nicht. Der Aufwand für eine Sandbox lohnt sich nur, wenn die Eingabe nicht vertrauenswürdig oder nicht vorhersehbar ist.
Sandbox.create() und runCode: der Ablauf in zwei Aufrufen
Das README zeigt den Mechanismus in wenigen Zeilen. In Python erzeugt ein Kontextmanager die Sandbox, danach folgen zwei Aufrufe von run_code. Der erste setzt eine Variable, der zweite erhöht sie und gibt sie zurück. Der entscheidende Punkt ist der Zustand zwischen den Aufrufen: x bleibt über die Grenze des zweiten Aufrufs hinweg erhalten. Das ist keine reine Funktionsevaluierung, sondern eine persistente Sitzung, in der Variablen, importierte Module und offene Dateihandles weiterleben.
Das Ergebnis eines Aufrufs ist ein Execution-Objekt mit einem text-Attribut. Im Beispiel gibt der zweite Aufruf 2 zurück, und genau dieser Wert landet in execution.text. Die JavaScript-Variante ist strukturell identisch, nur ohne Kontextmanager: Sandbox.create() wird awaited, runCode wird awaited, und das Ergebnis trägt ebenfalls ein text-Feld. Die API ist damit über beide Sprachen hinweg gleich aufgebaut, was den Wechsel erleichtert.
Was das README nicht zeigt, ist der Rückkanal für alles, was nicht Text ist. Ob Bilder aus matplotlib, Fehlerausgaben oder Zwischendateien über das Execution-Objekt abrufbar sind, lässt sich aus dem vorliegenden Material nicht belegen. Wer Diagramme oder Artefakte aus der Sandbox herausziehen will, muss das in der Dokumentation prüfen, bevor er die Architektur darauf aufbaut. Dasselbe gilt für Timeouts und Ressourcenlimits: Das README nennt keine Zahlen.
Installation und der API-Key als harte Abhängigkeit
Die Einrichtung ist kurz. Für JavaScript und TypeScript lautet der Befehl npm i @e2b/code-interpreter, für Python pip install e2b-code-interpreter. Auffällig ist die Asymmetrie der Paketnamen: Auf npm heißt das Paket @e2b/code-interpreter, auf PyPI e2b-code-interpreter. Wer aus Gewohnheit pip install e2b eingibt, bekommt ein anderes Paket, denn im README steht für Python ausdrücklich e2b-code-interpreter. Der Import im Code folgt dann wieder einer dritten Schreibweise, nämlich from e2b_code_interpreter import Sandbox, mit Unterstrichen statt Bindestrichen. Drei Schreibweisen für dieselbe Sache sind eine realistische Fehlerquelle beim ersten Setup.
Danach braucht man einen Account bei E2B und einen API-Key aus dem Dashboard, der als Umgebungsvariable E2B_API_KEY gesetzt wird. Das README zeigt das Format e2b_***. Dieser Schritt ist nicht optional. Es gibt im vorliegenden Material keinen Hinweis auf einen lokalen Betrieb ohne Cloud-Anbindung, keinen Self-Hosting-Pfad und keine Konfiguration, die den Dienst ersetzt. Wer den Key nicht setzen kann oder will, kann das SDK nicht nutzen. Für Umgebungen mit strikten Vorgaben zur Datenhaltung ist das der ausschlaggebende Punkt gegen dieses Projekt, unabhängig von der Codequalität.
Eigene Templates: der Ausweg, wenn Standardpakete fehlen
Eine Sandbox ist nur so nützlich wie die Bibliotheken, die in ihr installiert sind. Das README adressiert diesen Punkt direkt mit der Frage nach zusätzlichen Paketen oder einer anderen Laufzeit und verweist auf den Template-Guide unter /template/README.md. Dort wird laut README beschrieben, wie man ein eigenes Code-Interpreter-Template erstellt, baut und verwendet, einschließlich des Produktions-Templates code-interpreter-v1.
Das ist der Pfad für alle, deren Analyse pandas, bestimmte Plot-Bibliotheken oder eine feste Version einer Abhängigkeit benötigt. Der Preis dafür ist ein Build-Schritt außerhalb des normalen Entwicklungsflusses. Ein Template ist ein Artefakt, das gebaut und gepflegt werden muss. Ändert sich eine Anforderung, wird nicht der Anwendungscode angepasst, sondern das Template neu gebaut. Wer diesen Aufwand scheut, hängt dauerhaft von dem ab, was im Standard-Template enthalten ist, und kann das aus dem vorliegenden Material heraus nicht überprüfen.
Bemerkenswert ist die Arbeitsteilung: Dieses Repository behält genau das, was zum Bauen der Sandbox-Umgebung nötig ist, und gibt die Client-Logik ab. Diese Trennung ist konsistent, sie verschiebt aber die Verantwortung für das Laufzeit-Image in ein Repository, dessen Struktur der Anwender erst verstehen muss.
Der Vergleich: Jupyter direkt betreiben
Die naheliegende Alternative ist ein selbst betriebener Jupyter-Kernel, etwa in einem Container oder einem JupyterHub. Der Unterschied liegt nicht in der Ausführungsumgebung, sondern in der Zuständigkeit. Bei einem eigenen Kernel kontrolliert man das Image, die Netzwerkregeln, die Persistenz und die Skalierung vollständig. Man bezahlt dafür mit Betriebsarbeit: Container-Orchestrierung, Isolation zwischen Nutzern, Aufräumen verwaister Kernel, Absicherung des Netzwerkzugriffs.
Das SDK nimmt einem diesen Teil ab und verlangt im Gegenzug einen Account und einen API-Key. Die API selbst ist bewusst schmal gehalten: create, run_code, text. Wer mehr Kontrolle über das Innenleben braucht, zum Beispiel eigene Kernel-Argumente, Mounts oder eine bestimmte Python-Version, muss diesen Weg über den Template-Guide gehen und nicht über SDK-Parameter. Umgekehrt gilt: Ein Team, das bereits JupyterHub betreibt und dessen Betriebsrisiko kennt, gewinnt durch den Wechsel weniger, als die Kürze des Beispiels vermuten lässt. Die Entscheidung hängt an der Frage, ob man die Isolation selbst bauen will oder ob man sie einkauft.
Wartung, Versionen und die Lizenz
Die Versionsstände sind ein Punkt, den man beim Einbinden einplanen sollte. Die JS- und Python-Pakete werden unabhängig voneinander veröffentlicht, wie die Releases 2.7.1 und 2.9.1 am selben Tag zeigen. Ein gemeinsames Versionsschema gibt es nicht. Wer in einem Projekt beide Sprachen verwendet, muss zwei Upgrade-Pfade pflegen und darf nicht annehmen, dass eine Erhöhung auf der einen Seite eine entsprechende Änderung auf der anderen bedeutet.
Die Angabe Apache-2.0 im Repository bezieht sich auf den hier liegenden Inhalt, also Template und Chart-Data-Extractor. Für die SDK-Pakete, die inzwischen im Monorepo liegen, ist die Lizenz aus dem vorliegenden Material nicht ablesbar. Wer die Pakete kommerziell einsetzt, sollte die Lizenzangabe der veröffentlichten npm- und PyPI-Pakete selbst prüfen, statt sie aus diesem Repository abzuleiten. Das ist keine Rechtsberatung, sondern der Hinweis auf eine offene Stelle in den verfügbaren Informationen.
Der Wartungsaufwand liegt damit an zwei Stellen: beim eigenen Template, das bei geänderten Anforderungen neu gebaut werden muss, und bei den beiden SDK-Abhängigkeiten, die getrennt aktualisiert werden. Beides ist überschaubar, aber es ist Aufwand, der in der Planung auftauchen sollte und nicht erst beim ersten fehlgeschlagenen Build.
Redaktionelles Fazit
Wer KI-generierten Python-Code ausführen muss und dafür keine eigene Container-Infrastruktur betreiben will, findet hier ein schlankes SDK mit klarer Trennung zwischen Sandbox und Laufzeit. Wer den SDK-Quellcode lesen, patchen oder forken will, ist im falschen Repository: Er muss ins E2B-Monorepo unter packages/code-interpreter-python und packages/code-interpreter-js. Vor dem ersten Einsatz sollte man prüfen, ob die eigene Umgebung einen externen Cloud-Dienst mit API-Key zulässt, und ob die Standard-Templates die benötigten Pakete enthalten oder ob ein eigener Build über den Template-Guide nötig wird.
Community-Notizen