A sandbox lifetime is a workflow decision: using Never in Lizard

Lizard — Tue, 06 Oct 2026 15:46:31 +0000

A build is still running. An agent is waiting for a review. Your laptop needs to close. These are different events, but a fixed sandbox expiry can turn all three into the same problem: the working environment disappears before the task is finished.

We're the team behind Lizard (lizard.build). Our latest update highlights the Never option for automatic deletion in Lizard Sandboxes. It lets you keep the lifetime of a cloud workspace under your control instead of tying it to a fixed expiration timer.

What Never changes

In the dashboard, choose Never under Delete Sandbox after when creating a sandbox. This disables scheduled expiry. It does not stop running compute charges, and it is not a guarantee against service interruptions or application failures.

With the Lizard CLI, the corresponding creation flag is --timeout 0. For example:

lizard sandbox create --size small --timeout 0

This is a creation-time choice. It is useful to make the lifetime explicit in your setup instructions: the current CLI default is a five-minute lifetime, not an indefinitely running workspace.

If you use a coding agent with the CLI, you can ask it to create a Small sandbox that never expires. Check the resulting lifetime setting rather than assuming the agent selected it.

Expiration, execution and saved state are separate

Consider an illustrative development task: an agent installs dependencies, starts a long build, then waits for a person to review the result. A lifetime policy should account for that wait, not just the expected build time.

Three decisions matter:

Lifetime: when should this workspace be automatically deleted?
Execution: does the process need to keep running while you are away?
Saved state: what needs to survive a pause, interruption or eventual deletion?

Never answers the first question. Closing a laptop does not itself pause a cloud process. If the process keeps running, running compute remains billable.

The update also describes pausing a supported sandbox and resuming it later with memory and files retained. Check compatibility before building a workflow around this: the current CLI guide says the snapshot-based pause/resume workflow does not support attached Persistent Volumes. Keeping a workspace available and exporting important outputs are still separate responsibilities.

Make the running cost visible

At the Small compute rate of $0.009 per hour, continuous execution for a 30-day month works out to:

30 days × 24 hours × $0.009 = $6.48

That is the approximately $6.50 figure in the announcement. It is a compute-only calculation, not an all-inclusive account bill. Plan charges, storage and other resources must be considered separately. Running compute is metered per second.

A practical policy is to use Never for work that spans unpredictable waits, then explicitly review and delete workspaces when the task is finished. A workspace without an expiry timer still needs an owner and a cleanup decision.

Try it on a task with a real wait

Choose a development task that includes both computation and human review. Create the workspace with the lifetime you intend, save a useful artifact, and check whether pausing is supported by that configuration before relying on it.

Read the original announcement or explore Lizard Sandboxes.

Lizard sandboxes: separate kernels, ready-to-run agents, and resumable work

Lizard — Mon, 05 Oct 2026 16:08:50 +0000

An AI coding agent needs somewhere to run its commands. Once it can install packages, execute generated code, or drive a browser, that environment becomes part of your application's design.

We're the team behind Lizard. Our latest sandbox announcement focuses on three parts of that environment: a separate kernel for each sandbox, templates for different workloads, and the ability to pause and resume work.

One Firecracker microVM per sandbox

The announced architecture runs each sandbox in its own Firecracker microVM with its own kernel.

That distinction matters when evaluating execution environments. With conventional container isolation, workloads can share the host kernel. A microVM introduces a guest kernel and a virtualization boundary. Firecracker is designed around lightweight virtual machines; you can read about its architecture in the Firecracker project documentation.

An isolation boundary does not replace application-level access controls. If you give an agent a production credential, its sandbox can still use that credential. Scope the permissions you pass into the environment to the task the agent needs to complete.

Choose a template around the workload

A sandbox is more useful when the dependencies you need are already present. The announcement includes these templates:

Template	Included environment	Example workload
`base`	Python 3.11	A small Python script or a custom setup
`interpreter`	Python, Node, pandas, numpy, matplotlib, scipy, Jupyter	Data analysis and notebook execution
`desktop`	Linux desktop with Chromium	Browser and computer-use tasks
`claude`, `codex`, `opencode`, `pi`, `prime`	The corresponding coding agent installed	A coding task using your chosen agent

These are starting environments, not claims that every task needs the same stack. A data-analysis job and an agent interacting with a browser have different requirements. Picking the closest template reduces the setup you need to manage yourself.

An installed agent may still need credentials and configuration for the services it uses. Treat those as part of your integration, rather than assuming a template includes access to a model provider.

Pause a task without rebuilding its environment

The update also announces pause and resume: files and running processes stay where you left them.

Consider a coding agent that has installed dependencies, started a process, and then reached a point where it needs human input. Preserving the environment means the next step can continue from that state instead of repeating setup.

There are several different requirements here that are worth keeping separate:

Pausing and resuming execution preserves a working session.
Persisting files keeps the outputs you want to retain.
Exporting an artifact makes that output available outside the sandbox.

Choose which of these your workflow needs. A resumable session is useful, but it is not a substitute for explicitly saving the final result of a job.

Compute starts at $0.009 per hour

The announced starting rate is $0.009 per hour, billed per second, with $10 in free credits to start.

At that starting compute rate, ten minutes works out to $0.0015. That's a compute-only illustration, not a quote for every configuration or associated service. Check the current plan and resource details for your workload.

What to try first

Start with one representative task: a Python analysis, a browser interaction, or a coding-agent run. Choose the matching template, give it only the access it needs, and save a useful output. If your workflow involves waiting for human input, include a pause/resume step in your evaluation.

You can explore the offering on the Lizard sandboxes page.

Which part of your agent workflow creates the most friction today: environment setup, execution isolation, or continuing a task after a wait?

DEV Community: Lizard