AI Agent Runtime Infrastructure: What It Is, How to Choose, How to Self-Host

An AI agent runtime is the isolated computer where an agent's tool calls actually execute: the shell, filesystem, network and state that a 'run this code' call lands in. The framework decides what the agent does next; the runtime is where it happens and what it is allowed to touch. That layer decides whether a confidently wrong model action is a shrug or an incident, whether the agent loop feels quick or sluggish, and whether many tenants can share a fleet without reading each other's data.

This guide defines the layer, separates it from agent frameworks and model serving, maps the 2026 options using each vendor's own documentation, gives a nine-point checklist, works through a cost example, and shows how to self-host an open-source runtime on Firecracker. Disclosure: I build PandaStack, an Apache-2.0 Firecracker microVM platform, so weight my opinions accordingly. Every PandaStack number here comes from the public benchmarks and pricing pages.

The runtime is not an implementation detail to pick last. It sets the ceiling for everything above it. A capable agent on a runtime that takes seconds to hand out a fresh machine feels slow, and it pushes you toward reusing long-lived boxes. A simpler agent on a runtime that can fork a warm machine cheaply can run best-of-N search that the other one cannot afford.

What is an AI agent runtime?

An AI agent runtime is the execution environment where an agent's actions happen. The model proposes an action (run this Python, edit this file, open this page), the framework routes it to a tool, and the runtime executes it on a real machine and returns stdout, stderr and an exit code that the model reads on its next turn. What that action can reach, whether files, network, credentials or other tenants, is decided by the runtime, not by the prompt.

The term is used for two different jobs, and search results mix them up:

• Where the agent loop runs: the process that calls the model, keeps conversation state and dispatches tools. Amazon Bedrock AgentCore Runtime and Google's Agent Runtime (part of the Gemini Enterprise Agent Platform) are managed hosts for this job. You hand them an agent built with LangGraph, CrewAI, Google's Agent Development Kit or your own loop, and they deploy and scale it.
• Where the agent's tool calls run: the machine that generated code and shell commands execute in. This is the sandbox layer, where E2B, Modal Sandboxes, Vercel Sandbox, Cloudflare's Sandbox SDK, Daytona and PandaStack sit. It decides blast radius, create latency and per-tenant isolation.

Most production agents need both, and the two do not have to come from the same vendor. The loop can live in your API server, a serverless function or a hyperscaler agent host, while every tool call that executes code goes to a disposable microVM. AWS draws the same line inside its own product: AgentCore documents a separate Code Interpreter tool next to the Runtime. This guide is mostly about the second job, because that is where untrusted, model-written code meets your infrastructure. On PandaStack's hosted service both fit on one platform: the loop can run under app hosting or functions, and the tool calls in per-session AI agent sandboxes.

AI agent runtime vs. agent framework vs. model serving

Agent stacks are easier to reason about as three layers with different owners. Mixing them up is how an agent's generated code ends up running through subprocess.run on the API server.

The layers are separable. A LangGraph node, a CrewAI tool or an OpenAI Agents SDK function tool is just a function that calls the runtime's API, so any framework can use any runtime, and swapping the runtime does not mean rewriting the agent. The PandaStack docs have integration guides for LangGraph, LangChain, CrewAI, AutoGen, LlamaIndex, Mastra, the OpenAI Agents SDK, Pydantic AI, smolagents, the Vercel AI SDK and Claude Managed Agents, plus an MCP server. For a worked example of that seam, see How to Give a LangGraph Agent a Code Execution Tool.

The 2026 AI agent runtime landscape

Three kinds of platform compete for this layer. What follows about each vendor is paraphrased from that vendor's own documentation as checked on 23 September 2026; the sources are listed after the comparison tables.

Managed agent hosts

Amazon Bedrock AgentCore Runtime is a serverless host for agents and tools. AWS documents that each user session runs in a dedicated microVM with its own CPU, memory and filesystem, terminated when the session ends; that it works with any framework and model; that filesystem state can persist across stop and resume; and that CPU billing follows active processing rather than allocation. Its Instances compute type runs agents on EC2 in your own account. Google's Agent Runtime, part of the Gemini Enterprise Agent Platform, is a fully managed runtime for deploying and scaling agents: full integration with Google's ADK, SDK templates for LangChain, LangGraph, AG2 and LlamaIndex, and support for any agent that can be containerized. Pick this category when you are committed to one cloud and want the loop, identity and tracing managed together.

