Sandbox providers

• You need Australian or multi-region placement
• Cost per sandbox-hour matters more than SDK ergonomics
• You already run on Fly and can reuse the networking

Unbeatable price-per-isolation and the only mainstream Sydney region, paid for in a week of glue code.

• You want sandboxes, agent hosting and MCP from one vendor
• Latency-sensitive workloads where you can keep a pool warm
• You are comfortable betting on an early-stage platform

The 25 ms claim measures the wrong operation, and the broad platform is a lot to buy from a seed-stage company.

• Boot time is your headline metric and the code is your own
• You want an MCP server maintained by the vendor
• You can tolerate a fast-moving, now closed-source product surface

E2B's most credible ergonomics challenger with the best MCP story, but shared-kernel containers make it wrong for untrusted code.

• Running SWE-bench-style evaluation loops at scale
• Generating training data from reproducible environments
• You want a vendor whose roadmap targets agent researchers

Built around evaluation, not production traffic: the obvious pick if you measure an agent's pass rate nightly.

• The sandbox needs a GPU on a self-serve plan
• Your team is Python-first and already writes Modal functions
• One platform for batch ML and untrusted execution

Buy Modal for GPUs and Python ergonomics, not boot time; unmatched when the agent runs inference next to its code.

• An app-builder or code-runner inside a Vercel deployment
• Agent sessions that mostly wait on a model, where active-CPU billing pays off
• You need a per-sandbox egress allowlist without building it yourself

Now a broad, well-isolated product with active-CPU billing, held back only by a single US region.

• You want the category default with a real self-host escape hatch
• Your environments are already Dockerfiles
• Python code-interpreter workloads at steady volume

The safest default: complete SDKs, Dockerfile templates and an Apache licence, though no longer fastest and weak at hobby scale.

• You fork one prepared environment many times
• Long-lived per-user environments that hibernate between sessions
• You need processes and memory preserved, not just the disk

The best-engineered snapshot-and-fork here for branching workloads, now a component of Together AI rather than its own product.

• You already use Namespace for CI runners
• Build-cache-heavy environments that are slow to reconstruct
• You want infrastructure primitives rather than an agent SDK

Snapshotted microVMs with good caching but no agent SDK, worth a look mainly if your CI already runs here.

• Central policy control over what each agent can reach
• Enterprise teams that must govern agent identity and access
• You are already inside Incredibuild's SDLC platform

An enterprise governance pitch this rival's table cannot capture; verify from Incredibuild's own documentation before shortlisting.

• Building an AI app builder with live previews
• You want git hosting and custom domains bundled with execution
• JavaScript and TypeScript workloads only

Collapses four vendors into one for Lovable-shaped app builders, wrong shape for anything outside JavaScript.

• Long-lived SSH VMs on a predictable monthly bill
• You want root, apt and systemd rather than a constrained runtime
• You are prepared to verify the gaps a competitor's chart reports

A placeholder built from a rival's table: positive claims credited, omissions ignored, nothing measured.

• You want an agent you message rather than an API you call
• Multi-repo dispatch across long-running VMs
• You are already using box and want the harness on top

An agent harness with a VM attached, judged from an unverified vendor table with no fundamentals established.

• You want a VM that stays up rather than a sandbox that vanishes
• SSH, Docker and a real network stack matter more than an SDK
• You are willing to test the vendor's claims yourself before committing

A coherent long-lived-VM pitch, but a vendor self-assessment with no measured isolation, boot time or price.

• Human-in-the-loop agent sessions rather than autonomous fleets
• You need an Australian region and are already on GitHub
• Your environments are already defined as devcontainers

Excellent for a human, a bad substrate for an API creating hundreds of sandboxes.

• Compliance requires the workload inside your own VPC
• Sandboxes are long-lived per customer, not per request
• You also need databases, jobs and GPUs on one platform

Loses on boot time, wins on running inside your own cloud account and compliance boundary.

• Sustained volume where vendor margin exceeds an engineer's salary
• Hard data-residency or air-gap requirements
• You already operate bare metal and a scheduler

The honest baseline: identical isolation at a tenth the cost, minus the two engineer-years of orchestration.

• Your app already runs on Workers and Durable Objects
• You want code-level control over what the sandbox can reach
• Sandboxes are long-lived per user rather than created in bursts

An addressable sandbox object in your app, worth it on Workers but too slow to migrate to.

• Evaluating short TypeScript snippets behind an HTTP endpoint
• Cron and webhook glue an agent can write and deploy itself
• Zero infrastructure, and you can accept zero filesystem

The isolate benchmark: fastest and cheapest for a TypeScript snippet behind a URL, outgrown the moment you need `npm install`.

• Executing model-written expressions with the tightest possible default
• Multi-language interpreter tooling without maintaining images
• You want deny-by-default network and filesystem out of the box

The strictest isolation here: perfect for evaluating a model's data transform, useless if it needs a dependency.