Which Open Source LLMs Work Best With Code Execution Sandboxes

The best open-weight LLM for a code execution sandbox is the model whose tool calls, output formats, and handling of execution history fit the environment it must control. Choosing well means evaluating the model and sandbox as a pair, with the workload deciding which strengths deserve the most weight.

Why model selection and sandbox selection are not independent decisions

Builders often evaluate LLMs on coding benchmarks and sandboxes on isolation specifications, then make separate procurement decisions. That separation hides a basic dependency. A model that produces malformed tool calls will fail against a well-engineered runtime, while a capable model will struggle when its environment drops state between turns. Neither component can compensate fully for the other.

Computer Environments Elicit General Agentic Intelligence in LLMs demonstrates that even a minimal sandbox can elicit capabilities across diverse domains. Its LLM-in-Sandbox environment provides tools through which models can act, but the gains depend on coherent multi-turn interaction. Consequently, a mismatch between calling conventions, execution history, and runtime behavior is not simply a performance problem that more infrastructure tuning will resolve.

What a code execution sandbox is actually doing for an agent, and why standard containers fall short

A sandbox is the agent’s working environment and its security perimeter. Terminal access, file changes, bash commands, and network resources flow through it. The LLM-in-Sandbox research groups these functions into external resource access, file management, and code execution. Together, they let an agent move beyond proposing code to acting on a task.

That freedom makes the isolation boundary consequential. Standard Docker containers share the host kernel, so a kernel vulnerability exposed by an agent-generated payload can defeat containment. MicroVMs give workloads dedicated kernels, while gVisor intercepts system calls. These approaches offer different balances of isolation strength and startup latency, with ordinary containers appropriate only for trusted code.

Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents describes frameworks taking on OS-like roles, including process management through subagents and environment management through configuration files. The sandbox therefore serves a managed workflow. For agentic workloads, this adds two requirements that frame model compatibility, namely near-instant provisioning and stateful persistence.

The three model traits that determine sandbox compatibility

Tool-use reliability is the first trait to examine. Can the model sustain a sequence of valid calls? Inconsistent calling conventions and malformed arguments turn into execution errors that compound across a task.

Structured output discipline is the second trait. A harness may expect JSON arguments, bash commands, or structured diffs, and natural-language drift can make an otherwise sensible response unusable. Invented argument names create the same problem. The harness must then fail or introduce re-parsing logic, adding another place where the model’s intent and the executed action can diverge.

Context management over long horizons is the third trait. Repository work requires tracking files, dependencies, prior actions, and unfinished steps across many turns. Losing that thread creates repeated sandbox round-trips and increases the risk of partial execution. Terminal-Bench evaluates agents on realistic command-line tasks, making it more directly relevant to this interaction than code-generation scores alone. The model must be able to operate through the loop as well as write code that looks correct outside it.

How the leading open-weight models perform against those three traits

Open-weight is the useful deployment category here, but it is not synonymous with open source under a formal licensing definition. Published weights let teams self-host and audit a model, but they must check its licensing separately. That distinction becomes important when a model must run inside customer-managed infrastructure. It also prevents “open” from standing in for a full deployment assessment.

GLM-5.3 is a strong candidate for long-horizon repository and terminal work. Its very large context window helps it keep the history of what ran, and its strength on coding-agent and terminal-task work is evidence of tool-use reliability. Published weights and MIT licensing give teams more ways to deploy it. However, those attributes do not independently establish structured-output fidelity, which still needs evaluation against the intended API.

Qwen3.6 has Apache 2.0 licensing and does well on benchmarks, so it is a practical choice to test for short-horizon, high-throughput tasks. DeepSeek-V4.1-Flash provides more specific terminal evidence, with 90.6 on Terminal-Bench 2.1 and 74.2 on DeepSWE. Those scores support its candidacy for demanding coding-agent workloads. Neither result, however, proves that every live call will follow a particular sandbox schema.

Models explicitly designed for sub-agent parallelism fit workflows in which specialized agents have independent contexts and sandboxes. That capability cannot be inferred from a single coding score, just as the evidence here does not establish a single-GPU winner. These profiles require different infrastructure, because a short session, a persistent repository task, and a group of parallel agents impose different demands on the runtime.

How sandbox architecture choices interact with model behavior in practice

The runtime sets how quickly feedback comes back and what state the model can still use. MicroVM isolation provides dedicated kernels but can add startup time, while gVisor offers a different latency-security tradeoff through syscall interception. Context management changes the cost of that choice. A model that avoids unnecessary re-entry can tolerate slower provisioning better than one that repeatedly reconstructs its position.

NVIDIA’s OpenShell uses declarative YAML policies across filesystem, network, process, and provider credentials. The credential layer resolves opaque placeholders only at profile-authorized endpoints. These controls can restrict access, but they do not establish that a model produces valid structured output.

Lifecycle design can be equally decisive. The llm-sandbox Python package abstracts starting, managing, and tearing down environments, easing comparisons between models against the same runtime. LangSmith Sandboxes, launched in March 2026 in Private Preview, provide ephemeral environments with access and resource controls. That design works better for bounded sessions than for workflows that need to keep persistent state for a long time.

The location of the agent loop also changes the compatibility test. Production architectures increasingly keep that loop outside the sandbox and invoke execution as a tool. In that arrangement, the model must reliably address an external API rather than depend on continuous residence inside an environment.

Statefulness and long-running execution: where model and sandbox demands align most sharply