Sandbox runtimes

These give each agent session or task its own isolated machine through an API. E2B runs one Firecracker microVM per sandbox and publishes its runtime under Apache-2.0. Vercel Sandbox runs each sandbox in a Firecracker microVM. Modal Sandboxes run on gVisor by default, with a beta option to run a sandbox on a full VM with its own Linux kernel. Cloudflare's Sandbox SDK runs each sandbox in its own container on Cloudflare Containers, driven from a Worker. Daytona's README describes sandboxes with a dedicated kernel. PandaStack is in this category too: one Firecracker microVM per sandbox, with an open-source core. Pick this category when the agent runs code nobody reviewed and you care about create latency, snapshot and fork, and per-tenant isolation.

Compute you assemble yourself

Fly Machines (fast-launching Firecracker microVMs behind a REST API), Kubernetes with a sandboxing container runtime such as gVisor or Kata Containers, or raw Firecracker on your own KVM hosts. You get full control, and you also build the snapshot pipeline, network pool, scheduler, egress policy and billing yourself. Section 9 below covers that trade-off, and the isolation side is covered in more depth in Agent runtimes: containers vs microVMs.

AI agent runtime comparison: isolation, state, egress and self-hosting

Each competitor cell below paraphrases that vendor's own public page, checked on 23 September 2026. A dash means the pages we checked did not say; it does not mean the feature is missing. Products in this space change monthly, so confirm on the vendor's site before you decide. Prices are left out on purpose: vendors meter different things (allocated versus used CPU, per core versus per vCPU), so compare them on each vendor's pricing page against your own workload.

Two gaps in our own row are worth stating plainly. PandaStack has no per-sandbox outbound allowlist today, while E2B, Modal and Vercel document domain allowlists and Cloudflare documents outbound allow, block and intercept handlers. And the open-source repository is the sandbox and managed-Postgres core: app hosting, functions, schedules and billing run only on the hosted service. Google Agent Runtime and Fly Machines are left out of the second table because the pages we checked cover neither column.

• PandaStack: github.com/pandastack-io/pandastack-ai (README); the docs.pandastack.ai isolation-model and egress-controls pages.
• E2B: github.com/e2b-dev/runtime (README).
• Modal: modal.com/docs/guide/security, modal.com/docs/guide/vm-sandboxes, modal.com/docs/guide/sandbox-networking.
• Vercel Sandbox: vercel.com/docs/sandbox and vercel.com/docs/sandbox/concepts/firewall.
• Cloudflare Sandbox SDK: developers.cloudflare.com/sandbox.
• Daytona: github.com/daytonaio/daytona (README).
• Amazon Bedrock AgentCore Runtime: docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html.
• Google Agent Runtime: docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime.
• Fly Machines: fly.io/docs/reference/architecture.

Where should you run an AI agent?

Short answer: on your laptop while you build it, and behind a real isolation boundary once other people's inputs reach it. These are the common deployment models:

A decision path that holds up in practice:

1. Does the agent execute code, shell commands or packages that a model chose? If not, and its tools only call fixed, scoped APIs, the loop can run wherever your app runs. If it does, send those calls to a hardware-isolated sandbox.
2. Will more than one customer's inputs reach it? Then use one sandbox per tenant or per session, never a shared box, and tag every sandbox with its tenant.
3. Must data stay inside your network or jurisdiction? Then you need a runtime you can self-host or have deployed in your own account.
4. Does the agent sit idle between turns while it waits on a model or a user? Then weight hibernation or pause-and-resume heavily, because that waiting is idle compute.
5. Will you branch work, such as best-of-N attempts or retries from a known state? Then weight snapshot and fork.

A common production shape: the agent loop runs wherever your application already runs, and every code-executing tool call goes to a per-session microVM that is created on demand, hibernated between turns and deleted at the end. On PandaStack you call hibernate() on a persistent sandbox between turns (or when a session goes quiet), and the next exec or file read or write wakes it, so a warm machine per user does not mean paying for idle compute.

