LangSmith Sandboxes

https://www.langchain.com/langsmith/sandboxes

LangSmith Sandboxes are managed, ephemeral compute environments based on hardware-virtualized microVMs for executing code generated by AI agents. They run on LangChain's cloud infrastructure (GCP and AWS) and are accessed via the LangSmith SDK in Python or TypeScript. Typical use cases include providing agents with a sandboxed filesystem and runtime, executing untrusted code, building Docker-based snapshots, and forking sandbox instances for parallel agent workflows.

Pricing model Per-second billing based on vCPU, memory, and storage usage
Pricing The headline compute price as the provider states it. Sorting ranks prices stated per vCPU over time, converted to hourly. Other pricing models sort after, unranked. $0.0576 per vCPU-hour for compute, plus memory and storage
Free while idle Whether a stopped, paused, or sleeping sandbox costs nothing.
Elastic Resources flex with what the sandbox actually uses, and the bill follows: yes when the provider bills on active or observed use, no when capacity is reserved or allocated and billed while it runs.
Memory snapshots Whether RAM state survives a pause and resume, not just disk.
Wake on request Whether a stopped sandbox wakes automatically on inbound traffic.
Start / resume Typical time from create or resume to running. Sorting ranks stated times, converted to seconds; claims with no figure sort after, unranked. <0.98 s p50 with prewarming
Max runtime The longest a sandbox may run. No documented hard limit. idle_ttl_seconds (default 600s) auto-stops after inactivity; delete_after_stop_seconds deletes after stop. Setting idle_ttl_seconds=0 disables the idle stop.
Isolation The isolation technology between sandboxes. Hardware-virtualized microVM (kernel-isolated)
GPUs Whether GPU instances are available for sandboxes.
Docker Whether Docker containers can run inside the sandbox.
SDKs Python, TypeScript

✓ yes · ✕ no · – no cited public fact.

The default lifecycle stops an idle sandbox after 10 minutes and deletes it after a server-configured period, typically 14 days. Filesystem state survives stop/start and snapshot capture, including `/tmp` (only `/dev/shm` is a tmpfs); running processes, open sockets, and RAM do not, unless you capture a memory snapshot. Memory snapshot controls are REST-only, absent from the Python and TypeScript clients, and unsupported on overlay-rootfs runtimes.

Sources

Last verified 2026-08-18. Corrections land through the update log.