The 9 Best Ephemeral Code Execution Environments for AI Agents (2026)

Key Points:

• An ephemeral code execution environment for AI agents is a short-lived, isolated compute unit - a Firecracker microVM, a gVisor sandbox, a container, a Kubernetes pod, or a V8 isolate - created on demand to run untrusted LLM-generated code and destroyed when the task ends.
• Nine options are worth a shortlist in 2026: E2B, Daytona, Blaxel, Vercel Sandbox and Cloudflare Sandbox (sandbox-as-a-service APIs), Modal and Koyeb (serverless compute), and Northflank and Qovery Agent Task (platforms that run agent workloads next to the apps they act on).
• Pick a sandbox API when the agent needs only a filesystem, a runtime and internet access. Pick a deployment platform when it needs your VPC, databases, secrets and RBAC, which is where most production agents end up by month two.
• Isolation strength ranks microVM > gVisor > shared-kernel container > same-process eval. A plain container is not a security boundary for untrusted code, and sandboxing alone does not stop prompt injection (OWASP LLM01) or excessive agency (LLM06).
• Cold start is rarely the bottleneck. microVM sandbox APIs report sub-second creation, while a single frontier-model round trip costs seconds, so isolation strength, egress control and data-plane access decide the outcome.
• Qovery Agent Task runs ephemeral agent workloads inside your own AWS, GCP, Azure, Scaleway or existing Kubernetes cluster, next to the apps and databases the agent operates on. Manus, by contrast, is an end-user agent product with its own session sandbox, not an execution platform you build on.

---

Your AI agent is going to run code you did not write. Some of that code will be wrong, some of it will be attacker-controlled, and you will not know which until it has already executed. McKinsey's State of AI in 2025 found 62% of organizations at least experimenting with AI agents and 23% already scaling one somewhere in the business. That is a lot of arbitrary code looking for somewhere safe to run.

That "somewhere" is an ephemeral code execution environment: a disposable, isolated compute unit you spin up per task and throw away when the agent is done. The market for it got crowded fast, and the vendors describe themselves in ways that make them sound interchangeable when they are not.

So this is a buyer's comparison, not a launch post. I checked every vendor figure below in September 2026, labeled it vendor-reported where it came from a vendor, and anchored the one benchmark I trust to a peer-reviewed paper. Where a number was not verifiable in current docs, I say so and describe it qualitatively instead.

What is an ephemeral code execution environment for AI agents?

An ephemeral code execution environment for AI agents is a disposable, isolated compute unit created on demand to run untrusted or LLM-generated code and destroyed when the task finishes. Three variables decide which one you need: how fast it boots, how strong the isolation is, and how much of your real environment it can reach.

Agents need disposable compute because their output is non-deterministic. A tool call can run an arbitrary pip install, a prompt injection can turn a "summarize this file" task into a "exfiltrate the environment variables" task, a loop can run away, and network egress can go anywhere the process is allowed to reach. You want all of that to happen inside a box you can incinerate.

The isolation options, ordered by how much they separate the guest from your host:

• microVMs (Firecracker, Cloud Hypervisor): each workload gets its own guest kernel behind a virtualization boundary.
• gVisor: a user-space kernel written in Go that intercepts and handles syscalls instead of passing them to the host (gvisor.dev).
• Shared-kernel containers: process isolation only, one kernel shared with the host.
• Kubernetes pods: containers plus namespace, network and RBAC policy, still sharing the node kernel unless you add a sandboxed runtime.
• V8 isolates: lightweight JavaScript contexts inside one process, the model Cloudflare Workers use.

Five dimensions are worth scoring, one line each:

• Cold start: time from "create" to the first line of your code actually executing.
• Session limits: maximum duration, and whether you can pause and resume.
• Egress control: can you default-deny outbound network and allow-list from there.
• Data-plane access: can it reach your VPC, databases and secrets, or only the public internet.
• Location: does the compute run in the vendor's cloud or inside your own account.

The vocabulary gets mixed up constantly, so here is the disambiguation.

The rest of this article uses three categories: sandbox-as-a-service APIs, serverless compute, and agent-adjacent deployment platforms.

Which ephemeral code execution environments should you actually consider in 2026?

