Warm-operation results
Lower is better.Comparison design
Modal optimized runs the controlling code in a Modal Function and requests the same region for the desktop Sandbox. It also uses the other documented optimizations. Modal simple calls the publicComputerSandbox API from the benchmark runner. It uses standard resources, default input pacing, and the attested-tunnel daemon path.
The remaining paths, E2B Computer Use, Daytona Computer Use, and Tzafon Computer Use, call each provider directly from the benchmark runner and use their recorded computer-use SDK defaults.
The benchmark applies the same six logical tasks to each path. Each result cell contains 30 successful samples. The path configurations, screenshot formats, and request shapes differ. The results compare these recorded paths. They do not rank provider infrastructure in isolation or show the fastest possible configuration for every provider.
All timers include transport, authentication, request handling, operation execution, and response collection.
Comparison limits
The shared region request does not prove the same host or availability zone. Screenshot formats differ. Tzafon returned a 1280 by 720 JPEG. The other paths returned a 1024 by 768 PNG. The four-click request shape differs. Modal optimized, Modal simple, and Tzafon used one request. Daytona used four SDK calls. E2B used four SDK calls through eight transport calls. The Modal optimized path and provider-default paths also differ in caller placement and configuration. Treat the ratios as path comparisons. Do not use them as isolated provider rankings. Native async provider APIs became available after these measurements. The July 30 report measured the synchronous colocated path only.Sources
- Current July 30 report
- Modal optimized artifact
- Provider comparison artifact
- Archived July 26 report
The July 26 report is archived. Use it for historical lifecycle and first-visual-change evidence, not current provider figures.

