The invoice review turned up a line nobody could explain: sandbox hours logged across a long weekend when no agent had been working. The machines had been created for a batch of data-cleaning jobs, finished on Friday afternoon and then sat there, sized for the heaviest task, waiting for a call that never came.
A cloud sandbox is an isolated Linux machine an agent creates by API to run the code it writes, and its bill follows two choices: how big the machine is and what happens when it goes quiet. Solari AI Sandboxes are billed by vCPUs and memory, run from the same account as Solari's browsers and desktops, and carry an idle rule set at create time. This guide walks through sizing, idle rules and plan choice, in the order they show up on the bill.
What a Cloud Sandbox Is Billed For
Before sizing anything, it helps to know what the meter counts. Solari bills a sandbox by its size, a rate per vCPU-hour plus a rate per GB-hour of memory, and on the Professional plan Solari charges $0.0245 per vCPU-hour and $0.0077 per GB-hour (Solari pricing).
The figure shows how the vCPU rate falls as the plan grows.
Because both rates scale with the machine, a sandbox twice the size costs twice as much for every hour it runs. A 4 vCPU, 16 GB sandbox on Professional comes to $0.221 an hour on the pricing page estimator, which makes size the first decision worth getting right.
How to Size a Sandbox
Size on Solari is a create-time decision, and the limits are strict. On Solari sandboxes, cpu takes 1 to 8 vCPUs and memMb up to 16 GB, with defaults of 2 vCPUs and 2 GB. A request above those limits is rejected with a 400 rather than quietly reduced, and the size sticks across snapshot, pause and resume.
The shared tier changes the arithmetic. A shared sandbox runs as a process tree inside a VM shared only with the organization's other shared sandboxes, separated by namespaces and a cgroup, with cpu capped at 4 and memory at 2048 MB, defaulting to 512 MB.
Memory is the trap there. The host enforces the cap, but /proc/meminfo inside the sandbox reports the whole VM, so a worker pool sized to "most of the available memory" overshoots and the process is killed for running out of memory without warning. Set pool sizes and heap limits as fixed numbers.
Once the machine is the right size, the next cost is the time it spends doing nothing.
Idle Rules: Pause, Kill or Park
The weekend in the opener was an idle-rule problem, not a sizing one. Every Solari sandbox carries an idle timeout, idleTimeoutMs, and a lifecycle rule for when it passes: the default, onTimeout: "pause", saves the machine's state so the next connect() picks up where it left off, while "kill" shuts it down for good.
Sandboxes share their lifecycle with Solari VMs, so the same cost rule applies to both. A paused machine stops counting against the plan's limit on running machines, which means a sandbox that pauses on idle frees its slot instead of holding it over a weekend.
Short waits get a lighter tool. parkAfterMs freezes the CPUs while the slot and connections stay held, so a model call wakes the machine with nothing to restore, but a parked machine still counts against the plan. Pair it with hibernateAfterParkedMs, which escalates a long park to a full pause; 15 minutes is a sensible starting point. On the shared tier a manual pause is refused, so park and the idle policy do that job there.
With size and idle rules set, the remaining choice is the plan the hours run under.
Choosing a Plan for Sandbox Hours
The plan sets both the rate and how many sandboxes run at once, as the figure shows.
Each self-serve fee comes back as credits of the same value, spent from one balance across browsers, sandboxes and desktops. Credits refill monthly and do not roll over, and at a zero balance new sandboxes stop launching, so there is no end-of-month overage charge.
Stored snapshots cost $0.05 per GB-month after the first 10 GB across the organization, and deleting one stops its charges the same day. Those levers are enough to write a rule for the next batch of jobs.
Choosing the Right Setup
Start every sandbox at the default size and move up only when a job measures slow, and on the shared tier set memory-hungry pools by hand. Give every sandbox an idle rule that pauses it, park it during short waits, and let hibernation free the slot when a wait runs long. Then pick the plan whose concurrency matches the fleet, and prune old snapshots as part of the same routine.
Get Started With Solari
Start with the batch job from the opener: create a sandbox at the default size with a pause rule, run the jobs, and watch it free its slot when the work stops. Solari sandboxes are ready in 90 ms, and over a sandbox's full lifecycle Solari is about 1.3x faster than E2B and almost 3x cheaper per sandbox hour. Create a free Solari account and the Free plan's monthly credits cover the first sandbox.