The AI agent runtime checklist: nine capabilities

Whichever category you pick, these are the capabilities to evaluate. The sections below take each in turn: what to look for, why it matters for agents, and where PandaStack lands.

1. Isolation boundary: what happens when the model runs a bad line? Process < container < microVM, and untrusted agent code needs a VM-grade boundary.
2. Fast create: create latency is felt latency inside the agent loop. Snapshot-restore vs. warm pools vs. cold boot.
3. Statefulness: ephemeral per task vs. persistent per session, plus hibernate and wake so idle sessions cost close to nothing.
4. Networking and egress control: per-sandbox network namespaces, hard blocks on cloud metadata and cross-tenant traffic, and an outbound policy you can tighten.
5. Filesystem and durable volumes: copy-on-write root disks for throwaway work; durable volumes for state that must outlive the VM.
6. Snapshot and fork: branch agent state cheaply for best-of-N search and warm starts. Hard to bolt on later.
7. Multi-tenancy and resource limits: one tenant per boundary and hard memory ceilings, so a runaway job is one VM you can kill.
8. Observability: structured exec results, streaming logs, a PTY, and per-tenant attribution.
9. Build vs. buy vs. self-host: the org decision that constrains the other eight.

1. Isolation boundary: process vs. container vs. microVM

This is the load-bearing one, so it goes first. The instant a model writes the code you are about to run, that code is untrusted: not necessarily malicious, just not reviewed by a human before it executed. Where that code runs is the security model of your product. There are three answers, in increasing order of how well you will sleep, and the difference between them is the kernel.

• In-process (exec or eval in your app): no boundary at all. A bad line reaches everything your process can reach: your database, your secrets, your filesystem. Fine for a demo, dangerous the moment it ships, and prototypes ship.
• Containers (namespaces, cgroups, seccomp): fast, cheap, dense, and sharing the host's one kernel across every tenant. A container restricts what a process can see; a kernel-level escape ignores those restrictions and reaches the host and every neighbor. Right for code you wrote, risky for code a model wrote.
• Hardware-virtualized microVMs (Firecracker, Kata): each sandbox boots its own guest kernel isolated by KVM. Guest code makes syscalls against its own kernel, never the host's, and the path out is a small virtual device model. This is the right default for arbitrary agent-written code; Firecracker was built by AWS to run Lambda and Fargate workloads from many customers on shared hardware.

What to look for: does the runtime give the guest its own kernel, or share yours? Shared-kernel hardening (seccomp, dropped capabilities, user namespaces) is a real improvement over nothing, but it is mitigation, not isolation: one kernel privilege-escalation bug reachable through an allowed syscall still threatens the host. The caveat cuts both ways. A microVM is not immune; VMMs and KVM have had bugs. The accurate claim is a much smaller, better-audited attack surface than the full Linux syscall interface a container exposes. The long-form comparison is Firecracker vs Docker: which one runs untrusted code?

Where PandaStack lands: every sandbox, managed database and hosted app is its own Firecracker microVM (v1.16, unmodified) with its own Linux 5.10 guest kernel. The boundary is VM-grade by default, not an option you enable. To reach the host, an exploit in the agent's code has to get through KVM and Firecracker's device model, not just a namespace.

2. Fast create: create latency is felt latency

The create call sits inside the agent loop, and you may hit it many times per trajectory: per task, sometimes per step. Its latency is how the product feels. If a fresh, isolated computer takes seconds, you will be tempted to keep one long-lived box and reuse it across tasks, which quietly rebuilds the shared-state problems the boundary was meant to solve. If it takes well under a second, disposable-per-task becomes the default and the architecture gets simpler.

There are three approaches, and they get conflated. Cold boot: boot a kernel and userland every time; correct, isolated, and slow. Warm pool: keep idle VMs pre-booted and hand one out on demand; fast to hand out, but you pay to keep the pool warm whether or not anyone uses it. Snapshot-restore: boot once, snapshot the running machine, and restore that snapshot on every create; fast like a warm pool, with no idle fleet to fund. The trade-offs have their own post: Snapshot-Restore vs Warm Pools: Two Ways to Kill Sandbox Cold Starts.

