The analyst asked the assistant for a chart of last month's signups and got back a block of Python with a polite note: run this and the chart will appear. Somebody pasted it into a notebook, installed a missing library, fixed a file path and finally saw the picture, long after the question had gone cold.
The assistant could write the code; it had nowhere to run it. An agent sandbox is that place: an isolated machine, created by API, where an AI agent runs the code it writes, installs what it needs, works on files and hands back the result instead of the script. Solari runs AI Sandboxes from the same account as its cloud browsers and desktops, and they are easiest to understand through the jobs agents do inside them. Here is what those jobs look like on Solari, and which feature each one leans on.
Analysis an Agent Can Finish Itself
The opener's chart is the most common sandbox job, so it comes first. A sandbox separates running programs from everything around them, which is what makes it safe to execute whatever the model wrote. On Solari, runCode runs Python and remembers variables and imports between calls, much like a read–eval–print loop, so the agent can load data in a step and plot it in the next.
The sketch below follows the pattern in the sandboxes docs: set state, plot, take the image.
Every matplotlib figure comes back as a base64 PNG, alongside a structured view of the chart type, title, axes and series. That view can be empty on the base template, so code checks charts.length and falls back to the image.
Analysis reads data; the next job changes code.
Coding Agents That Commit Their Own Work
A coding agent goes a step further, because it edits a repository and has to publish the result. Solari wraps Git in a git namespace: clone, status, add, commit, push and log return typed results, and they run without a shell, so there is nothing to escape or inject.
Credentials are the part worth knowing. A personal access token passed to push or clone travels as environment variables of that single command and is read back by a credential helper bound to the remote's origin. It never lands in the URL, in .git/config or in the process arguments.
Tests run through commands.run, which returns the exit code with stdout and stderr. A command that hits its 10-minute default deadline returns timedOut: true instead of throwing, so the agent checks that flag before trusting the exit code.
Once the tests pass, somebody usually wants to see the app.
Previewing an App Before Anyone Merges It
A preview turns the coding job into something a reviewer can click. previewUrl(port) returns a public URL for whatever the sandbox serves on that port, signed with a token that lasts an hour. Anyone holding the URL can use it until it expires, which is how a bearer token works, so it belongs in a review thread and not in a public log.
A request that arrives before the dev server starts answers 425 Too Early: the sandbox is reachable but nothing is listening yet, and polling until the app answers is the fix.
Previews end quickly; some jobs run far longer.
Long Jobs That Outlive the Client
Long jobs come next, because the agent's own process may restart before the work finishes. A background execution keeps the process, its buffered output and its exit status alive after the client disconnects, and the agent can poll, stream or kill it later. Up to 16 run at once per sandbox.
Idle time is handled by the lifecycle: a sandbox pauses after its idle timeout by default instead of being killed, so a job waiting overnight picks up where it stopped. Slow setup is handled by snapshots, installed once and copied into ready machines, as the snapshots docs describe.
Every job so far trusts its code at least a little; the last does not.
Code Nobody Has Reviewed
Some code arrives from places nobody checked. A model that reads a web page can pick up planted instructions, the pattern OWASP calls prompt injection, and then run what it was told. For that code Solari offers the hardened tier: a microVM of its own, like the default dedicated tier, with all outbound network blocked.
The figure maps each job above to the feature and tier it needs.
Dedicated covers most jobs because it is a full microVM with files, streaming and Git. Shared is cheaper and starts faster, but it runs only commands and runCode, which suits quick analysis. On every tier, a sandbox id and its control URLs let whoever holds them run commands as root, so they stay out of logs and tickets.
That leaves the question every job ends on, which is the bill.
What These Jobs Cost
Solari bills a sandbox for the CPU and memory it runs with, so sizing each sandbox to its job is the main lever on cost. A 4 vCPU, 16 GB sandbox runs at $0.221 per hour on the Professional plan.
Solari's Free plan includes $3 of monthly credits, and at a zero balance new sandboxes stop launching rather than running up an overage. Snapshots add storage at $0.05 per GB-month after the first 10 GB.
Choosing the Right Setup
The job decides the setup: runCode for analysis, Git and files on a dedicated sandbox for coding agents, a signed preview for review, background executions and pause for long work, and the hardened tier for unreviewed code. When a job needs a screen rather than a shell, a Solari desktop shares the same lifecycle. Isolation and pause get a full treatment in What Is an AI Agent Sandbox, and the Solari introduction shows a sandbox and a browser paired for a single agent.
Get Started With Solari
Start with the job from the opener: create a dedicated sandbox, give the agent the data and let runCode return the chart instead of the script. Solari sandboxes are ready in 90 ms and run almost 3x cheaper than E2B per sandbox hour on the pricing comparison. Create a free Solari account and the Free plan's credits cover the first sandbox.
