Genspark SB-Box: Sandboxes That Freeze and Resume

Agents that write and run code need somewhere safe to run it. For the past two years the standard answer has been a sandbox: a disposable, isolated environment that the agent can install packages in, write files to and, if it misbehaves, be thrown away without harm. Genspark, the AI workspace company whose agent products we covered in our Genspark AI Workspace 6.0 review, has now productised its own version as SB-Box, a beta service described on its intro page as "isolated sandboxes for agents".

The pitch has four parts. Every sandbox is a full virtual machine with its own kernel rather than a container. Creating one restores a snapshot instead of booting, which Genspark says takes 0.35 seconds at the median for a 4 GB machine. A sandbox can be frozen, keeping its memory, processes and disk while billing only for disk, and resumed in about 0.8 seconds. And every freeze is a saved version that can be forked into an independent machine or rolled back to.

That combination, cheap start plus durable pause, is what makes the product interesting. It turns a sandbox from a disposable tool into something closer to a persistent employee workstation that an agent can leave and return to. The caveats are equally clear: it is a beta, it needs a paid plan, the REST API is explicitly described as beta with rough edges, and every performance figure is Genspark's own measurement.

This article walks through the architecture as documented, the developer workflow, the security model, the pricing and plan facts we could verify, the limitations, and how SB-Box fits into the broader race to give agents safe, persistent computers, a theme running through our coverage of Kimi K3's sandbox escape and Genspark's GenOffice.

Agentic coding and computer-use tools share a structural problem. The model generates code, but something must execute it, and executing arbitrary model-written code on a laptop or a shared server is risky. At the same time, useful agent work is long and stateful: an agent may spend an hour setting up a data environment, then need to come back to it a day later with variables, open files and a half-finished analysis intact.

Containers solve isolation partially and statefulness poorly. They share the host kernel, so a kernel-level vulnerability or a misconfiguration can cross the boundary, and when a container stops, its in-memory state is gone. Rebuilding that state is slow and expensive, and for an agent it means re-reading files, re-importing libraries and re-deriving context that cost tokens to build.

The industry has responded with micro-virtual-machine platforms. Genspark itself has said publicly, via a customer story published by sandbox provider E2B, that its agents have run in E2B's Firecracker micro VMs, with each agent session in its own isolated VM. SB-Box can be read as Genspark bringing that layer in-house and exposing it to developers. Genspark's documentation does not say whether SB-Box runs on the same underlying technology, so treat that connection as context, not fact.

Genspark's intro page organises the product around four pillars. We summarise each, noting where the claim is a design statement and where it is a measured figure.

Every sandbox is a full virtual machine with its own kernel. A template is the snapshot of a machine that was already running your start command. Creating a sandbox restores that snapshot, with memory arriving on demand as the machine touches it, and the hot set preloaded from the template's own warm-up runs. Genspark reports that a 4 GB machine is up in 0.35 seconds median, 0.43 seconds at the 90th percentile and 0.70 seconds at the 99th, measured at the platform, with the public API and your network round trip adding a few hundred milliseconds. Resume from frozen uses the same mechanism: 0.8 seconds median and 1.7 seconds at the 90th percentile.

The technical idea, restoring a process snapshot and lazily faulting in memory pages, is well established in virtualisation research. Its practical effect is that start-up cost no longer scales with how heavy the environment is. A template that has already installed pandas, loaded a model and started a server restores just as fast as an empty one.

Freeze saves only what changed since the template, then releases the machine. A frozen sandbox keeps its processes, memory and disk and bills only its disk. Resume continues where it stopped. Every freeze is a version: clone forks any version into an independent machine, rollback returns to one, and reset wipes processes but keeps the disk. Memory snapshots expire after 14 days frozen; the disk stays.

Incremental snapshots and copy-on-write forks are what make this affordable. Because only deltas are stored, a version costs roughly the size of what changed rather than the size of a whole machine. That makes branching practical: an agent can fork a known-good state, try a risky approach, and discard it if it fails.

A sandbox freezes on its own after 10 to 15 minutes idle, or when its lifetime deadline passes, depending on whether the onTimeout setting is freeze or kill, and it exits when its init process exits. Nothing needs resuming by hand: the next command, file operation or HTTP request to one of its port URLs resumes a frozen sandbox first, which Genspark says takes about four seconds end to end for that first call. A metrics sample every five seconds records CPU, memory and disk. The documentation adds that a zero credit balance also freezes a sandbox.

The four-second figure for the first call to a frozen sandbox, versus 0.8 seconds for an explicit resume, is worth noticing. The first includes request routing and platform overhead. For interactive use that is fine; for a tight loop of tiny calls you would keep the sandbox running.

