Code Interpreter SDK

Executes arbitrary Python code in a containerized, isolated sandbox environment that prevents code from accessing the host system or other sandboxes. Uses cloud-hosted microVMs or containers with resource limits (CPU, memory, disk) and automatic cleanup, enabling safe execution of untrusted or user-generated code without security risks to the parent application.

Extends sandboxed execution beyond Python to support JavaScript/Node.js, Bash, and other languages by provisioning language-specific runtime environments within the sandbox. Each language gets its own pre-configured interpreter with common libraries and package managers (npm, pip, apt) available, enabling polyglot code execution in a single API call.

Provides official SDKs for Python, JavaScript/TypeScript, and other languages that wrap the underlying HTTP/gRPC API with language-native abstractions. SDKs handle authentication, error handling, request serialization, and streaming, providing a developer-friendly interface that feels native to each language while maintaining consistent behavior across SDKs.

Captures and reports execution errors including syntax errors, runtime exceptions, timeouts, and resource limit violations with detailed error messages and stack traces. Errors are returned to the caller with structured metadata enabling programmatic error handling and recovery strategies (e.g., retry with different parameters, fallback execution).

Provides a mounted filesystem within the sandbox where code can read, write, and manipulate files using standard language APIs (open(), fs.readFile(), etc.). Files are isolated per sandbox instance and can be uploaded before execution or generated during execution, with support for directory traversal and file streaming to handle large datasets.

Streams stdout/stderr output in real-time as code executes, enabling interactive feedback loops where the calling application can monitor progress, capture intermediate results, or terminate execution early. Uses WebSocket or HTTP streaming to deliver output chunks as they are generated, rather than buffering until completion.

Allows passing environment variables and secrets into the sandbox at execution time, with support for masking sensitive values in logs and output. Variables are injected into the process environment before code execution, making them accessible via standard language APIs (os.environ in Python, process.env in Node.js) without exposing them in code or logs.

Enforces hard limits on execution time, CPU usage, memory consumption, and disk I/O to prevent resource exhaustion and runaway processes. Limits are configured per execution or per sandbox instance and are enforced by the underlying container runtime, with automatic termination of processes that exceed thresholds.

Manages sandbox instances with explicit lifecycle: creation, reuse across multiple executions, and termination. A single sandbox session can execute multiple code snippets sequentially, with state (variables, imports, file system) persisting between executions unless explicitly cleared. Sessions are identified by unique IDs and can be resumed or terminated via API calls.

Allows users to provide custom Docker images as the base for sandbox instances, enabling installation of arbitrary dependencies, system libraries, or specialized tools not available in default images. Custom images are built once and cached, then instantiated as sandboxes with the same isolation and resource limits as default images.

Manages outbound network access from sandboxes with configurable allowlisting or blocklisting of domains/IPs. Code within the sandbox can make HTTP requests to allowed endpoints using standard libraries (requests in Python, fetch in Node.js), with automatic handling of SSL/TLS certificates and proxy configuration. Inbound network access is disabled by default.

Captures detailed metadata about each code execution including runtime duration, CPU/memory/disk usage, exit code, and resource limit violations. Metrics are collected by the container runtime and returned to the caller, enabling performance analysis, cost tracking, and debugging. Metrics are available both during execution (streaming) and after completion.