What to look for: ask which of the three a vendor uses, and what their number measures. Server-side create-to-ready and wall-clock time from your client are different claims; the second adds network round trips. A warm-pool hand-out and a snapshot restore can both be fast and still behave differently under a burst. Benchmark on your own template, region and concurrency, including PandaStack's numbers.

Where PandaStack lands: snapshot-restore on every create, with no warm pool of idle VMs. The published figure is 49 ms p50 sandbox create, measured server-side from POST /v1/sandboxes to ready across 50 consecutive boots of the base template on the live API on 17 June 2026. It covers the scheduler claim, the snapshot restore, network assignment and the guest readiness probe; your client's wall-clock time adds its own network round trip. The first spawn of a new template does a full cold boot and bakes the snapshot that later creates restore from. Because there is no idle pool, idle tenants cost nothing, and a disposable machine per task is cheap in both time and money. The methodology is on the benchmarks page.

3. Statefulness: ephemeral, persistent, and hibernate/wake

Agents come in two shapes and your runtime needs to serve both. The one-shot task (run this, return the result, throw the machine away) wants an ephemeral sandbox: nothing survives, no state leaks from one run into the next, and nothing is left running. The interactive or long-horizon agent, such as a coding session that installs packages and edits files for twenty minutes, wants a persistent sandbox that holds state across steps so you are not re-cloning the repository every turn.

What to look for: can you choose per sandbox, or is the runtime opinionated one way? Ephemeral-only forces you to re-provision state constantly; persistent-only means idle sessions burn money until something reaps them. The best answer is both, plus a third state for sessions that are neither hot nor finished: hibernated. A hibernated session is snapshotted and stopped, costs little or nothing while idle, and wakes on the next request with its state intact. That is what makes a warm workspace per user affordable at scale. The long-running case is covered in Long-Running Sandboxes for AI Agents.

Where PandaStack lands: sandboxes are ephemeral by default. Each has a TTL (one hour unless you set ttl_seconds, refreshed by API activity), and the Python SDK's context manager kills a non-persistent sandbox when the with block exits. Create one with persistent=True and the TTL reaper leaves it alone. Nothing hibernates it for you, so call hibernate() when the session goes idle; the next exec or file read or write wakes it with memory and disk intact. Hibernated sandboxes bill no compute. On the Free plan a sandbox is deleted one hour after it is created regardless, so long-lived sessions need a paid plan. One rule does not bend: one tenant per persistent sandbox. Reusing one across two tenants erases the boundary by hand.

4. Networking and egress control

Isolating the machine contains what the code can do to your host. It does nothing about where the code can reach out to. Agent code with unrestricted outbound access can hit your internal network, a cloud metadata endpoint, a data-exfiltration server or a mining pool, and the kernel boundary stops none of that, because it is all just packets leaving a well-isolated VM. Egress control is a separate capability from isolation.

What to look for: per-sandbox network namespaces, so one tenant's traffic cannot be seen or spoofed by another; hard blocks on the cloud metadata endpoint and on traffic between sandboxes; and an outbound policy you can tighten. Default-deny with a per-sandbox allowlist is the strongest posture: the task needs PyPI and one API, not the whole internet. Also ask how networking is provisioned, because building a namespace, veth pair and firewall rules from scratch on every create adds latency. The threat model and the controls are in Controlling Network Egress for Untrusted Code.

Where PandaStack lands: each sandbox gets its own /30 from a per-host address pool (16,384 slots), with its own network namespace, veth pair and TAP device. A warm set of slots is built ahead of time, so a create usually patches an existing slot instead of building one. VM-to-VM traffic and the whole link-local range, which includes the cloud metadata endpoint, are dropped at the top of the host's FORWARD chain, and outbound connections to standard Stratum mining-pool ports are blocked by default. Beyond that, outbound access is open, and there is no per-sandbox allowlist today. That is a deliberate trade-off for agents that install packages and call APIs, paired with egress that is attributable to one VM and workspace. If your threat model needs default-deny egress, enforce it with your own egress proxy, or self-host and tighten the host policy; the blocked-port list is operator-configurable.

5. Filesystem and durable volumes