Repository refactors and multi-session debugging expose a two-sided persistence problem. The environment must preserve work, and the model must retain enough history to interpret it. Fast provisioning cannot replace either requirement. A fresh environment is not equivalent to the one in which the previous steps occurred.

DeltaBox (2026) treats checkpoint/restore as a millisecond-level primitive built on a Firecracker microVM. Its DeltaFS component is a standalone Linux filesystem, while DeltaCR extends CRIU. By duplicating changes between consecutive checkpoints rather than full state, it reduces the work required for recovery. TClone (2026) approaches interactive computer-use workloads by separating fast branch creation from durable checkpointing and using copy-on-write sharing for memory and filesystem state.

These projects formalize statefulness as more than an operational convenience. Fly.io Sprites supplies a concrete service example, with approximately 300ms checkpoint/restore and 100GB of persistent NVMe storage per sandbox. The model must identify its prior tool calls, file changes, and position in the task or risk duplicate and conflicting actions. GLM-5.2’s very large context window supports retaining that history, although capacity alone does not demonstrate reliable re-anchoring after a restore.

The checkpoint/restore security objection and what it means for model selection

A faithful snapshot is not necessarily a safe recovery point. A 2026 paper on agent checkpoint/restore mechanisms argues that recovery spans framework, workspace, and runtime state, yet broader coverage does not guarantee security-valid resumption. Restored state may depend on assumptions and external effects that never coexisted in a valid history. This is a stronger objection than ordinary data loss.

What does that imply for the model? Structured calls make it easier to tell state apart from intended actions than commands that are inconsistent and context-sensitive do. That discipline can support safely retryable operations, but valid syntax does not itself make an action idempotent. The objection therefore raises the stakes of output evaluation without turning formatting into a security guarantee.

Builders should put more weight on this trait when workloads have external side effects. Financial transactions, infrastructure changes, and patient records make replay behavior more consequential than a parser failure alone. Model selection must account for whether the model’s outputs support controlled recovery as well as whether the harness accepts them on the first attempt.

Sandboxing inside coding agent harnesses: what production systems already do

Claude Code offers opt-in OS sandboxing through Bubblewrap on Linux and Seatbelt on macOS, with network restrictions. Hermes, from Nous Research, instead delegates containment to six pluggable execution backends and ships no OS-level isolation primitives itself. The chosen backend must keep execution safe, and the model must still make reliable calls.

Orchestration introduces a separate compatibility burden. Codex CLI lets a main agent spawn specialized subagents with independent context windows and sandboxes. The driving model must therefore manage coordination as well as its own execution loop. Success in a single-agent session does not show that the model can do that.

The same study describes OpenHands running Claude Code, Codex, or Gemini CLI as interchangeable backends. It also finds that SKILL.md skills lead MCP in adoption across the systems studied. These patterns make interface compatibility a practical engineering concern. The study’s observation that no production agent runtime imports a general-purpose agentic framework further underscores how directly harness design must handle model and sandbox behavior.

Compliance and self-hosting requirements that constrain open-weight model and sandbox choices together

Some teams must rule out otherwise promising combinations because of deployment requirements before they compare performance. Fintech, healthcare, and government workloads may need customer-managed infrastructure when the managed offerings available cannot meet their constraints. This narrows both sides of the pairing. Open weights alone do not satisfy a requirement if execution still sends sensitive data elsewhere.

HIPAA adds a specific contractual boundary for protected health information. A vendor that creates, receives, maintains, or transmits it is a Business Associate and requires a signed BAA before that information reaches its infrastructure. Most standard public LLM API offerings are not BAA-covered by default. Model hosting and sandbox hosting must therefore be considered within the same data-handling assessment.

GLM-5.2 under MIT and Qwen3.6 under Apache 2.0 provide permissively licensed options for customer-managed compute. On the execution side, microsandbox uses libkrun microVMs, llm-sandbox provides a Python package, and Cleanroom offers deny-by-default egress. These options support keeping execution within a team’s infrastructure, though self-hosting is not itself a complete compliance determination. Docker-native compatibility can also reduce the integration surface when teams bring existing hardened container configurations into the agent runtime.

A framework for choosing an open-weight model and sandbox combination for your workload

The practical selection process begins with four workload axes. These are isolation requirement, session duration, deployment model, and parallelism pattern. What threat does the generated code pose, how long must state last, where can execution take place, and will agents work on their own or together? Those answers narrow the combinations to test before differences in benchmarks decide the choice.

For short-horizon data analysis and API integrations, the priority is cold-start speed paired with reliable tool calls. Qwen3.6 is a practical candidate, with gVisor-isolated execution offering a latency-security tradeoff for this profile. For long-horizon repository and terminal work, teams should put more weight on how well the model keeps context and how it performs during live execution. GLM-5.2, with its very large context window and strong SWE-bench Pro results, fits evaluation against stateful microVM environments such as Sprites or DeltaBox-style checkpoint/restore.

For maximum terminal performance, DeepSeek-V4.1-Flash is a candidate for a fast-provisioning microVM sandbox. Parallel subagents instead favor models built for that orchestration pattern, paired with per-subagent isolation and independent contexts. For any of these workloads, teams should put more weight on structured-output discipline when execution affects external systems. The workload determines how costly an ambiguous or replayed action can become.

Before writing infrastructure code, builders should check that the model they are considering has a tool-call schema that matches the sandbox’s API surface without translation layers. Each translation layer introduces another source of execution errors and structured-output failures.