Research-backed calculator guide

Persistent vs Ephemeral Agent Sandboxes: Price Rebuilds, Idle Time and State Reuse

A practical cost model for choosing persistent or ephemeral agent sandboxes, including rebuild work, idle time, storage, state reuse, and a worked monthly example.

What actually persists?

“Persistent sandbox” is not a single technical promise. Separate the state you need before assigning a price. A retained filesystem can preserve a repository, installed packages, build artifacts, and notes. It does not automatically preserve an in-memory process, an open socket, a network identity, or a database transaction.

Microsoft Foundry’s hosted-agent documentation is a useful concrete example: a session persists its filesystem across turns and idle periods, can last up to 30 days, and suspends compute after the configured idle timeout while saving state for later restoration. That is filesystem/session persistence, not a promise that every process remains continuously active. ^[1] A separate Microsoft Code Interpreter page describes a different session pattern: the tool session is active by default for one hour with a 30-minute idle timeout and carries additional charges beyond token fees. ^[2] The lesson is to record the provider’s exact session, timeout, and persistence semantics instead of treating “sandbox” as a universal billing unit.

For a cost model, label each state layer:

• Workspace files: repositories, generated files, local databases, and package caches.
• Runtime state: running processes, warm memory, sockets, and service supervisors.
• External state: object storage, databases, queues, logs, and agent memory.
• Security state: credentials, package provenance, network policy, and approvals.

An ephemeral runtime can still write durable results to external storage. A persistent volume can still be attached to a short-lived worker. Those designs are neither fully ephemeral nor fully persistent, so price the compute and durable state independently.

The cost model: five buckets to measure

1. Rebuild and cold-start work

Count everything that must happen again after an ephemeral teardown. Include image retrieval if it is billable, repository checkout, package installation, browser or model cache warming, dataset staging, migrations, and agent context reconstruction. Measure elapsed setup time and resource usage rather than assuming “cold start” means only VM boot.

If a task spends 90 seconds installing dependencies and 10 minutes doing useful work, the 90 seconds is 13.0% of the sandbox’s total runtime. At 100 repeated tasks, that setup becomes 150 minutes of monthly execution before you count model calls or tests. A persistent workspace may pay the installation once, but it also needs a reset path when the environment drifts.

2. Active compute and provisioned resources

Providers meter these differently. Cloudflare Containers says CPU is based on active usage while memory and disk are based on provisioned resources; charges start when the instance is started and stop when it sleeps. ^[3] Modal’s sandbox guidance says charges use the greater of requested and actual CPU/memory, and its pricing page publishes separate CPU, memory, volume, and network rates. ^{[4] [5]}

Therefore, record at least requested CPU, actual CPU, requested memory, actual memory, runtime seconds, and the provider’s minimum billing increment. A persistent sandbox that waits on model responses may still incur provisioned-memory charges even when active CPU is low. An ephemeral sandbox may save those waiting costs by ending immediately, but pay setup again on the next task.

3. Retained storage and snapshots

Storage is the price of remembering. Count the logical data retained, not just the disk size you provisioned, when the provider bills logical usage. Add snapshot or backup storage, read/write operations, replication, and the retention period. Also price deletion: a stale volume that remains for 45 days is not free merely because the agent is no longer using it.

A useful policy is to separate “resume tomorrow” from “archive for 90 days.” The former may justify a warm or paused workspace; the latter may be cheaper in object storage or a database. Never treat the sandbox filesystem as the only system of record for user work.

4. Idle and waiting time

Idle time is not one thing. A sandbox waiting on a model call may use almost no CPU but still reserve memory. A stopped persistent sandbox may incur only storage. A provider may pause automatically, or your application may need to call stop explicitly. Measure active time, waiting time, paused time, and retained time separately.

Use the provider’s own definitions. Cloudflare documents automatic sleep and separate active CPU, provisioned memory, and provisioned disk meters. ^[3] Modal says its sandbox resource requests are charged for the sandbox lifetime when explicitly requested, while omitted requests use a small minimum and can burst based on actual use. ^[5] This is why an idle-time assumption must sit next to the calculation, not hide inside a single hourly rate.

5. State export, reset, and cleanup

A persistent workspace reduces rebuilds only if its state is trustworthy. Add the engineering time to snapshot, validate, restore, rotate credentials, quarantine a poisoned dependency, delete abandoned workspaces, and detect failed teardown. Add egress or object-store transfer when results leave a worker.