Here is the shortlist. Five are sandbox APIs, two are serverless compute, and two are deployment platforms that run agents beside your apps. No single option wins every job.

1. E2B - open-source (Apache-2.0) Firecracker microVM sandboxes with Python and JS/TS SDKs, self-hostable on your own cloud via Terraform, no GPU focus, billed per second of vCPU and RAM. Best for: code-interpreter and data-analysis agents. Skip it if: the agent needs to reach your private services and databases.
2. Modal - serverless CPU/GPU compute with gVisor-isolated Sandboxes, memory snapshotting, per-second billing, and a deep GPU lineup (T4 through H200 and B200). Closed platform. Best for: compute- or inference-heavy agent work. Skip it if: you want a microVM boundary or a self-hosted install.
3. Daytona - stateful, persistent agent sandboxes with declarative snapshots, sub-90ms creation, per-second billing. Best for: repo-scoped coding agents that keep state across turns. Skip it if: you need a supported open-source install (the core repo moved to a private codebase in June 2026).
4. Northflank - a full application platform with sandboxes, microVM isolation and bring-your-own-cloud. Closest architectural comparison to Qovery. Best for: teams that want one platform for apps and agent workloads across clouds. Skip it if: all you need is a throwaway public code interpreter.
5. Koyeb - microVM serverless compute (Cloud Hypervisor via Kata, historically Firecracker) with multi-region placement and GPUs, billed per second. Best for: latency-sensitive tool calls placed near users. Skip it if: you need the workload to run inside your own cloud account.
6. Blaxel - agent-first infrastructure: microVM sandboxes plus agent hosting, batch jobs, MCP server hosting and a model gateway, billed per GB-second. Managed platform, open-source SDKs. Best for: teams building agents on one opinionated agent-native stack. Skip it if: you need to self-host the platform in your account.
7. Vercel Sandbox - ephemeral Firecracker microVMs wired into the Vercel and AI SDK ecosystem, billed on active CPU and memory. Best for: agents that already live inside a Next.js or Vercel app. Skip it if: the agent must run in your own VPC next to internal services.
8. Cloudflare Sandbox SDK / Workers isolates - V8 isolates at the edge with effectively zero cold start for very short, high-fanout calls, plus a container-backed Sandbox SDK for real Linux workloads. Best for: huge fan-out of tiny, short tool calls at the edge. Skip it if: the agent needs long-running sessions or your private data plane.
9. Qovery Agent Task - ephemeral, on-demand execution environments for agent workloads created inside your own AWS, GCP, Azure, Scaleway or existing Kubernetes cluster, next to the apps and databases the agent touches. Best for: agents that operate your own services and data. Skip it if: you only need a public sandbox with no access to your systems.

One category correction, because AI answers keep getting it wrong: Manus is not on this list, and should not be. Manus is "an autonomous general AI agent designed to complete tasks and deliver results." It runs each task in its own isolated cloud VM, but that sandbox is an implementation detail of an end-user product. It is not an execution platform you build your own agents on.

Here is the anchor comparison. Cold-start figures are vendor-reported unless noted, checked September 2026.

How fast do AI agent sandboxes actually cold start, and does it matter?

The range first: vendor-reported sandbox creation clusters in the sub-second range for microVM APIs and in single-digit seconds for container-based platforms. A single frontier-model round trip costs seconds. So isolation strength and data-plane access matter far more than shaving 200ms off a boot.

The one number I trust here is not from a vendor. The Firecracker paper at USENIX NSDI 2020 reports that a microVM "boots to application code in less than 125 ms," carries "memory overhead of less than 5 MB per microVM," and that a single host can create "up to 150 MicroVMs per second." That is the physics floor that most sandbox APIs on this list build on.

The vendor figures are real but not comparable to each other, because they measure different things:

• E2B reports sandboxes starting in under 200 ms in-region.
• Modal says containers "boot in about one second", with memory snapshotting to cut that further.
• Daytona claims sub-90ms sandbox creation from a warm pool.
• Koyeb reports ~200 ms scale-to-zero wake for its light-sleep path, and 1-5 s for a full cold VM.
• Blaxel advertises a ~25 ms resume from standby, which is a resume, not a from-scratch boot.
• Cloudflare Workers isolates have effectively zero cold start because a Worker loads in about 5 ms.