Templates build from any public Docker image or Dockerfile. Hardware virtualisation gives each sandbox its own kernel, so untrusted code never shares one with a neighbour. Egress is a per-sandbox policy with allow lists, deny lists or no internet at all. Anything listening on a port is reachable at a per-sandbox URL, and setting allowPublicTraffic to false places a per-sandbox traffic token in front of every port URL. The exec call returns stdout, stderr and the exit code, and streaming exec, background commands and a WebSocket terminal cover interactive needs.

The container-native part is strategically sensible. Developers already describe environments as Dockerfiles; being able to turn one into a snapshot-restorable VM removes a migration barrier.

SB-Box is driven by one token across three surfaces: a web console, the gsk command-line tool, and a REST API at genspark.ai/api/sb-box/v1. The documentation describes the CLI and console as the stable surfaces and the REST API as beta, with fields that may still be added.

The quick start is short. Install the CLI with npm install -g @genspark/cli and sign in with gsk login. Running gsk sb-box create with no template starts from the newest public base image, described as Ubuntu 24.04 with Python 3 (including numpy, pandas and matplotlib), Node 22 and git. The documentation's example sandbox has 2 CPUs, 4,096 MB of memory and a 20 GB disk. You then run commands with gsk sb-box exec, move files with write, read and ls, and end the session with kill.

Custom environments use templates. You can build one with gsk sb-box build-template from a Docker image, with a start command and a readiness check, for example installing pandas and matplotlib on python:3.12-slim and then signalling readiness. Every sandbox created from that template starts with the packages installed and the runtime warm, which is the recommended pattern for anything you will start more than a few times. Installing at runtime works but is lost when the sandbox is killed and is repeated for every new sandbox.

A notable convenience is the agent-skill install. Running a one-line script in a project writes a single SKILL.md file into an opencode project, after which a coding agent can run generated code on an SB-Box sandbox instead of the developer's laptop. A session name keeps one sandbox per task so the model never handles an ID, and a run-code command provides a stateful Python interpreter where variables and DataFrames persist between calls like a notebook. This is the same skill-file pattern used across the agent ecosystem, which we covered in our OpenClaw 2.0 coverage.

Binary files move through the REST API, which streams request bodies byte for byte; text files go through the CLI's write and read commands. Because the sandbox is a separate machine, nothing from your working directory is visible there until you copy it in, a design choice that is good for isolation and a small tax on convenience.

The most novel feature is treating a running machine as versioned data. It is worth walking through what that enables, with the caveat that these are our analyses of documented behaviour rather than tested results.

• Long-running agent tasks. An agent that sets up a research environment can freeze it overnight, paying only for disk, and resume with interpreter variables and shell history intact, within the 14-day memory window.
• Safe experimentation. Fork a version into a clone, let the agent attempt a destructive migration, and roll the original back if it goes wrong.
• Parallel search. Fork one prepared state into many independent machines, each exploring a different strategy. Genspark's own intro page describes a training run handed one environment to fork as one of its three headline scenarios.
• Cost control. Idle auto-freeze means forgotten sandboxes stop burning compute after 10 to 15 minutes, and a zero credit balance freezes rather than deletes.

There are limits worth knowing. A killed sandbox is final: its disk and versions are gone and there is no un-kill. Memory snapshots expire after 14 days untouched, after which only the disk survives and only the owner's reset revives the machine. And a frozen sandbox still bills for disk, so a large fleet of long-frozen machines is not free.

The 14-day memory limit also shapes how you should think of it. SB-Box is not a place to park a stateful process indefinitely; it is a way to make pauses cheap. Anything that must survive longer needs to be written to disk or an external store.

Isolation is the headline reason to use a sandbox, and the documentation is direct about the model. Each sandbox is its own virtual machine with its own kernel; sandboxes never share a kernel. Genspark states that it never reads the data in your sandboxes, and that access beyond the owner requires explicit grants, with their own tokens.

The defaults deserve attention. Outbound internet access is on by default and public port URLs are on by default. If an agent is handling sensitive material, you should restrict egress with allow lists or disable it, and set allowPublicTraffic to false so port URLs require a token. Genspark's own guidance is not to copy into a sandbox any long-lived credentials you would not put on a shared server. We agree: the sandbox protects your machine from the agent, but it does not by itself protect secrets you give the agent.

The broader context matters too. Recent incidents have shown that capable agents probe their boundaries; our report on Kimi K3's sandbox escape is one example. A hardware-virtualised boundary is a stronger starting point than a shared-kernel container, but no isolation layer should be treated as absolute, and network egress policy is often the more important control than the kernel boundary.

Finally, remember that the security of the platform itself is Genspark's. We found no independent audit or penetration-test report for SB-Box. For regulated workloads, ask the vendor for one.

Availability is the clearest verified fact. According to the documentation, SB-Box is available on paid plans: Plus, Pro, Team and Enterprise. A Free account receives a 403 error with a sb_box_plan_required code on every call that creates or runs something, though reads, freeze, kill and template deletion still work. Accounts also need SB-Box enabled, otherwise calls return a not-enabled error.

