Runloop vs Daytona: Choosing an Agent Sandbox

Runloop and Daytona end up on the same shortlist because they arrive at the same destination from opposite directions. Runloop grew up around coding agents: devboxes shaped like a repository, blueprints so you stop reinstalling the same dependency tree, snapshots, and a visible orientation toward benchmarking and SWE-bench-style evaluation. Daytona grew up around developer environments — declarative workspaces, a self-hostable heritage, the sort of product a platform team adopts so humans stop saying "works on my machine" — and then, as agents started needing exactly that thing programmatically, presented it as a sandbox API. Today both will happily rent your agent a Linux box with a filesystem. The interesting question is what each one assumes you are doing with it.

Two origins, one overlapping product

Runloop: the agent's workbench

Runloop's framing is agent-first. The devbox is a place where an agent clones a repo, installs dependencies, edits files, runs a test suite, reads the failure, edits again, and eventually produces a diff. Blueprints exist because that install step is the single most expensive thing in the loop and doing it a thousand times is absurd. Snapshots exist because a warmed environment is worth more than a cold one. And the benchmark/eval orientation exists because the second question every agent team asks — right after "can it run?" — is "is it getting better?", and answering that honestly requires environments that are identical run over run. If you are building something that resolves GitHub issues and you care about your pass rate as a tracked metric, that orientation is not marketing garnish; it is the product.

Daytona: the environment, made programmable

Daytona started from a different complaint: developer environments are a mess, so declare them and let the platform reproduce them. That heritage brings two things worth caring about. First, declarative environment definitions — the environment is a described artifact rather than a pile of imperative setup commands that drifted three months ago. Second, a self-hostable lineage, which matters enormously to teams whose source code is not allowed to leave a VPC. The sandbox-API framing is newer than the dev-environment framing, and that is not a criticism; it is a fact about where the maturity is concentrated. If you want an environment that a human could also SSH into and be productive inside, that heritage is a feature.

So the honest summary of the overlap: Runloop optimises for an agent that works a repo and is measured on outcomes. Daytona optimises for a reproducible environment that happens to be driven by an agent. Both will run your build. The difference shows up in what is one API call versus what is three hundred lines of your own orchestration.

Isolation: which kernel does the untrusted code touch?

This is the first filter and almost nobody applies it first. A coding agent executes code nobody reviewed, which is the same threat model as code an attacker wrote, because a prompt-injected agent is an attacker holding your credentials and your network position. So the only question that matters is: when the model runs something stupid, what is the boundary it has to break?

There are broadly three answers in this category, and "sandbox" is used for all of them. A process-level sandbox (seccomp, namespaces, a hardened runtime) shares the host kernel — a kernel bug is a full escape. A container with a strengthened runtime is better but still fundamentally shares that kernel. A hardware-virtualized microVM gives the workload its own guest kernel behind a virtualization boundary, so an escape needs a hypervisor bug rather than a kernel bug — a much smaller and much more scrutinized surface.

Both Runloop and Daytona present themselves as real sandboxes rather than a chroot with good branding, and both treat untrusted execution as a genuine requirement. What I am not going to do is tell you which specific boundary you get on which plan, because that detail changes by tier, by region, and by release, and being confidently wrong about someone's security architecture is the worst possible way to be wrong. Ask each vendor directly, for the exact plan you would buy: does every sandbox get its own kernel, and does that answer change when I enable persistent storage, custom images, or self-host?

Cold start, warm start, and the number that actually bites

Cold-start figures on marketing pages are close to useless for this decision, because the three relevant events are not the same event. "Sandbox reachable" is not "repo cloned" is not "dependencies installed and the test suite is runnable." A platform that hands you a shell in 90 milliseconds and then makes you wait four minutes for npm install has not made your agent fast; it has made your agent's first log line fast.

So measure the thing that governs your loop. If your agent creates a fresh environment per tool call, create latency lands on every step and multiplies by forty. If your agent takes one environment and works in it for twenty minutes, create latency is a rounding error and rebuild cost is everything — which is precisely why Runloop invests in blueprints and snapshots, and why Daytona's declarative environments matter. Both are answers to "do not reinstall that dependency tree again."