Two needs hide under 'the sandbox has a filesystem.' The first is a throwaway working disk: the agent clones a repository, writes files, makes a mess, and it all vanishes when the VM dies. That disk should be cheap to create, which means copy-on-write: a fresh root disk is a metadata-only clone that shares blocks with the template until something is written, not a multi-gigabyte copy on every create. The second is state that must outlive the VM: a database's data directory, a user's uploaded files, anything you would miss when the machine is reaped.

What to look for: copy-on-write on the ephemeral root disk, and a separate durable-volume primitive for persistent state, so you are not conflating the machine with the data. Conflating them is how teams end up afraid to delete a sandbox because the data lives on the same disk, which defeats the disposability that made the model safe.

Where PandaStack lands: the root disk is an XFS reflink clone of the template image, private to the VM from its first write. Durable volumes are a separate primitive: named ext4 volumes you attach read-write to one sandbox or read-only to many, which survive the sandbox. Managed databases keep their data on a durable volume too. The split is deliberate: delete the VM freely, keep the volume when you mean to.

6. Snapshot and fork: branching agent state

This capability is easy to overlook and painful to add later. Agents are unreliable per attempt and much stronger in aggregate: generate five candidate fixes, run each, keep the one whose tests pass. The naive way creates five environments and repeats setup five times. The fast way warms one environment (repository cloned, dependencies installed, data loaded), forks it N times with copy-on-write, and explores each branch in parallel. Every branch inherits the warm state.

fork_tree clones a running sandbox with copy-on-write: the parent is snapshotted once and each child restores that snapshot, so guest memory is mapped MAP_PRIVATE (the kernel copies a page only when a child writes it) and the root disk is cloned with a reflink. A snapshot does the same across time instead of across branches: freeze a warm, configured machine and restore it later as a warm start. A plain fork() is different: it copies only the disk and cold-boots the child, so it is not a live copy of the parent. What to look for: are snapshot and fork first-class API primitives, or something you would reconstruct from raw VM images? If best-of-N or tree search is central to your agent, weight this heavily. The mechanics are walked through in How AI Agent Sandboxes Work.

Where PandaStack lands: snapshot, fork, fork_tree and explore are SDK primitives. fork_tree restores each child with the parent's memory and disk in about 400 ms on the same host; a plain fork() copies only the disk and cold-boots the child (about 3 s), so running processes do not carry over. explore() is built on fork_tree: it runs a list of candidate commands in parallel children, scores the outcomes, promotes the winner and reaps the losers. fork_tree children run on the parent's host by default, because they share the parent's memory pages and disk blocks, so fan-out is bounded by that host's memory; explore() caps a round at 16 branches. A dead-end branch costs one kill().

7. Multi-tenancy and resource limits

Once more than one customer's agents share a fleet, two failure modes appear. The noisy neighbor: one tenant's agent writes a runaway loop or a huge allocation, pins cores or triggers the host OOM killer, and a neighbor's reasonable job is degraded or killed. The cross-tenant leak: a worker that held tenant A's data and your platform credentials runs tenant B's code, and that code reads what is still in memory. Both are architecture problems, not bugs you can patch.

What to look for: is the isolation boundary also the tenancy boundary (one tenant per VM, so a leak is prevented by construction rather than by policy), and are resource limits hard ceilings? A microVM with a memory size baked into its template and a CPU share enforced by cgroups turns a runaway allocation into one guest killing its own process, instead of the host evicting whatever it evicts. The per-tenant pattern in depth: Per-Tenant Analytics Queries in Isolated microVMs.

Where PandaStack lands: multi-tenant by construction, with orgs and members at the top and one VM per sandbox. RAM is fixed by the template snapshot (2 GiB for code-interpreter, 4 GiB for base), so an allocation cannot grow past the guest's size. Every sandbox gets 8 burstable vCPUs, shared by cgroup weight under contention; the Free plan caps sustained use at 2 cores. Workspaces also have concurrent-sandbox, hourly-create and aggregate CPU and memory quotas. A managed database is a dedicated microVM with its own durable volume, not a schema in a shared instance, so a per-tenant database is a hardware-enforced boundary rather than a WHERE clause a query can forget. Addressing allows 16,384 sandboxes per host; in practice host memory and CPU are the limit.

8. Observability: logs, metrics, exec/PTY

