Sandboxes · Agents

Let the agent work inside the machine.

Your app provisions the sandbox, sets the limits, and collects the patch. The loop stays inside.

Start Read the docs

Your app owns the product. The sandbox owns the machine.

Inside the machine

A shell and the files the agent edits
Dependencies installed for that session
The process environment, including a model key when you pass one

In your application

Provisioning, time limits, and teardown
The network policy
Streaming logs and collecting the files, the test log, and the patch

Edit. Test. Fix. Leave with more than stdout.

The agent edits, tests, and fixes inside the sandbox. Your application collects the files and the test log at the end.

Put the project in the machine. The agent edits, runs the tests, and fixes the code there. When the loop stops, your application takes the files, the test log, and a patch it assembled from those files.

Sandboxes does not provide a diff() method. The patch is something your code collects.

Keep the project in the machine while the agent iterates.

You do not have to copy the tree in on every turn. Three patterns already fit the session:

A writable volume that stays attached while the loop runs
The project baked into the image layer you started from
A git clone inside the sandbox, run as an ordinary command

Clone is a command you run. It is not a separate import API.

The model key reaches the process. It does not travel in the command line.

Pass the key in the process environment. It is not an argument of the command.

You bring the model and the loop.

Sphere Engine Sandboxes is the machine. It does not plan tasks, store prompts, or ship an agent runtime. LangGraph, your own harness, or a coding agent you already run — that code stays yours. It calls this API to get a shell and a filesystem.

Put your loop in a machine you provision.

Create an account and call the SDK. If volume or policy needs a conversation, talk to us.

Start Read the docs

Talk to us