Core concepts

Sandbox

A sandbox is a fast, isolated Linux environment created on demand. Each one runs your code in a container with the gVisor runtime, a stateful Python code-interpreter kernel, a workspace filesystem, and a shell.

Sandboxes are the unit you create, run code in, and tear down. They're cheap to start and isolated from each other and from the host.

Isolation

Untrusted code runs under gVisor (runsc) — a user-space kernel that intercepts syscalls, so model-generated code never talks directly to the host kernel. Combined with dropped Linux capabilities, no-new-privileges, and CPU / memory / PID limits, a sandbox can run genuinely untrusted code safely.

Lifecycle

• Create — a container boots and the executor becomes ready in ~1s.
• Run — execute code (stateful) or shell commands; the kernel keeps state between calls.
• Pause — stop the container: no CPU/RAM, but the whole filesystem is preserved. Resume later exactly as it was.
• Kill — destroy the sandbox and its filesystem.

Idle sandboxes are auto-reaped after a period of inactivity so abandoned ones don't pile up. See Sandbox lifecycle.

Region & data residency

Everything runs in AWS Mumbai (ap-south-1). Compute and data stay in India — that's the core guarantee.

Authentication

Requests authenticate with a bearer API key (ai2in_live_…). Keys are team-scoped and carry scopes (sandbox:create, sandbox:run, …). Manage them in the dashboard under API Keys.

Quotas

Each team has caps — concurrent sandboxes, monthly vCPU-hours, and an optional budget — enforced server-side. Hitting a hard cap returns 429. Metered compute is billed at ₹4.00/vCPU-hour + ₹1.00/GB-hour. See Pricing.

Templates

Sandboxes boot from an image. The default is a Python 3.12 code-interpreter image; you can build custom templates from a Dockerfile to pre-install packages.