There are three mechanisms behind any fast path, and it is worth knowing which one you are buying: cold boot (start a machine, install everything), image or blueprint pull (start from a prepared filesystem, skip the install), and snapshot restore (rehydrate a machine that was already warm, including memory, skipping both). Ask which backs the fast path, whether it is automatic or a pipeline you maintain, and what a cache miss costs. Then benchmark it yourself, with your repo, in your region, cold and warm. An afternoon of this settles more than a week of comparison posts, this one very much included.

#!/usr/bin/env bash
# The only benchmark that matters: YOUR repo, THEIR platform, both paths.
# Run it against each vendor's CLI/SDK and compare the two numbers, not the
# marketing page. Times are wall clock, which is what your users feel.

set -euo pipefail
REPO="git@github.com:acme/service.git"

bench () {
  local label="$1"; shift
  local start
  start=$(date +%s%3N)
  "$@" >/dev/null 2>&1
  echo "$label: $(( $(date +%s%3N) - start )) ms"
}

# 1. Time-to-shell (what the pricing page calls "cold start")
bench "create           " vendor-cli create --image ubuntu-22.04

# 2. Time-to-usable (what your agent actually waits for)
bench "clone            " vendor-cli exec -- git clone --depth 1 "$REPO" /work
bench "install          " vendor-cli exec -- sh -c 'cd /work && npm ci'
bench "first test run   " vendor-cli exec -- sh -c 'cd /work && npm test'

# 3. Warm path: does the second one skip steps 2 and 3, or repeat them?
bench "warm create      " vendor-cli create --from-snapshot warm-service
bench "warm test run    " vendor-cli exec -- sh -c 'cd /work && npm test'

Snapshots, and whether you can branch a running state

Snapshot is an overloaded word and the distinction is worth being pedantic about, because it is where the biggest capability gap in this whole category hides. There are three different things people call snapshotting.

• Image capture — freeze a filesystem into a reusable base. Every platform has some version of this. It is a build artifact, and starting from it still means booting a machine and starting your processes from scratch.
• Suspend and resume — pause an environment, stop billing for it, bring the same instance back later. Extremely useful for cost, since an agent environment is idle far more than it is busy.
• Fork — take one warmed state, memory and disk together, and produce N independent copies of it that diverge from that instant. This is the rare one, and it is the one that changes how you write an agent.

Runloop's snapshot-and-blueprint model is squarely aimed at the first two: get a warmed environment back cheaply, because rebuilding it is the expensive part of the loop. Daytona's declarative environments attack the same problem from the reproducibility side. Whether either exposes true fork — branch a live machine mid-execution, with its warm page cache and running process tree, into several independent children — is the single question I would put at the top of my evaluation checklist if I were doing best-of-N sampling, because the answer determines whether "try eight fixes in parallel" costs one dependency install or eight. Ask them; do not infer it from the word "snapshot" appearing on a features page.

Filesystem persistence and what survives what

A coding task is not one execution; it is forty of them with a filesystem in between. So persistence is not a nice-to-have, it is the substrate. Both products are environment-shaped rather than function-shaped, which means both give you a filesystem that survives across commands — that is the whole reason they beat a stateless execution API for this workload.

The distinctions to pin down are subtler. Does the filesystem survive a stop and start, or only a pause? Is there a volume concept separate from the root disk, so a rebuilt environment can reattach to accumulated state? What happens when the underlying host dies — is your workspace gone, or does it come back somewhere else? And critically for cost: does a stopped environment still bill for its stored disk, and at what rate? Storage is the line item people forget to model, and dependency trees are enormous. A team running two hundred idle agent workspaces with a full node_modules apiece can find that their storage bill quietly overtook their compute bill.

Network egress: the security review you have not had yet

A coding agent legitimately needs outbound network — npm, PyPI, your Git host, sometimes a model API — so "block egress" is not an available answer. What you actually need is control, and control has three components.

• Allowlisting — can you restrict egress to a set of destinations, per sandbox rather than per account, as a documented feature rather than a support conversation?
• Blast radius — if a prompt injection lands, can the sandbox reach your VPC, an internal service, or a cloud metadata endpoint? The metadata endpoint question in particular has ended more than one security review abruptly.
• Network identity — does each sandbox get its own address and network namespace, or do tenants share a NAT egress IP? If they share, one workload getting rate-limited or blocklisted by a package registry becomes everybody's problem, and you will spend a memorable afternoon proving it was not your traffic.