If you cannot see what the agent's code did, you cannot debug it, let the model self-correct on real failures, or bill for it. The runtime has to surface three things. Exec results: stdout, stderr and the exit code as separate fields, because the agent needs to see a non-zero exit or an error on stderr to fix it. Logs: the machine's console and the workload's output, streamable so you can follow a long build. An interactive path: a PTY for when a human needs to drop into the guest.

What to look for: structured exec results rather than a merged text blob, streaming logs, a real PTY for interactive debugging, and per-sandbox metadata you can attribute to a tenant for billing and abuse investigation. Tag every sandbox with a tenant id so a runaway run, a suspicious connection or a billing line traces back to exactly one customer.

Where PandaStack lands: exec returns stdout, stderr and exit_code as separate fields. There is an SSE exec stream for live output, a WebSocket PTY compatible with xterm.js, SSE streams for Firecracker logs and lifecycle events, and free-form metadata you set at create time for tenant attribution. Commands reach the guest over an SSH bridge from the host agent. Lifecycle events and metrics are recorded in Postgres and ClickHouse.

9. Build vs. buy vs. self-host your agent runtime

This org-level decision constrains the other eight, and it mostly comes down to who owns the KVM hosts and whether you can read the source. Building on raw Firecracker is doable, since the primitives are open, but you are signing up to implement snapshot-restore, a network pool, a scheduler, egress control and multi-tenant billing yourself: a platform, not a weekend. Buying a hosted sandbox is fastest to a first run, but it puts your untrusted-code execution on someone else's fleet, pricing and data-residency terms. Self-hosting an open-source platform is the middle path: someone else built it, and you run it on your own hosts.

What to look for: is the core open-source and self-hostable, or hosted-only? That matters for data residency, air-gapped or regulated environments, cost at scale, and not depending on an execution layer you cannot inspect or move off. The build-versus-buy math, including when building is the right call, is in Build vs Buy: Rolling Your Own Firecracker Sandbox, and the self-host path is in Self-Hosted Code Execution Sandbox for Production AI.

Where PandaStack lands: both. The hosted service runs the full platform, and the Apache-2.0 repository contains the core it is built on: the Go control-plane API and scheduler (backed by Postgres), the per-host agent that drives Firecracker, the SNI-routing database proxy and the template Dockerfiles. That three-layer split (control plane, per-host agent, microVMs) is roughly what you would build yourself on raw Firecracker, which makes it a useful yardstick when you estimate a build.

Self-host an open-source AI agent runtime on Firecracker

If your agents handle data that cannot leave your network, or you would rather not rent your execution layer, you can run the runtime yourself. PandaStack's public repository, github.com/pandastack-io/pandastack-ai, is Apache-2.0 and covers sandboxes and managed Postgres: create, exec, filesystem, PTY, pause and resume, hibernate and wake, TTLs, snapshots and fork trees, volumes, memory streaming from object storage, and the multi-node scheduler. The open-source edition ships without billing, metering or quota code, so it has no usage limits.

What you need

• Linux hosts with /dev/kvm: bare metal, a *.metal cloud instance, or a cloud VM with nested virtualization enabled. The one-command path is tested on Ubuntu 22.04 and 24.04 and Debian 12, on x86_64 or aarch64.
• For a single box, at least 4 vCPUs, 8 GiB of RAM and 30 GiB of free disk; the docs recommend 8 vCPUs and 16 GiB.
• Postgres for the control plane and ClickHouse for events and metrics. The local script runs both in Docker.
• Object storage (GCS, or an S3-compatible store) if you want snapshot seeds and memory streaming across hosts.
• Deployment guides exist for GCP (Terraform on Compute Engine with nested virtualization), AWS (bare-metal c5n.metal), on-prem bare metal, and Apple Silicon through Lima for development.

Try it on one Linux box

# Ubuntu 22.04+/24.04 or Debian 12, with /dev/kvm readable by your user
git clone https://github.com/pandastack-io/pandastack-ai
cd pandastack-ai
bash scripts/linux-local-e2e.sh   # idempotent: Postgres + ClickHouse in Docker;
                                  # API :8080, dashboard :3000, Firecracker agent :7070

# smoke test against your own control plane
curl -fsS http://localhost:8080/healthz
curl -fsS -H "Authorization: Bearer pds_local_dev_token" http://localhost:8080/v1/templates

