Less overhead.
More useful work.
A deliberately small execution runtime changes the economics of short-lived agent tasks. Here are the measurements—and the boundaries of what they prove.
One million sessions.
One measured fleet.
On 8 November 2026, Joulebox created and held one million concurrent sessions across 128 AWS Graviton c9g.2xlarge instances (1,024 vCPUs; 2,048 GiB fleet memory).
Fast at the median.
Measured at the tail.
The million-session run timed every Joulebox creation request. Percentiles describe the same workload and fleet.
Bars normalized to p99, not a cross-provider comparison.
Why tail latency matters
Agents issue many short tool calls. A runtime that starts quickly but stalls under bursts can still become a bottleneck.
These measurements capture creation latency at high concurrency. Real workloads also include compilation, task CPU, I/O, queuing, and orchestration.
Small by construction.
Joulebox's restricted runtime avoids general-purpose runtime facilities that carry ongoing resource and kernel-interface costs. The numbers below come from separate experiments and must not be added as if they were one benchmark.
Measure the work,
not just the container.
An earlier same-output Go example reported the following execution and memory measurements. This is a narrow program-level result, not a full application benchmark.
| Metric | Native Joulebox | Stock Go comparison | Interpretation |
|---|---|---|---|
| Example execution | 8.7 ms | 103 ms | ~11.8× lower measured time for this example |
| Example memory | 5.1 MiB | 56.4 MiB | ~11.1× lower measured footprint for this example |
| Runtime design | Restricted compiled guest | General-purpose Go runtime | Different supported capabilities and execution machinery |
Comparison is from an internal demonstration. Exact methodology and measurement boundaries should accompany any independently reproduced claim. Stock Go here is a benchmark reference, not a publicly available securely.run product mode.
Scale deserves context.
A published Modal million-sandbox experiment provides useful context, but the environments, resources, endpoints and timing methodology differ. These are separate published runs, not a controlled benchmark.
| Reported metric | Joulebox (8 Nov 2026) | Modal (22 Jun 2026) |
|---|---|---|
| Concurrent sessions / sandboxes | 1,000,000 | 1,000,000 |
| Time to reach one million | 3.39 s | 46 s |
| Median startup / creation | 4.43 ms | ~75 ms (estimated from chart) |
| p99 startup / creation | 34.84 ms | ~513 ms (estimated from chart) |
| Resource accounting | 1,024 fleet vCPUs; 2 TiB fleet RAM | Published dashboard's reserved resources; not equivalent to Joulebox fleet allocation |
| Endpoint | Session accepting commands | Worker assigned (as described in comparison analysis) |
Source: internal Joulebox and Modal at a Million analysis, 8 Nov 2026. External reference: Modal's published engineering blog (million-sandbox report, June 2026).
What is measured.
What isn't.
Million-session timing is about creating and holding sessions, not running one million compute-intensive programs.
Small-program comparisons include the specific program and toolchain used. Results vary by task and compilation path.
Host memory, per-session allocations, RSS/PSS and reservations measure different things. Do not interchange them.
Browser, server and LLM costs must be measured separately to estimate full-agent savings.
Workloads we want to benchmark next
- Idle and active browser contexts, including Chrome sharding.
- Identical agent steps with the same browser setup and different execution runtimes.
- CPU time, peak and proportional memory, latency percentiles, success rate, and idle cost.
Scope of support
Native Joulebox supports a restricted Go execution model and a supported Python translation subset. Unsupported code and dependencies require a different execution environment. The measured advantage does not automatically apply to those workloads.
Bring a real workload.
We'd rather benchmark your agent's actual execution path than quote a generic multiplier. Let's measure where time and memory go—and whether a smaller runtime helps.
Contact email is a deployment placeholder until configured.