On cost, the documentation establishes the structure rather than the rates: a running sandbox is billed for compute, a frozen sandbox is billed only at the disk rate, and usage draws on the account's credit balance, which you can see with gsk login-info. A GET /limits call shows your plan, its caps and your current usage. We did not find per-hour rates in the pages we reviewed, so we are not quoting a price; check Genspark's pricing page, and note that any figure quoted in pounds will depend on plan and exchange rate.

The structure is nonetheless informative. Because freezing converts compute billing into disk billing, the economic sweet spot is bursty, interactive agent work with long idle gaps, which is exactly how people use assistants. Always-on workloads such as a continuously running server would not benefit from freezing and are better priced against conventional cloud instances.

The numbers circulating about SB-Box come from Genspark's own pages: 0.35 seconds median create for a 4 GB machine (0.43 seconds p90, 0.70 seconds p99), 0.8 seconds median resume (1.7 seconds p90), and about 4 seconds end to end for the first call that wakes a frozen sandbox. The documentation is careful to say the create figure is measured at the platform and that the public API and your round trip add a few hundred milliseconds.

We found no third-party benchmark of these figures. That is normal for a product in beta, but it means they should be treated as targets you should verify under your own workload. Percentile reporting is a good sign, since it shows Genspark is not only quoting a best case; the 99th-percentile figure of 0.70 seconds is the honest one to plan around.

Real-world latency will also depend on template size, memory pressure, region (the documentation lists westus2 as the default), and what your start command warms. A template that preloads a large model may behave very differently from the 4 GB base. Run your own tests with the metrics endpoint before committing to a design that assumes sub-second restores.

Against a plain Docker container, SB-Box offers a stronger isolation boundary and durable memory, at the cost of dependence on Genspark's platform. Against self-managed micro-VM stacks such as Firecracker, it offers the same class of isolation without the operations burden, but with less control. Against third-party agent sandbox providers, which already offer fast starts and pause features, SB-Box competes mainly through integration with the rest of the Genspark ecosystem and its credit billing; we did not run head-to-head tests, so we make no claim about relative speed or price.

The more important comparison is with the way agents are used in practice. Platforms like Genspark's workspace, covered in our AI Workspace 6.0 article, and enterprise offerings such as NVIDIA's NemoClaw all need a trustworthy execution layer. Whoever owns that layer controls cost, safety and lock-in. SB-Box is Genspark's bid to own its own, and to rent it to others.

Data analysis agents. The stateful run-code interpreter is a natural fit: load a dataset once, freeze, and return to ask follow-up questions without reloading. Coding agents. Running generated code on a remote sandbox keeps your laptop clean and lets you run many tasks in parallel. Evaluation and training environments. Forking a prepared environment into many identical machines is the standard shape of agent evaluation and reinforcement-learning rollouts. Preview environments. Port URLs let an agent build a web app and share a live link, which suits the demo-driven workflows popular with creators. Long-lived assistants. A per-user machine that sleeps between interactions is a plausible architecture for personal agents, within the 14-day memory limit.

What it is less suited to: latency-critical production serving, workloads needing GPUs (the documentation we reviewed describes CPU and memory sizing, and we did not see GPU options), and anything requiring guaranteed indefinite process uptime.

Beta status. The REST API is beta and the documentation has its own section on rough edges. Paid plans only. No free tier for creating sandboxes. Vendor-reported performance. No independent benchmarks. Memory expiry. 14 days frozen, then disk only. Default openness. Internet access and public port URLs are on unless you change them. Unknown rates. We could not verify per-unit pricing. Lock-in. Templates and the gsk tooling are Genspark-specific, although Docker-image templates soften this. Regions. The documentation lists a default region, westus2, and we did not verify others, which matters for data-residency and UK or EU compliance questions.

The honest bottom line on risk: for experimentation and internal automation the downside is small; for production or regulated workloads, wait for GA, independent testing and a clear data-processing agreement.

Try it now if you already pay for a Genspark plan, build coding or data agents that need isolated execution, want pause-and-resume without maintaining infrastructure, or need many identical environments for evaluation. Wait if you need GPUs, strict data-residency guarantees, a free tier, or independently verified performance. Skip it if your agents never execute code, or if a simple container already meets your isolation needs. Browse alternatives and related tools in our AI tools directory and the Genspark tool profile.

SB-Box is a thoughtful piece of agent infrastructure: real virtual machines, snapshot-based starts, and a Freeze feature that treats a running machine as versioned, forkable data. If Genspark's numbers hold up, it removes two of the biggest frictions in agent sandboxes: slow start-up and lost state. Today the evidence is Genspark's own documentation, the product is in beta, and it sits behind a paid plan. That is enough to justify a serious trial for agent builders, and not yet enough to bet production workloads on it. Verify the speed claims on your templates, lock down egress, and keep long-lived secrets out of the box.