E2B Code Interpreter: Running AI-Generated Python and TypeScript in Cloud Sandboxes

What E2B Code Interpreter actually solves, and for whom

An LLM that writes Python cannot run it. The model emits a string; something else has to execute it and hand the stdout, the result value and any errors back so the model can continue. Doing that inside your own process means model-authored code shares your filesystem, your environment variables and your network. E2B Code Interpreter is aimed at that gap. The README describes E2B as "open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud", and the repository supplies the sandbox template plus a chart data extractor. The audience is narrow and specific: developers building agents, data-analysis assistants or notebook-style tools in Python or TypeScript who need a stateful execution environment they can call from application code. It is not a CLI for running scripts, and it is not a Jupyter replacement for humans. The unit of work is a sandbox started by your app, driven by runCode calls, and torn down when you are done.

How a sandbox session works: create, runCode, read the result

The mechanism visible in the README is a stateful remote session. Sandbox.create() starts an isolated environment and returns a handle. runCode sends a code string to that environment and returns an execution object whose text field carries the textual output. State persists between calls, which the README demonstrates by assigning x = 1 in one call and evaluating x+=1; x in the next, printing 2. That persistence is the whole point: a model can build up variables, import packages and iterate across turns without resending everything. The Python example uses the sandbox as a context manager, so the block's exit closes the session. The TypeScript example holds the handle in a variable and awaits each call. The repository itself keeps the template that defines what runs inside the sandbox, and a chart_data_extractor directory. The SDK sources are no longer here; the README states they moved to 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. Read that as a maintenance boundary: bugs in the client libraries belong in the monorepo, not in this repo's issue tracker.

Installing the SDK and running your first code

The README gives a five-step path. Pick the package for your language. The JavaScript and TypeScript package is @e2b/code-interpreter; the Python package is e2b-code-interpreter.

npm i @e2b/code-interpreter

pip install e2b-code-interpreter

Next you need an API key. The README directs you to sign up at e2b.dev, get the key from the dashboard keys tab, and set it as an environment variable. The value is prefixed with e2b_, and the README shows the placeholder E2B_API_KEY=e2b_***. Do not commit that value.

E2B_API_KEY=e2b_***

With the key in the environment, the Python example creates a sandbox, runs one statement, then runs a second statement that depends on the first. The comment in the README says the printed output is 2.

from e2b_code_interpreter import Sandbox

with Sandbox.create() as sandbox:
    sandbox.run_code("x = 1")
    execution = sandbox.run_code("x+=1; x")
    print(execution.text)  # outputs 2

The TypeScript version is the same flow with await. If the printed value is not 2, the session did not persist state or the API key was rejected, and the execution object is where you look for the error text.

import { Sandbox } from '@e2b/code-interpreter'

const sbx = await Sandbox.create()
await sbx.runCode('x = 1')

const execution = await sbx.runCode('x+=1; x')
console.log(execution.text)  // outputs 2

For extra packages or a different runtime, the README points to the template guide at template/README.md, which walks through creating, building and using a custom template, including how the production code-interpreter-v1 template is built. The Makefile in the repository root shows how the team runs a local template server during development: start-template-server builds an image from template/build_docker.py and runs it with E2B_LOCAL=true on port 49999. That is the local path, and it is the only piece of the stack you can exercise without the hosted service.

make start-template-server

Where the hosted model bites: keys, sessions and the missing SDK source

The first constraint is that the default path is not local. Sandbox.create() talks to E2B's cloud service, and the README's setup requires an account and an API key before the first line of example code runs. If your deployment cannot reach an external service, or your data cannot leave your network, the default examples do not apply to you. The Makefile shows a local template server on port 49999 with E2B_LOCAL=true, but the README does not document how a client SDK is pointed at that server, so you are reading the Makefile and the template guide rather than a documented offline mode. Treat local execution as a development convenience to investigate, not a supported production topology.

The second constraint is session lifetime. The examples are short-lived and the README shows no reconnection, keepalive or resume logic. Nothing in the README documents what happens when a sandbox is reclaimed between turns, and it does not document rollback. Anyone building a long chat session has to decide what to do when the next runCode call fails because the environment is gone, and that decision is not answered here. The related search data around "code interpreter session expired" reflects how common that failure class is in this product category.

The third constraint is where the code lives. If you wanted to read the Python SDK implementation to understand result parsing or error surfaces, this repository will not give it to you. The README says the SDK sources now live in the E2B monorepo under packages/code-interpreter-js and packages/code-interpreter-python. What remains here is the template and the chart data extractor, so the surface you debug against and the code you clone are in different places.

E2B versus a self-hosted Jupyter kernel

The obvious alternative is running a Jupyter kernel yourself, either in-process with something like jupyter_client or as a container you manage. The difference in approach is who owns isolation and lifecycle. With a self-hosted kernel you own the container image, the network policy, the resource limits and the cleanup, and you get an execution loop that never leaves your infrastructure. E2B takes that ownership and exposes it as a create-and-runCode API with an API key. The trade is control for operational work: you give up the ability to inspect the runtime directly and to run entirely offline, and in exchange you do not build the sandboxing, the image pipeline or the teardown. The repository's template directory is the seam between the two models. Because the template is in the repository and the README points to template/README.md for building a custom one, you can add packages and change the runtime while still using the hosted control plane. You cannot, from this repository alone, replace the control plane.

Licence, releases and what upgrades cost you

The repository is Apache-2.0. That covers the template and the chart data extractor that live here; it does not by itself tell you the terms of the hosted sandbox service or of the SDK packages published to npm and PyPI, which are distributed from the monorepo. Check the licence shipped with the package you install rather than assuming it matches this repository. This is a description of what the files state, not legal advice.

On releases, the recent tags are split by language: @e2b/[email protected] and @e2b/[email protected], both dated 2026-08-13, following @e2b/[email protected] on 2026-07-23. The two version lines move independently, so a JavaScript upgrade and a Python upgrade are separate decisions with separate changelogs. The root package.json is private and exists to drive the workspace: scripts for version and publish run through changesets, lint and format run recursively across packages, and the pinned package manager is [email protected] with an engines range of >=10.16.0 <11. If you contribute to the template, expect to use pnpm at that version. The last push to this repository was on 2026-09-07, so the template and extractor are still receiving changes even though the SDKs moved elsewhere.

Editorial conclusion

Use E2B Code Interpreter if you are building an AI app that must execute model-generated Python and you accept a hosted sandbox with an API key. Do not use it if you need a fully local, offline execution path or you want to read the SDK source in this repository, since the README states the SDK sources now live in the E2B monorepo under packages/code-interpreter-js and packages/code-interpreter-python. Before adopting, verify what the template directory builds, whether your custom packages are covered, and how you handle a session that expires mid-conversation.

Frequently asked questions

Official sources

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