# the published SDKs read the endpoint and key from the environment
export PANDASTACK_API=http://localhost:8080
export PANDASTACK_API_KEY=pds_local_dev_token   # the local stub token the script seeds
pip install pandastack                          # or: npm install @pandastack/sdk

Self-hosting gives you data residency by construction, your own network policy, and a runtime you can read, patch and fork. Read the repository's limitations before you expose it to users: authentication is bring-your-own (a stub mode for local development, or JWT verification against your identity provider's JWKS), the access-control model is intentionally minimal, and hosts must have KVM. You also take on the hosts, upgrades, backups and on-call. App hosting, functions, schedules and a few managed-database features (branching, point-in-time restore to any second, connection hardening) are hosted-only.

Other options in this lane, per their own pages: E2B's runtime is Apache-2.0, with a single-machine Embed package that E2B describes as an evaluation package rather than a production deployment, and dedicated deployments run inside your own cloud account. Daytona's public repository states that it is no longer maintained as of June 2026, with core development moved to a private codebase. Building directly on raw Firecracker is the question in section 9. For a wider survey, see Best Self-Hosted Code Execution Sandboxes in 2026.

Security and compliance questions to ask any agent runtime

Procurement will ask these, so ask them of every vendor, including us:

1. What is the isolation boundary: a shared-kernel container, a user-space kernel such as gVisor, or a hardware-virtualized microVM with its own guest kernel?
2. Is outbound traffic open or default-deny, and can you allowlist domains per sandbox?
3. Can guest code reach the cloud metadata endpoint, or other tenants' VMs?
4. Does a sandbox carry any ambient cloud credentials?
5. Can every connection and CPU-second be attributed to one tenant?
6. Which certifications are held today, and can you self-host where a certification or residency rule rules out a managed service?

PandaStack's answers: each sandbox, app and database is its own Firecracker microVM with its own guest kernel. VM-to-VM traffic and the link-local metadata range are dropped at the top of the host firewall chain, and a VM has no cloud service account or instance credentials. Outbound traffic is open apart from the Stratum mining-port block, with no per-sandbox allowlist today, and egress is attributable to a specific VM and workspace. On compliance, there is a GDPR Article 28 DPA with Standard Contractual Clauses, a published subprocessor list and an RFC 9116 security.txt. PandaStack does not hold a SOC 2 report, ISO 27001 certification or HIPAA attestation, and will not claim one before an independent audit. Where that matters, you can self-host. The security page has the details.

What does an AI agent runtime cost? A worked example

PandaStack has one pair of meters for sandboxes, apps and databases: $0.054 per active vCPU-hour and $0.0162 per working-set GiB-hour, billed per second. Active means CPU-seconds your code actually burned; working set means memory actually resident, capped at the template's size. Network egress is metered but not billed. So one sandbox with one vCPU pegged and 1 GiB resident for a full hour costs at most $0.0702.

Take 200 agent sessions a day, each 30 minutes of wall clock on the code-interpreter template (2 GiB of RAM, 8 burstable vCPUs). The utilization figures are illustrative inputs, not measurements; plug in your own.

At agent-shaped utilization that is $2.16 a day, or $64.80 over a 30-day month. On the Pro plan the $20 monthly fee converts 1:1 into usage credit and the rest bills at the same rates, so the bill is about $65; on Team, the $99 fee covers it. Three things follow. First, the ceiling row costs more than 20 times the agent-shaped row: that gap is the difference between paying for what a sandbox could use and what it does use, and an agent waiting on a model burns very little CPU. Second, at that utilization memory costs three times as much as CPU, so a smaller working set saves more than a smaller CPU would. Third, the cheapest session is one that is not running: a persistent sandbox hibernated between turns bills no compute while hibernated, and hibernated state storage is currently included.

The Free plan includes $5.40 of monthly credit, caps sustained CPU at 2 cores and deletes sandboxes one hour after creation, so the ceiling row assumes Pro or Team. This example covers compute only; model tokens are billed by your model provider, and The anatomy of an AI agent's bill: tokens vs compute vs egress breaks down how they compare. The full rate card, plan credits and limits are on the pricing page.

Tying it together in code