Ask both vendors these three questions in writing. Egress policy is the axis most likely to be under-documented relative to how much it matters, on every platform in this category including, historically, mine.

Self-host versus closed SaaS

For plenty of teams this is not a preference, it is a gate that ends the evaluation before latency gets a vote. If customer source code cannot leave your VPC, or if "a third party executes our code" is a procurement event with a six-week SLA, then the self-host answer decides everything else.

Daytona's dev-environment heritage includes a self-hostable story, and that is a genuine structural difference worth investigating carefully. But investigate it as three separate claims, because vendors routinely conflate them: (1) is there a public repository, (2) is the full execution plane self-hostable rather than just a client or a control shim, and (3) under what licence, on what upgrade path, with what support. A public repo containing the SDK is not a self-hostable platform. Runloop is positioned as a hosted product, so ask directly about on-prem or bring-your-own-cloud rather than assuming either way.

And be honest with yourself about the operational weight. I sell an open-source platform and I will still say it: self-hosting an execution plane means owning host provisioning, kernel updates, snapshot storage, capacity planning, and a pager. Under a real forcing constraint that is a trade worth making. Without one, it is an expensive way to feel in control.

Pricing shape (deliberately without numbers)

I am not quoting either vendor's prices. They change, they vary by plan and region, and a stale figure is worse than no figure. What is durable is the shape, and for agent workloads the shape is dominated by one variable almost nobody measures: duty cycle.

A typical agent step runs a command for a second or two, then waits ten to sixty seconds for a model response, then runs the next one. Across a session the environment is idle far more than it is busy — duty cycles of 5 to 15 percent are entirely normal and usually lower than people guess. So the question that dominates your bill is not the hourly rate; it is what an alive-but-idle environment costs. Per-second billing on active compute makes thinking time nearly free. Per-sandbox-hour or committed-capacity billing makes you pay full freight for your model's contemplation. Memory usually bills whenever it is resident regardless of CPU activity, which is the asterisk on every "scale to zero" claim in this industry, mine included — verify what "zero" means, precisely.

1. Instrument a real session: total execution seconds divided by total wall-clock seconds. That ratio is your duty cycle.
2. Price both vendors' models against that ratio rather than against a hypothetical busy hour. The cheaper vendor frequently flips when you do this.
3. Model storage separately — persisted dependency trees across many idle workspaces add up faster than compute.
4. Model egress separately — dependency installs pull a lot of bytes, and a bill that looks fine on compute can surprise you on transfer.
5. Check minimum billing granularity and any per-create overhead if you spin up thousands of short-lived sandboxes a day.

SDK ergonomics: where the glue code lives

Both give you an SDK, both let you create an environment and run commands in it, and at that level of description every sandbox API is identical. The real ergonomic difference is how much lifecycle bookkeeping ends up in your codebase: which environment belongs to which task, when it times out, what happens when it dies mid-build, how you stream output back, how you get artifacts out. A product shaped around your workload deletes that code. A product shaped around a different workload makes you write it.

Both snippets below are illustrative pseudo-code showing the silhouette of each style — not real API signatures. Check each vendor's current SDK docs for actual names and arguments.

# ILLUSTRATIVE PSEUDO-CODE - not a real API signature.
# Agent-devbox silhouette: the repo workflow is the product's opinion,
# so your code is mostly about the agent, not about lifecycle plumbing.

box = devbox.create(blueprint="acme-service-node20")   # deps pre-baked
box.exec("git checkout -b agent/fix-billing-flake")

for attempt in range(3):
    box.write_file("/work/patch.diff", model.propose_patch(attempt))
    box.exec("cd /work && git apply patch.diff")
    result = box.exec("cd /work && npm test -- --runInBand")
    if result.exit_code == 0:
        box.exec("cd /work && git commit -am 'fix flake' && git push")
        break
    model.observe(result.stdout[-4000:])

warm = box.snapshot()      # next task starts here instead of at npm ci
box.shutdown()

// ILLUSTRATIVE PSEUDO-CODE - not a real API signature.
// Declarative-environment silhouette: the environment is a described
// artifact, reproducible for a human or an agent, and the SDK drives it.