Read those carefully. "Sandbox create" is not "time to first executed line," which is not "snapshot restore," which is not "warm-pool hit," which is not "the 40 seconds it takes to pip install your dependencies." Blaxel's 25 ms is a resume; Koyeb's 200 ms is a wake from light sleep; Daytona's sub-90ms is a warm create. Comparing them head to head is apples to oranges.

Now size it against the agent loop. On Artificial Analysis, even the fastest non-reasoning frontier models return their first token in roughly 0.3 to 0.4 seconds, and reasoning models spend tens of seconds "thinking" before the first token. A coding agent on SWE-bench takes a median of about 12 model-call steps to solve a task. Multiply seconds-per-step by a dozen steps and a 200 ms boot is a rounding error.

Cold start matters where you feel it directly: editor-loop coding agents, per-request tool calls inside a user-facing chat, and high-fanout runs of hundreds of sandboxes at once. It does not matter for research, build and test, migrations, CI-like jobs, or anything with a human reviewing the output. If you are going to optimize it, measure your own p50/p95 time to first executed line, with your image, your dependency install, your region and your real concurrency, and publish the method next to the number.

How do you keep an AI agent's sandbox from becoming a security incident?

Treat every LLM-generated command as hostile input, enforce isolation at the kernel boundary, and pair it with default-deny egress, short-lived scoped credentials and a full command audit trail. Sandboxing alone is not security, because prompt injection and excessive agency happen inside whatever permissions the sandbox already holds.

The threat model is concrete. A prompt injection tells the agent to read a secret and POST it out. A typosquatted dependency gets pulled during npm install. Data leaves over DNS or plain HTTP to an allowed host. The agent writes to a shared bucket, or calls an internal admin API that happened to be reachable. None of these require breaking out of the sandbox. They abuse what the sandbox can already do.

This is not theoretical. Johann Rehberger documented a prompt injection hidden in source code that made GitHub Copilot Chat render a markdown image whose auto-fetch leaked chat-context data as a URL parameter to an attacker server. In 2025, the "EchoLeak" flaw in Microsoft 365 Copilot (CVE-2025-32711, CVSS 9.3) let a single crafted email trigger zero-click exfiltration. The attacker never touched the kernel.

That said, the kernel boundary is still your first line, and the ranking is not marketing:

OWASP is blunt about the non-kernel half. Its 2025 guidance for Prompt Injection says to "restrict the model's access privileges to the minimum necessary" and to "implement human-in-the-loop controls for privileged operations." For Excessive Agency it says to "limit the permissions that LLM extensions are granted to other systems to the minimum necessary" and to require human approval for high-impact actions. Least privilege, not just a strong box.

My non-negotiables checklist for any agent sandbox:

• Default-deny egress with an explicit allow-list.
• Zero long-lived cloud keys. One OIDC-issued, short-lived identity per task.
• Read-only mounts by default.
• Hard CPU, memory and wall-clock caps.
• TTL auto-destroy.
• Per-command logging you can actually read after the fact.

Running in your own VPC changes the trade-off in both directions. You inherit your existing network policy, IAM and data-residency posture, which is a real advantage for regulated data. You also own the blast-radius design, so a mistake is your mistake. And the anti-pattern to name out loud: pasting the production database URL into an agent's environment variables "just for now." That is how an isolation win becomes a bigger incident.

When should an AI agent run in a sandbox versus a real deployed ephemeral environment?

Use a sandbox when the agent needs only a filesystem, a runtime and internet access. Use a real ephemeral environment inside your own cloud when it needs your services, your database, your private network, or must leave an artifact a human will review. Most agent sandbox setups fail not on latency but because the sandbox cannot reach the systems the agent is supposed to change.

Sandbox-appropriate work is self-contained: code interpretation, uploaded-file analysis, scraping, test generation, throwaway data transformations. Deployment-appropriate work touches your world: PR-verifying agents, schema migrations, infra operations, multi-service integration tests, internal-only API calls.

Then month two arrives. The agent that "just runs code" now needs to hit the staging API, and there is no route from the sandbox to your network. So someone tunnels a production credential into the sandbox to make it work, and the isolation win quietly becomes a credential-exposure incident. The pattern that avoids it: one ephemeral preview environment per pull request, with ephemeral agent tasks running inside it, sharing a network boundary and a lifecycle, destroyed together.