Most of these capabilities show up in a handful of SDK calls. The flow below creates a sandbox with a TTL backstop and tenant metadata, prepares a repository, snapshots the warm state, fans candidate patches out across copy-on-write forks with explore(), and tears everything down. It uses the pandastack Python SDK, version 0.9.0. Command time limits are enforced inside the guest with coreutils timeout. exec() waits on a single HTTP request (the Python client's default timeout is 30 s, and the hosted API's edge cuts a request at about 100 s), so the long setup step uses exec_stream() and each test run is kept under 90 s.

from pandastack import Client, ExploreError, Sandbox, set_default_client

# exec() is one HTTP request that returns when the command exits, and the client's
# default timeout is 30 s. Raise it for the test runs below; sandboxes created after
# this call, and their forks, use this client.
set_default_client(Client(timeout=120))

# 1) CREATE: every create restores a baked snapshot (49 ms p50 server-side; see /benchmarks).
#    ttl_seconds reaps a leaked VM even if this process dies; metadata tags the tenant.
base = Sandbox.create(
    template="code-interpreter",
    ttl_seconds=900,
    metadata={"tenant_id": "acme", "task": "fix-flaky-test"},
)

try:
    # 2) EXEC: a long setup step goes through exec_stream(), which sends output as it
    #    arrives and returns the exit code. `timeout` runs inside the guest, so a hung
    #    install is killed there.
    code = base.exec_stream(
        "timeout 300 sh -c 'git clone --depth 1 https://github.com/your-org/your-repo /workspace/repo"
        " && cd /workspace/repo && pip install -r requirements.txt'",
        on_stdout=lambda s: print(s, end=""),
        on_stderr=lambda s: print(s, end=""),
    )
    if code != 0:
        raise RuntimeError(f"setup failed (exit {code})")

    # 3) SNAPSHOT: freeze the warm machine. Returns the snapshot id (a str).
    snapshot_id = base.snapshot()
    # later: Sandbox.create(template="code-interpreter", from_snapshot=snapshot_id)

    # 4) FORK (best-of-N): stage candidate patches, then run each in its own
    #    fork_tree child (memory + disk, copy-on-write). Every child inherits the
    #    clone and the install.
    patches = generate_patches()  # your model call; returns a list of diffs
    for i, diff in enumerate(patches):
        base.filesystem.write(f"/workspace/p{i}.patch", diff)

    try:
        result = base.explore(
            [f"cd /workspace/repo && git apply /workspace/p{i}.patch && timeout 90 pytest -q"
             for i in range(len(patches))],
        )  # each branch runs through exec(); default score: 1.0 if the command exits 0
        print("winner:", result.winner_outcome.label)
        result.winner.kill()  # promoted to an independent sandbox; losers already reaped
    except ExploreError:
        print("no candidate passed")
finally:
    # 5) TEARDOWN: memory, disk and network slot go with the VM.
    base.kill()

The TypeScript SDK (@pandastack/sdk) has the same shape. Here is a persistent per-user workspace that forks and then hibernates:

import { Sandbox } from "@pandastack/sdk";

// A persistent per-user workspace: never TTL-reaped; call hibernate() when idle.
const sb = await Sandbox.create({
  template: "code-interpreter",
  persistent: true,
  metadata: { tenant_id: "acme", user_id: "u_123" },
});

const r = await sb.exec("timeout 30 python3 -c 'print(2 + 2)'");
console.log(r.exitCode, r.stdout);

const [branch] = await sb.forkTree({ count: 1 });   // copy-on-write child with the parent's memory and disk (~400 ms)
await branch.kill();

await sb.hibernate();             // no compute billed while hibernated; the next request wakes it

Isolation does not appear in the code because it sits under every call: each create, fork and explore branch is its own VM. Network and egress policy is set at the platform level rather than per call, which is where it belongs, because the agent's code cannot talk its way around it.

The bottom line

An AI agent runtime turns a model's decision into an action on a real machine, and it sets the ceiling on safety, latency and cost for everything above it. Keep it separate from the framework, pick the category that fits (managed agent host, sandbox runtime, or your own assembly), and evaluate it against the nine capabilities above on your own workload. Benchmark every vendor's numbers, including ours, before you commit.