LoginGet startedDashboard
Compare · Sandboxes

Sandal vs Modal

Modal is a broad serverless platform, functions, scheduling, GPUs, and container sandboxes, and it snapshots GPU memory, which nothing here matches. Sandal is the narrower tool: hardware-isolated machines for agents, priced per second with pause-to-$0, spanning Linux, Windows, macOS, CI runners and mobile simulators from one SDK.

Start buildingSee the migration
Reviewed August 2026 · 3 sources
Isolation
gVisorModalOwn kernelSandal
GPU memory snapshot
YesModal, Sandal
Paused sandbox
BilledModal$0Sandal
Surfaces on one SDK
ServerlessModalLinux · CI · mobileSandal
The honest split

Two good answers. Here is which one is yours.

Pick Modal if
  • Your workload is GPU-heavy inference and model weights or CUDA context are what you wait on.
  • You already run functions, jobs and sandboxes through Modal Apps and want one serverless control plane.
  • You want Modal-specific images, scheduling and platform primitives, not just a machine.
Pick Sandal if
  • You need the same API to also give the agent a CI runner, a desktop, or an iOS simulator.
  • Agents idle between turns and you refuse to pay wall-clock for a machine that is thinking.
  • Untrusted code needs its own kernel, default-deny egress and a key that dies with the machine.

Many teams run both. runs-on is per job and a sandbox is per task; nothing here is all or nothing.

Side by side

What each one actually ships.

Documented capability as of August 2026. Where the honest answer is a qualifier rather than yes or no, the qualifier is printed. Scroll sideways on a small screen.

Modal compared with Sandal, August 2026
AreaModalSandalWhy it matters
Runtime
GPUFirst-class GPUs, with GPU memory snapshots that take a vLLM cold start from about 45 s to about 5 s.No GPU sandboxes.If the model runs inside the sandbox, this row ends the comparison.
Pause and resumeSandboxes run until they finish or time out.Pause to $0 with memory intact; resume under 200 ms.Agent loops are mostly idle.
Fork a machineNo public evidence.Copy-on-write forks of a running box.Parallel attempts without rebuilding state.
Isolation
RuntimegVisor-isolated containers and VM sandboxes inside a Modal App.Firecracker microVM with its own kernel; containers on the same fleet for one-shot code.gVisor intercepts syscalls; a microVM gives the guest its own kernel. Different boundaries for untrusted code.
Pricing
BillingPer second on CPU, memory and GPU while the container runs.Per second while the machine runs; paused costs nothing.Same granularity; only one of them has a free idle state.
Surfaces
Beyond LinuxGeneral-purpose serverless compute; mobile and desktop are assembled separately.Linux, Windows and macOS machines, CI runners, iOS and Android simulators, Xcode builds.One integration instead of three.
Developer experience
SDKsPython.TypeScript and Python, CLI, REST, MCP. A Modal-shaped compat import in Python.TypeScript agent stacks have no native Modal client.
Sources · reviewed August 2026

Capabilities change and rates change. If something here is out of date, tell us and we will fix it the same week.

Price

Same shape. Two meters.

Modal prices CPU, memory and GPU separately per second; there is no single published rate for this shape, so we do not print one. Sandal publishes $0.036 per hour for 4 vCPU / 8 GiB, August 2026.

Modal4 vCPU / 8 GiB
Per-second CPU, memory and GPU rates, see Modal’s pricing page
Sandal4 vCPU / 8 GiB · paused = $0
0.036$ / hour
Price your own fleetThe full rate card
How to compare

Normalise both vendors on the same unit before you compare: one sandbox, one hour, the same size. Sandal meters per second and a paused machine costs nothing, so a bill for bursty work is the sum of the seconds it actually ran.

Open the rate card →
Migration

One line changes.

A compatibility shim presents the SDK you already call. Change the import, keep the code, and run both vendors side by side until the numbers convince you.

agent.py−1 +1one line changes
-import modal
+from sandal.compat import modal
app = modal.App("agent-runner")
sb = modal.Sandbox.create(app=app, cpu=4, memory=8192)
p = sb.exec("python", "-c", "print(1)")
sb.terminate()
  1. 01≈ 1 min

    Install the shim

    pip install sandal. The compat module presents modal.Sandbox with the create, exec and terminate calls you already make.

  2. 02≈ 10 min

    Swap the import

    Change one line. Sandbox lifecycle keeps its shape; Functions, schedules, images and GPU calls throw with a hint, they have no equivalent here.

  3. 03≈ 1 afternoon

    Run both, side by side

    Keep GPU work on Modal, move the agent’s CPU sandboxes, and compare the two bills.

Where Modal is ahead

What we would rather you read here than find later.

A comparison page where the vendor wins every row is a brochure. These are real, and we would rather you land on the right tool than land on us and leave in a month.

  • 01

    GPU memory snapshots.

    Modal snapshots GPU memory, not just CPU state, which takes a vLLM cold start from around 45 seconds to around 5. That work is deeper than ours and it is not close.

  • 02

    The serverless platform.

    Functions, schedules, images and Apps are one control plane on Modal. Sandal is a machine provider; the orchestration stays in your code.

Before you switch

Questions teams ask before moving off Modal.

For the Sandbox lifecycle, yes, through sandal.compat.modal. Modal Functions, schedules, images and GPU features have no equivalent on Sandal and the shim throws a hint rather than pretending.

More comparisons

The rest of the field in sandboxes.

All comparisons and the full matrix →
Get started

Run the same job twice.

Point one workload at Sandal and one at Modal. The numbers on this page are ours; the ones that matter are yours.

Start buildingRead the docs
npm i @sandal/sdk