e2b-dev/code-interpreter: a sandbox SDK for running LLM-generated code, and what moved out of the repo

The problem: model-written code needs somewhere to run that is not your server

An LLM that emits Python is only half a feature. The other half is execution, and that execution is hostile input by default. The README frames E2B as "open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud," with the JavaScript and Python SDKs as the control surface. The audience is narrow and specific: developers wiring a code interpreter into an AI app, whether the model behind it is OpenAI, Anthropic, Cohere or a local one, since the topics list names all of those. The repository itself is no longer the SDK. The README states plainly that the @e2b/code-interpreter and e2b-code-interpreter sources now live in the E2B monorepo under packages/code-interpreter-js and packages/code-interpreter-python, and that this repository keeps the sandbox template and the chart data extractor. That split matters before you clone anything: if you want to read or patch the client code, this is the wrong repository. If you want the image that the sandbox boots into, it is the right one.

How execution actually flows: Sandbox.create, runCode, and a text result

The mechanism visible in the README is a remote sandbox object with a code-execution method. In Python you write `with Sandbox.create() as sandbox:` and then call `sandbox.run_code("x = 1")` followed by `sandbox.run_code("x+=1; x")`, printing `execution.text`, which the comment says outputs 2. Two things follow from that example. First, the sandbox holds state between run_code calls, so it behaves like a live kernel rather than a one-shot script runner; the second call sees the x defined by the first. Second, the return value is an execution object with a text field, not a raw stdout string, which implies the SDK parses the result into structured fields. The JavaScript example is the same shape: `await Sandbox.create()`, `await sbx.runCode('x = 1')`, then `sbx.runCode('x+=1; x')` and `execution.text`. The topics list includes jupyter and jupyter-notebook, and the repository keeps a chart data extractor, which is consistent with a notebook-style runtime where rich outputs exist alongside plain text. The README does not document the full execution object, so the fields beyond text are something you would confirm in the docs rather than here. The sandbox is created in the cloud, not on your machine, and the client is a thin control channel to it.

Getting a sandbox running: two installs, one API key, five lines

The README gives the whole path. Install with `npm i @e2b/code-interpreter` or `pip install e2b-code-interpreter`. Sign up at e2b.dev, take an API key from the dashboard, and set `E2B_API_KEY=e2b_***` as an environment variable. Then the Python snippet above runs as-is. Note the package-name mismatch that trips people up: the PyPI distribution is e2b-code-interpreter, but the import is `from e2b_code_interpreter import Sandbox`. The npm package and the import name match. There is no self-hosted server to start, no Docker command in the README, and no local kernel to configure. The API key is the gate, which means the first thing your build pipeline needs is secret handling for E2B_API_KEY rather than a container runtime. If you need packages the default image lacks, the README points to /template/README.md for a step-by-step walkthrough of creating, building and using a custom template, and notes that the same guide covers building the production code-interpreter-v1 template. That is the documented extension path: change the image, not the client.

The template is the real customization surface, and it is a build step

Because the SDK sources have moved out, the part of this repository you can meaningfully fork is the sandbox template. The README's last section is explicit that extra packages or a different runtime are handled by building your own Code Interpreter sandbox template, with the guide in /template/README.md. That has a cost the README does not spell out: a custom template is an artifact you build and version, and every package your agent might import has to be decided in advance or installed at runtime inside the sandbox. The repository also keeps a chart data extractor, which suggests the template's output handling is opinionated about charts specifically, not about arbitrary binary outputs. If your application needs a language runtime other than Python, the README's phrase "a different runtime" is the only signal that this is supported; the mechanics are in the template guide, not in this README. Treat template design as a first-class engineering task rather than a one-line config change.

Where it is the wrong tool: hosted dependency, latency, and the missing failure semantics

The clearest limitation is structural. Sandboxes are created in E2B's cloud and authenticated with an E2B_API_KEY, so this is not an air-gapped or fully self-hosted execution path. If your threat model, procurement rules or data-residency requirements forbid sending generated code and its inputs to a third-party service, the README offers no alternative deployment described in this material. A second limitation is that the README never describes timeouts, resource ceilings, network egress rules inside the sandbox, or what happens to a sandbox when run_code raises. It shows a happy path only. For a component whose entire purpose is executing untrusted code, the absence of documented failure semantics in the README is a real gap, and you should read the docs before assuming defaults. Third, the round trip to a remote sandbox is not free compared with a local subprocess, and for a fixed, simple transformation you already trust, spawning a process or calling a function is cheaper and has no API key to rotate. The SDK is also split across repositories, so bug reports and patches for the client belong in the monorepo, not here. Filing against this repository for a client-side issue wastes a cycle.

Compared with running your own Jupyter kernel

The obvious alternative is standing up Jupyter kernels yourself, for example via jupyter_client or a container per session, and calling execute on them. The difference in approach is where isolation lives. With a self-managed kernel, you own the container image, the network policy, the process limits and the cleanup, and you get no vendor account; in exchange you own every failure mode, including orphaned kernels and escape attempts. E2B's model inverts that: the isolation is the product, the SDK is the control channel, and your operational surface shrinks to an API key and a template. The trade is control and data locality for less infrastructure to run. A second alternative is a plain subprocess with a timeout, which is fine when the code is generated by you rather than by a model and the blast radius is acceptable. The README's topics list jupyter and jupyter-notebook, so the project is not positioning itself against notebooks conceptually; it is positioning itself as the managed execution layer a notebook-style runtime implies. Pick based on whether you want to operate kernels or consume them.

Maintenance, versioning and the licence

The repository is active, not archived, with a last push in September 2026 and paired releases for the JS and Python packages (2.7.1 and 2.9.1 respectively at the time of writing). The two version numbers move independently, so pinning matters: a JS upgrade and a Python upgrade are separate decisions. The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant; it also requires that you preserve notices and state significant changes. That is a permission statement, not legal advice, and if you redistribute a modified template you should read the licence text and your own counsel's view rather than this summary. The practical maintenance cost sits in two places: keeping the SDK version current against the monorepo, and rebuilding your custom template when the packages inside it change. Neither is heavy, but the template is the piece that will drift silently, because nothing in your application code fails when a package inside the image goes stale.

Editorial conclusion

Adopt it if you are building an AI app that must execute model-written Python or JavaScript and you are willing to depend on E2B's hosted sandboxes and an E2B_API_KEY. Do not adopt it if you need fully self-hosted execution with no vendor account, or if your code paths are simple enough for a local subprocess. Before committing, verify two things in the current monorepo sources: whether runCode state persists across calls in your target SDK version, and whether your required packages fit the template you plan to build, since the README points to /template/README.md for custom images rather than promising a general-purpose runtime.

Official sources

1. e2b-dev/code-interpreter on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases