CodeSandbox has changed
CodeSandbox began as a browser playground, expanded into collaborative cloud development environments, and is now positioned heavily around isolated sandbox infrastructure for AI agents, code execution, and developer products. The company is part of Together AI, and the current homepage leads with the CodeSandbox SDK rather than a simple React editor. Browser Sandboxes still support fast experiments and examples, while VM Sandboxes provide full virtual machines for arbitrary code, persistent snapshots, terminals, previews, and larger workloads.
This product shift matters because older reviews centered on a $9 Pro editor plan or a frontend-only sandbox no longer describe the current buying decision. The relevant questions in 2026 are whether a workload needs a browser runtime or VM, how many concurrent environments an application must create, what compute size is required, and whether developers or an SDK will control the sessions. CodeSandbox remains useful for individual coding, but its differentiated value is now the infrastructure behind agents, code interpreters, evaluations, training environments, and collaborative developer tools.
Browser Sandboxes, VM Sandboxes, and Dev Containers
Browser Sandboxes are unlimited across the published plans and remain a good fit for lightweight web examples. VM Sandboxes run on isolated virtual machines and use credits based on runtime. CodeSandbox describes near-instant forking, snapshot restore, browser terminals, preview URLs, hibernation, and the ability to resume context after inactivity. Its VM infrastructure can create a sandbox from a Git repository, inject environment variables and Git credentials into a session, and expose a browser preview through APIs.
Dev Container support gives repository owners a portable way to declare dependencies, setup tasks, environment variables, and startup commands. CodeSandbox runs the configuration in a microVM and can infer package scripts, prepare .env files, and launch previews. Because the Dev Container specification is reusable outside CodeSandbox, it reduces lock-in compared with a proprietary setup form. Teams should still test unsupported privileges, image build time, network policy, storage, and secret injection, because a standard configuration does not guarantee identical behavior across every CDE implementation.
Current pricing and capacity
The current Build plan is free for up to five members and includes 40 hours of monthly VM credits, unlimited Browser and VM Sandboxes, private sandboxes, VM sizes up to 4 vCPUs and 8 GiB RAM, a VS Code extension, and CodeSandbox SDK Lite. The SDK limit is 10 concurrent VM Sandboxes, 20 new sandboxes per hour, and 1,000 SDK requests per hour. This is enough for prototypes, education, and low-volume agents, but concurrency rather than the total number of sandbox records is often the first production constraint.
Scale starts at $170 per month per workspace for up to 20 members and includes 160 monthly VM hours, on-demand VM credits listed at $0.15 per hour, up to 250 concurrent SDK VMs, 1,000 new sandboxes per hour, and 10,000 SDK requests per hour. It supports VM sizes up to 16 vCPUs and 32 GiB RAM. The pricing page also states that VM credits cost $0.015 each, so buyers should confirm how credits translate to the selected machine tier and estimate active runtime, hibernation policy, concurrency bursts, and preview traffic before relying on the included-hour headline.
Security and SDK design
Each VM Sandbox is isolated, which is essential when an agent or user runs generated or untrusted code. CodeSandbox's SDK documentation separates sandbox management from sessions and supports private sandboxes, browser sessions, host tokens for exposed previews, environment variables, Git credentials, commands, interpreters, tasks, and setup steps. A private-by-default sandbox plus a narrowly scoped host token is a better starting point than publishing every preview, but application developers remain responsible for token lifetime, tenant isolation, network egress, logging, and deletion.
Isolation is not the same as a complete security policy. Agent builders should assume generated code can attempt credential discovery, excessive compute, network scanning, or data exfiltration. Secrets should be injected only into tasks that require them, preview hosts should be authenticated, base templates should be patched, and inactive environments should hibernate or terminate predictably. Enterprise advertises custom concurrency, larger machines up to 64 vCPUs and 128 GiB RAM, tailored limits, SOC 2 Type II, and dedicated support; buyers with regulated workloads should validate contractual controls rather than infer them from the public sandbox model.
Verdict and alternatives
CodeSandbox is a strong choice for teams that need both a human-facing editor and an API for creating isolated development environments at scale. It is especially relevant for coding agents, code interpreters, evaluation systems, interactive courses, and documentation products that benefit from fast clones and shareable previews. The free Build plan is credible for validation, while Scale is a production infrastructure purchase whose value depends on concurrency and operational simplicity. Its current direction is more platform than playground.
StackBlitz is simpler and often faster for browser-native Node.js prototypes through WebContainers. GitHub Codespaces offers deeper GitHub administration and a conventional devcontainer workstation, while Ona combines environments with an agent mission-control experience. Self-hosted Coder or Kubernetes-based systems offer more infrastructure control at greater operational cost. CodeSandbox wins when programmable VM lifecycle, snapshots, browser sessions, and preview APIs are central requirements; it is less compelling when a team only needs one remote editor per developer.