For untrusted or model-generated code, cost is not the only decision. Persistent state can carry a malicious install script or a secret into the next session. Ephemeral deletion limits retention, but it does not replace runtime isolation, least-privilege credentials, or egress controls. Budget security review and incident response as operating costs even if a provider does not place them on the invoice.

Worked cost example

Assume a US workload in which one project runs 20 agent tasks per month. Each task needs 10 minutes of active work and 90 seconds of setup. The persistent design performs the 90-second setup once, keeps a 5 GiB workspace volume, stops compute between tasks, and has no snapshot or egress charge in this simplified comparison. The ephemeral design destroys the workspace after every task.

To make the arithmetic inspectable, use Modal’s published Sandbox non-preemptible rates as an illustrative rate basis checked on 2026-11-02: $0.00003942 per physical CPU-core-second and $0.00000667 per GiB-second of memory; Modal notes that one physical core is equivalent to two vCPUs and lists volume storage at $0.09 per GiB-month. ^[4] This is not a universal sandbox quote and excludes plan credits, network, image transfer, model tokens, and application labor.

The persistent design saves 1,710 seconds of compute, worth about $0.1130 at these assumptions, but adds $0.45 of monthly storage. Under this deliberately simple rate basis, ephemeral is cheaper by about $0.337 per month. That does not mean ephemeral is always cheaper. If the workspace were 200 GiB, if storage were replicated, or if rebuilding required additional paid services, the result would change. If the persistent sandbox remained running between tasks, idle compute could also erase the apparent benefit.

The more important output is the break-even test. Let S be setup seconds avoided per month, R the combined compute rate per second, and D the incremental persistent storage and lifecycle cost. Persistence saves money only when S × R > D, after adding any persistent idle, backup, reset, and security costs. In this example, the avoided setup would need to exceed the $0.45 storage charge plus any other persistent costs. The task count, setup duration, memory shape, and storage size are the levers to change in your own worksheet.

When a hybrid design is the better economic choice

A durable workspace plus ephemeral workers can avoid the worst cost on both sides. Keep the repository, approved dependencies, and user-visible artifacts in one controlled workspace. Launch disposable workers for test matrices, untrusted uploads, evaluations, and parallel candidate branches. Return only reviewed artifacts or test results.

This pattern also makes attribution clearer. The workspace carries storage and occasional resume compute. Each worker carries its own active execution and cleanup. You can then compare cost per accepted change, cost per successful task, or cost per evaluation rather than hiding failed rebuilds in a shared monthly total. If budget variance matters, pair the estimate with the AI agent budget guardrail and P95 calculator. If setup is part of development rather than production execution, compare it with the AI agent development cost estimator.

The hybrid still needs lifecycle controls. Give persistent workspaces an idle timeout, maximum age, storage quota, reset command, and deletion owner. Give ephemeral workers a hard TTL, retry-safe cleanup, scoped credentials, and a record of the parent task. Reconcile provider invoices against these lifecycle events with the AI API invoice reconciliation calculator when sandbox charges appear alongside model and tool usage.

FAQ

Is a persistent sandbox cheaper than an ephemeral sandbox?

Not by definition. Persistence can avoid repeated setup, but it can add storage, snapshots, idle memory, backup, cleanup, and security-review cost. Compare the avoided rebuild seconds with the full incremental persistent bill under the same resource shape.

What should count as ephemeral sandbox setup cost?

Count repository checkout, dependency installation, image or dataset preparation, cache warming, migrations, and agent-state reconstruction. Include paid network or storage operations if your provider meters them. Do not count only VM boot time when most of the cold-start tax is package or data preparation.

Does a persistent filesystem keep processes alive?

Usually not automatically. A retained filesystem and a continuously running process are different capabilities. Microsoft’s hosted-session model saves filesystem state while deprovisioning compute after idle timeout, so a later resume can restore files without implying that every process remained in memory. ^[1]

Can an ephemeral sandbox use persistent storage?

Yes. A short-lived worker can write results to a database, object store, queue, or mounted durable volume. Price the worker’s compute and the external storage separately, then include transfer and retention when applicable.

How should I account for idle time?

Split it into active CPU time, provisioned memory time, paused storage time, and retained-data time. Use the provider’s meters rather than one blended hourly assumption. Cloudflare, for example, distinguishes active CPU from provisioned memory and disk. ^[3]

When should I choose a persistent workspace?

Choose it when users or agents repeatedly return to the same repository, dependency tree, build cache, or approved intermediate artifacts, and the value of state reuse exceeds storage and lifecycle controls. Use an ephemeral worker for isolated tests or untrusted execution even when the parent workspace is persistent.