Skip to main content

​
Agent Sandbox Costs

Sandbox cost is a function of how long you hold resources, not how much work you do. The levers below are ordered by how much they typically save.

​
1. Timeout is the main lever

timeout_seconds is the ceiling on what a run can cost. Set it to slightly more than the work needs, not to a comfortable round number.
A hung agent bills for the full timeout. The default is generous enough that a stuck loop is expensive — this is the single most common source of surprise cost.

​
2. Stop explicitly, don’t wait for the timeout

Stop in a finally block so a thrown error doesn’t leave the sandbox running to its ceiling:

​
3. Size to the workload

cpus and memory should match what the agent actually needs. A commerce agent doing reads and a few writes is not a compute-heavy job — oversizing pays for headroom that goes unused for the whole run.

​
4. Batch deliberately

Splitting a large workflow into smaller runs bounds the blast radius of a failure too: a run that dies takes one chunk’s spend with it rather than the whole job’s.

​
Keep the cost visible

Stream and store execution output. Two reasons: an audit trail for what the agent did, and the evidence for why a run cost what it did.
Use --json for agent-driven commands. Beyond being parseable, it’s more compact than prose output — which matters when the output is going back into a model’s context and being paid for by the token.

​
Guardrails that also save money

--apply prevents an exploring agent from doing expensive write work by accident. Scoping its tools narrows what it can attempt at all. A run that can’t call the manufacturing domain won’t spend time deciding whether to.