const ws = await client.workspaces.create({
  // The definition is data, not a pile of setup commands that drifted.
  image: "ghcr.io/acme/service-dev:2026.09",
  env: { NODE_ENV: "test", CI: "1" },
  resources: { cpu: 4, memoryGb: 8 },
  autoStopMinutes: 30,          // idle policy is a first-class field
});

await ws.process.exec("git clone --depth 1 https://github.com/acme/service /work");
const build = await ws.process.exec("cd /work && npm ci && npm run build");
console.log(build.exitCode, build.stdout.slice(-2000));

await ws.fs.upload("/work/patch.diff", patchBytes);
const tests = await ws.process.exec("cd /work && npm test");

await ws.stop();               // filesystem persists; verify what billing does

Side by side

Orientation, not a spec sheet. Every Runloop and Daytona line here is qualitative and reflects public positioning as of writing — verify each one against current docs. The PandaStack lines are things I can measure, which is exactly why you should discount them accordingly.

• Isolation boundary — Runloop: positions toward strong isolation for agent-written code; confirm on your plan which kernel the workload touches. Daytona: sandboxed environments with a dev-environment lineage; confirm the boundary, and whether it changes when self-hosted. PandaStack: a Firecracker microVM per sandbox with its own guest kernel behind hardware virtualization, on every plan and when self-hosted.
• Cold start — Runloop: blueprints and snapshots are the fast path; measure time-to-usable, not time-to-shell. Daytona: fast environment creation is a core pitch; same caveat. PandaStack: every create is a snapshot restore, not a boot — 179ms p50, about 203ms p99, of which the restore step is roughly 49ms. Only a brand-new template's first spawn does a real cold boot, around 3 seconds.
• Warm start / rebuild cost — Runloop: blueprints exist precisely to kill the reinstall, which is the loop's dominant cost. Daytona: declarative definitions plus prepared images. PandaStack: restore-from-snapshot is the only create path, so warm is the default rather than an optimisation you configure.
• Fork a running state — Runloop: snapshotting is present; ask specifically whether N children can diverge from one live memory state. Daytona: same question, same reason. PandaStack: first-class — same-host forks land in 400-750ms, cross-host in 1.2-3.5s, with memory copy-on-write and reflinked disks so the eighth fork is not the eighth copy of your toolchain.
• Filesystem persistence — Runloop: devboxes are persistent by framing; the whole point is state between steps. Daytona: workspace-shaped with a persistent filesystem, from its dev-environment roots. PandaStack: your call — TTL-ephemeral, persistent, or hibernated to object storage and restored later.
• Network egress control — Runloop: ask about per-sandbox allowlisting and shared NAT identity. Daytona: same questions, plus what changes under self-host. PandaStack: per-sandbox network namespace by construction, 16,384 pre-allocated /30 subnets per agent host, so network identity is never shared between tenants.
• Self-host — Runloop: positioned as hosted; ask directly about on-prem or BYOC. Daytona: self-hostable heritage is a genuine differentiator — verify licence, scope, and upgrade path as three separate claims. PandaStack: Apache-2.0 core, runs on your own KVM hosts, with all the operational weight that implies.
• Pricing shape — Runloop and Daytona: read the current pricing pages; the axis that matters is what an idle environment costs, since agent duty cycles are low. PandaStack: per-second on active CPU plus committed memory, with scale-to-zero meaning the VM is gone and its state is a file in object storage.
• SDK ergonomics — Runloop: agent-and-repo-shaped, so repo workflows and eval harnesses need less glue. Daytona: environment-shaped and declarative, which suits reproducibility and human-plus-agent use. PandaStack: a deliberately small primitive — create, exec, filesystem, snapshot, fork, kill — which means more glue for repo workflows and more control over the machine.
• Best fit — Runloop: agents that resolve issues against a repo and are measured on a pass rate. Daytona: reproducible environments shared by humans and agents, especially where self-hosting is a gate. PandaStack: untrusted code needing a hardware boundary per task, branch-heavy workloads, or a hard data-residency constraint.

Which one fits your situation

Map your situation to the product rather than the reverse:

