Sandboxes for AI agents, on our servers or yours

A Triton sandbox is a Linux microVM with its own kernel, started on demand for code your agent writes. Set a lifetime and a deadline action: delete, stop, or pause where enabled. It runs next to your VMs on the same private network, and the same software installs inside your own perimeter.

Request access Read the sandbox docs

from triton_sandbox import Sandbox sbx = Sandbox.create(timeout=3600, package="sandbox-4g")print(sbx.commands.run("uname -a").stdout)sbx.kill()

$ tritonctl sandbox create --name dev \--package sandbox-4g --ttl 1h$ tritonctl sandbox exec dev -- python agent_task.py$ tritonctl sandbox snapshot create dev --name ready$ tritonctl sandbox fork dev --count 5 \--from-snapshot ready$ tritonctl sandbox delete -y dev

Known problems you can hand a sandbox today

If you are not sure what a sandbox is for, start with one of these.

Run the code your coding agent writes

Agent-written code should not run on a laptop or a shared build host. Give each task its own sandbox, allow it to reach your code host, clone the repository, run the task and delete the sandbox.

$ tritonctl sandbox create --name fix-123 --package sandbox-4g \--ttl 2h --allow-out <git-host-range>$ tritonctl sandbox exec fix-123 -- git clone <repo-url> /work/app$ tritonctl sandbox exec fix-123 --cwd /work/app -- python agent_task.py$ tritonctl sandbox delete -y fix-123

A clean machine for every CI job or pull request
Build disposable CI environments through the CLI or API. Every job starts from the same state. Today this works best on servers you own, next to your caches and internal services.
$ tritonctl sandbox exec pr-481 --cwd /work/app -- make test
Let customers run code in your product safely
When a user asks your product to run code, it runs in a sandbox, not on your app servers. Each user gets their own, with a time limit.
sbx = Sandbox.create(template="code-interpreter", timeout=600)
with the SDK

Analyze an uploaded file with Python

Put the file in a sandbox, run pandas on it, and read the result back. Nothing touches your own servers.

$ tritonctl sandbox create --name analysis --template code-interpreter \--package sandbox-4g --ttl 1h$ tritonctl sandbox fs put analysis ./data.csv /work/data.csv$ tritonctl sandbox exec analysis -- python3 -c "import pandas as pd; df = pd.read_csv('/work/data.csv'); print(df.describe())"$ tritonctl sandbox delete -y analysis

Parallel eval or RL rollouts from one snapshot
Set the environment up once, snapshot it, and fork a copy for every run. Each copy starts from the same state and is thrown away after.
$ tritonctl sandbox fork env --count 20 --from-snapshot ready
A disposable machine per support ticket
Reproduce a customer's problem on a fresh machine and hand the shell to whoever picks up the ticket. Set a lifetime and a deadline action: delete, stop, or pause where enabled.
$ tritonctl sandbox create --name ticket-8812 --package sandbox-4g --ttl 4h

Browser and desktop agents are on the roadmap.

How it works

Create. Pick a size and a lifetime, and choose a deadline action.
Run. Exec commands, stream output, move files in and out, open a shell or an SSH session.
Snapshot and fork. Save a ready environment once, then fork it into parallel copies for each attempt.
Finish. Delete the sandbox, or let the deadline action run.

Sizes are packages: sandbox-2g, sandbox-4g and sandbox-8g.

shell

$ tritonctl sandbox create --name dev \--package sandbox-4g --ttl 1h$ tritonctl sandbox exec dev -- python agent_task.py$ tritonctl sandbox snapshot create dev --name ready$ tritonctl sandbox fork dev --count 5 \--from-snapshot ready$ tritonctl sandbox delete -y dev

Snapshot and fork

Save a ready environment once, then fork it into parallel copies for each attempt.

devsbx-7f2a91

snapshot create

readysnap-3c0e12

fork --count 5

dev-1
dev-2
dev-3
dev-4
dev-5

The console today

The console lists your sandboxes and opens each one with a terminal, processes, logs and snapshots.

One running sandbox: its configuration, its deadline and the forks made from it.Scroll sideways to see the whole screen.

Control and isolation

Each sandbox has its own Linux kernel and a hardware virtualization boundary separating it from the host and other tenants.
Outbound access is denied by default. Allow destinations per sandbox by address range.
Place sandboxes alongside your VMs and explicitly allow access to services on their subnet.
Set a lifetime and a deadline action: delete, stop, or pause where enabled.

Where it runs

Choose where agent code runs: our cloud or servers you own, with one control plane for sandboxes, VMs and private networking.

Triton Cloud, hosted
Available
Servers you own
Available
Keep agent execution, stored credentials and working data on hardware you control. You choose which external services agents can reach. How it installs on your servers

Who it is for

Teams who need agents to run code somewhere they control. Most of the people we talk to fit one of four shapes:

Platform and security teams in regulated or sovereignty-sensitive companies who want sandboxes they can run on their own servers, next to the systems the agents work on.
RL and eval teams who need many short-lived copies of one environment, reset on every run.
Platform engineers giving each ticket or pull request its own clean environment for a coding agent.
Agent startups building code execution into a product. Public SDK packages come first; tell us if you want them early.

Price

$0.1656an hour

for 2 vCPU and 4 GB

$0.0504 per vCPU-hour
$0.0162 per GB-hour

A sandbox bills from create until it is deleted or its timer ends, busy or idle.

Request access

How should I start

Start from a template. Use the built-in base or code-interpreter template, or build your own from a container image.
$ tritonctl sandbox template build py312 --image docker.io/library/python:3.12-slim --follow
Run one task. Create a sandbox from that template, run the task, read the output, delete it.
$ tritonctl sandbox create --name t1 --template py312 --package sandbox-4g --ttl 1h
Wire it into what you already run. Call the SDK from your agent loop or point one CI job at it.

What exists this week

Sandboxes are created, run, snapshotted, forked and deleted through the API and tritonctl.

Sandbox usage is invoiced monthly.

Questions

What is a sandbox, exactly?

A Linux microVM, not a container. Each sandbox has its own Linux kernel and a hardware virtualization boundary separating it from the host and other tenants.

How do I start one?

With tritonctl or the API.

Can I run it in my own data center?

Yes, as a design partner. The same control plane installs on your servers. See self-hosted sandboxes.

What does it cost?

$0.1656 an hour for 2 vCPU and 4 GB, invoiced monthly. See pricing.

Can I control what a sandbox reaches on the network?

Outbound access is denied by default. Allow destinations per sandbox by address range. Place sandboxes alongside your VMs and explicitly allow access to services on their subnet.

How fast does it start?

We will publish a number with the method once we have run an end-to-end benchmark.

Tell us what you are running

Request access now, or tell us what you are running and a person replies within two business days.

Request access Talk to us