Compare

How PAL Runtime compares.

Google Agent Compute Engine, E2B and Modal are managed sandboxes: compute you rent to run agent code. PAL Runtime is an open-source agent runtime you host yourself, and its sandbox is one part of it. So the comparison has two halves.

The sandbox

This is ACE’s whole product, and on isolation it is ahead of PAL Runtime by default: its sandbox never holds a credential and all egress leaves through a proxy on the host, backed by Google’s hardware root of trust. PAL Runtime comes closest only in its opt-in broker mode on Firecracker: injected credentials stay on the host, but vended secrets still enter the guest, there is no hardware root of trust, and it is validated on nested KVM, not at Google’s scale.

The sandbox: PAL Runtime, Google Agent Compute Engine, E2B and Modal
CapabilityPAL RuntimeGoogle Agent Compute EngineE2BModal
Hardware-isolated microVM per sandboxYes: Firecracker / Kata (needs KVM)YesYesPartly: gVisor or VM runtime
Platform runs the agent loop for youYesPartly: your harness (“each team writes and trusts its own harness”)No: you host the loopNo: you host the loop
Credentials never enter the sandboxPartly: injected headers only; opt-in broker mode, FirecrackerYes: by defaultPartly: header injection (beta)Partly: experimental
Egress allowlist enforced outside the guestPartly: broker mode, opt-inYes: by defaultPartly: CIDR + domain on HTTP/TLS, at E2B’s firewallPartly: CIDR; domain allowlist in beta
No network interface in the sandbox by defaultPartly: broker mode only; guest mode attaches a TAP NICYes: by defaultnot documentednot documented
Data-loss-prevention policy on egressNoYes: per Googlenot documentednot documented
Idle auto-suspend, resume on demandYes: Firecracker only, opt-in per VMYesYes: opt-inPartly
Snapshot and forkYes: Firecracker only; shared-memory forkYesYesPartly
Fork fan-out per callup to 1,000 (default 100); validated with 3 forks on Limathousands, memory-deduplicated (per Google)up to 20no fork
Hardware root of trust / attestationPartly: measurement recorded, not verifiedYes: TitanNoNo
Proven at scaleLima nested-KVM + CI onlyThe infrastructure behind Gemini’s agents (per Google)ProductionProduction

The platform around it

These are agent-runtime features. ACE is a compute layer, so “out of scope” means it isn’t trying to do them, not that it fails at them; on Google Cloud they come from other products.

The platform around it: PAL Runtime, Google Agent Compute Engine, E2B and Modal
CapabilityPAL RuntimeGoogle Agent Compute EngineE2BModal
Durable agent runs with crash-resumeYesout of scopeNoNo
Budgets enforced before the model callPartly: cost, tokens and runs per day, tenant daily cost, per-run cap mid-workflow, per-tool limits in workflows; per-run cap on single-call runs not enforced; a mid-workflow breach fails the stepout of scopeNoPartly
Multi-provider model routing with failoverYesout of scopeNoNo
Signed, offline-verifiable run receiptsPartly: only with a signing key configuredout of scopeNoNo
Self-host in your VPC or on-premYes: Apache-2.0No: Google Cloud onlyPartlyNo
AvailabilityOpen source todayPreview “in the coming months”Generally availableGenerally available

When to pick which

  • Pick Google ACE if you want a managed sandbox on Google Cloud with the strongest isolation defaults.

  • Pick E2B or Modal if you want hosted sandboxes today.

  • Pick PAL Runtime if you need to run agents in your own cloud or on-prem, with the sandbox, durable execution, spend limits and audit trail in one stack you control.

Competitor columns reflect each vendor’s public docs and announcements as of 2026-10-28; the Google column follows Google’sAgent Compute Engine deep dive (Oct 22, 2026). E2B: egress and secrets, auto-resume, fork. Modal: sandbox networking, Sandbox reference. A cross means not offered or not announced; “not documented” means the docs we read don’t say. If a cell is out of date, open an issue.

Back to PAL Runtime