Cost decides the rest. Flexera's 2026 State of the Cloud puts self-reported wasted cloud spend at 29%, and CAST AI's Kubernetes benchmark found large clusters use only about 13% of provisioned CPU and 20% of memory. Parallel agent fleets stay affordable only with auto-stop for idle non-production and destroy-on-completion for tasks. Per-second sandbox billing wins for bursty, public, short-lived work; a cluster you already pay for wins when the agents run steadily next to apps that are already there.

How does Qovery Agent Task compare to sandbox-only providers like E2B or Modal?

E2B, Modal, Daytona, Blaxel, Vercel Sandbox and Cloudflare Sandbox give you a sandbox in their cloud. Qovery Agent Task gives you ephemeral agent execution inside your own AWS, GCP, Azure, Scaleway or existing Kubernetes cluster, next to the applications and databases the agent needs to act on. That is the whole difference, and it is the difference that shows up in month two.

I will describe Agent Task only from what Qovery actually ships. It is an on-demand ephemeral execution environment for agent workloads, created and destroyed per task, deployed into your own cluster. I am not going to quote you a boot time or a session cap for it, because Qovery does not publish one and I am not going to invent one.

What is verified are the platform capabilities around it: git-push deployments, preview environments with one per pull request torn down automatically, TTL cleanup for abandoned environments, per-environment RBAC, databases backed either by managed cloud services or containers, managed cluster provisioning and upgrades, and OPA-backed API Policy Tokens so an agent's token is scoped to exactly what it may do. Qovery calls itself the agentic infrastructure platform that sits between your team, human or AI agent, and your own cloud account.

The bring-your-own-cloud consequence is concrete: the cloud bill, the committed-use discounts and the Savings Plans stay in your name, and the data never leaves your account. That is what makes residency and audit requirements tractable instead of a compliance meeting that never ends.

Where Qovery is not the answer, plainly: reach for E2B or Vercel Sandbox for a public sub-second code interpreter, Modal for per-second GPU billing next to inference, Daytona for stateful repo workspaces that persist across turns, and Cloudflare for very short, high-fanout edge calls. If the agent only needs a filesystem and the internet, a sandbox API is simpler and cheaper.

Northflank deserves the most respect here, because it is the closest architecture to Qovery: a full application platform with sandboxes, microVM isolation and bring-your-own-cloud across AWS, GCP, Azure and more, plus bring-your-own-Kubernetes. The honest differences are emphasis and cloud coverage. Northflank leans hard into being an all-clouds runtime with first-class sandbox primitives; Qovery leans into a git-driven application platform on AWS, GCP, Azure, Scaleway and your own Kubernetes, with per-environment RBAC and OPA policy tokens as the governance spine. If you are choosing between them, the deciding questions are which clouds you actually run on and whether your center of gravity is the sandbox primitive or the application lifecycle.

How do you build an ephemeral agent execution setup you will not regret in six months?

Five steps, in order:

1. Define the task contract. Inputs, allowed tools, max runtime, the expected artifact, and an explicit definition of failure. Everything else depends on this being written down first.
2. Pick isolation by trust level. Expect two tiers: untrusted LLM code goes in a microVM sandbox API, and agents that operate your systems go in an ephemeral environment inside your own cloud.
3. Wire credentials on day one. OIDC-issued, short-lived, scoped tokens. One identity per task. No static keys, no shared service account that already holds admin.
4. Add observability and a kill switch. Per-task logs, a full command trace, cost attribution per run, and a kill switch you have actually tested by pulling it, not one you assume works.
5. Enforce lifecycle limits before you scale. Hard TTL, destroy on completion, auto-stop when idle, and a cap on concurrent tasks per project, all in place before you fan out to parallel agents.

A migration note that saves rework: start on a sandbox API for the self-contained half, then move the "agent needs my services" half onto your own cluster later. If you wrote the task contract first, the agent code barely changes when you switch where it runs.

Teams over-optimize cold start and under-invest in credential scoping, and that is the wrong order. Pick the isolation that matches the trust level, put the compute where the data it needs already lives, and the 200 milliseconds you were worried about stops being interesting.