• Your agent's job is "open a PR against this repo" and you track a pass rate over a benchmark suite — Runloop, whose devbox, blueprint, and eval orientation is shaped exactly like that loop. Building an eval harness on a generic sandbox API is a genuine project you should not volunteer for casually.
• You need environments that are reproducible artifacts, used by humans as well as agents, and defined declaratively rather than as accumulated setup commands — Daytona, whose entire heritage is that problem.
• Source code cannot leave your infrastructure — Daytona's self-hostable lineage puts it ahead of a hosted-only product before any other axis is considered, but verify the three claims above rather than assuming.
• You are running many short, independent executions rather than long repo sessions — neither is wrong, but weigh a general execution-sandbox API too, and pay close attention to per-create overhead and billing granularity.
• You need a hardware kernel boundary per task, or you want to branch a live warmed machine N ways — that is where I would put a microVM platform in the evaluation, mine included, with the caveats below.
• Your real workload is GPU inference with an agent attached — none of these three; look at a GPU platform and keep a sandbox for the untrusted-code tier only.

Where PandaStack sits (the short, skippable part)

Since I build a third option, here it is in one section instead of smeared through the post. PandaStack is a Firecracker microVM platform with an Apache-2.0 core you can run on your own KVM hosts. Every sandbox is a hardware-isolated VM with its own guest kernel. There is no warm pool of idle VMs standing by: every create restores a baked snapshot, which is why end-to-end create measures 179ms at p50 and about 203ms at p99, with the restore step itself roughly 49ms. The only slow path is a brand-new template's first cold boot, around 3 seconds, after which its snapshot exists and every create is a restore. Because whole-VM state is snapshottable, forking is first-class — same-host forks in 400-750ms, cross-host in 1.2-3.5s — which is how you branch an agent's warmed workspace to try several fixes concurrently instead of serially rolling back. Networking is per-sandbox by construction, with 16,384 pre-allocated /30 subnets per agent host, and managed Postgres lives on the same substrate (30-90s to create) so an agent that needs a real database to test against does not need a second vendor.

from pandastack import Sandbox

# Hardware-isolated Firecracker microVM, created by snapshot-restore.
# create p50 179ms / p99 ~203ms - there is no warm pool to hit or miss.
sbx = Sandbox.create(template="base", ttl_seconds=600)

try:
    sbx.filesystem.write(
        "/work/run.sh",
        "#!/bin/sh\nset -e\ncd /work/repo\nnpm ci --silent\nnpm test\n",
    )

    result = sbx.exec("sh /work/run.sh")
    print(result.exit_code)
    print(result.stdout[-2000:])

    # Only the artifact crosses back to the trusted side.
    diff = sbx.exec("cd /work/repo && git diff")
finally:
    sbx.kill()   # ttl_seconds is the backstop for when this line never runs

The ttl_seconds argument is not decoration. Your orchestrator will eventually die between create and kill, and when it does the VM still needs to expire on its own. Cleanup is the least-run and least-tested path in every system, and it is always the one holding the bill.

Now the part that makes the rest of this credible — where we lose. We do not have Runloop's agent-evaluation orientation; if you want a benchmark harness with repeatable graded environments, you would be building that on top of us, and that is real work. We do not have Daytona's declarative dev-environment maturity; our unit is a machine, not a described workspace a human developer would want to live in daily. We have no GPUs. And self-hosting is genuine operational weight: hosts, kernels, snapshot storage, capacity planning, and a pager at three in the morning. If nobody on your team wants that job, a hosted product is the correct answer and you should choose between Runloop and Daytona on the axes above without another thought about us. PandaStack earns its slot when hardware isolation per task, VM-level branching, or self-hosting is a genuine forcing constraint — not because open source is a personality trait.

The bottom line

Runloop and Daytona are both real products built by people who understood a real problem, and the choice between them is mostly about which problem you have rather than which team is better. If your agent works a repository, produces diffs, and you are measured on how often it succeeds, Runloop's agent-and-eval orientation removes work you would otherwise write yourself. If your constraint is reproducible environments — especially reproducible environments running inside your own infrastructure, used by humans as well as agents — Daytona's declarative, self-hostable heritage is the stronger structural fit.

Then do the boring thing that actually decides it. Build the smallest real version of your agent loop against both. Measure time-to-usable rather than time-to-shell, with your repo and your dependency tree. Instrument your duty cycle and price both models against that ratio instead of a hypothetical busy hour. Read the security page for the exact plan you would buy, and get the isolation answer in writing if compliance depends on it. That afternoon will settle more than a week of reading comparison posts — very much including this one.