LLM-in-Sandbox

Put your LLM inside a Docker-isolated code sandbox and it beats the standalone model on math, physics, chemistry, long-context and instruction-following tasks — no extra training required, and RL amplifies the gains further.

Stars
★ 245
Last updated
1mo ago
License
Apache-2.0
Primary language
Python

At a glance

How it runs
CLIFramework
Works with
Universal · cross-platformOpenAI API · Claude API
Cost
Free software; you pay for model usage
Setup effort
Low · running in minutes
You'll need
Python 3.10+DockerShell / CLINetwork accessLocal filesystem
Typical use
Researchers reproducing the paper's evaluation showing sandboxing boosts LLM performance on chemistry, physics, math, biomedicine, long-context understanding, and instruction following
Not a fit if
  • Restricted environments where Docker cannot be installed or running code in containers is not allowed
  • Teams wanting a fully hosted, zero-install cloud product

What does this agent do, and when should you use it?

LLM-in-Sandbox is an open-source research framework (Apache-2.0) from RUC AI Box at Renmin University of China, accompanying the paper 'Computer Environments Elicit General Agentic Intelligence in LLMs'. Its core idea: place any LLM inside a code sandbox with basic computer functionalities such as a file system and command execution, turning it into a general agent that outperforms standalone LLMs across diverse non-code domains. The software ships as a CLI (llm-in-sandbox run) and is backend-agnostic, connecting to OpenAI, Anthropic, and self-hosted OpenAI-compatible servers like vLLM and SGLang. Execution happens in the Docker image cdx123/llm-in-sandbox:v0.1 (~400 MB, auto-pulled on first run) for security through isolation. Each run writes a timestamped folder under ./output containing answer files and a trajectory.json execution history. The repository also includes a v0.2.0 benchmark module for reproducing paper results, and a companion repo, LLM-in-Sandbox-RL, releasing RL code, models, data, and training logs.

You submit a task via llm-in-sandbox run with a --query and model configuration; the framework launches a Docker sandbox (default image cdx123/llm-in-sandbox:v0.1) and hands the task to the selected LLM, which iteratively executes commands and reads/writes files inside the sandbox for up to --max_steps (default 100) conversation turns. You can mount an input folder via --input_dir; results go to a timestamped folder under --output_dir (default ./output) containing files/answer.txt, produced files, and trajectory.json. The file system acts as long-term memory, with up to 8× token savings reported in the paper. Prompt templates are switched via --prompt_config (default ./config/general.yaml), and the llm_in_sandbox/benchmark/ module reproduces paper evaluations, evaluates any LLM, or adds custom tasks. llm-in-sandbox build builds a custom image from docker/Dockerfile.

  1. Researchers reproducing the paper's evaluation showing sandboxing boosts LLM performance on chemistry, physics, math, biomedicine, long-context understanding, and instruction following
  2. Teams running self-hosted models (e.g., Qwen3-Coder-30B, DeepSeek-V3.2 on vLLM or SGLang) who want general agentic capability without training
  3. Engineers who want LLM code and file execution inside Docker isolation rather than unrestricted setups like OpenClaw
  4. Researchers running reinforcement learning experiments using the open code, models, and wandb logs from LLM-in-Sandbox-RL
  5. Evaluators benchmarking any LLM behind an OpenAI-compatible endpoint across domains via the built-in benchmark module
  6. Agent developers looking for examples in non-coding tasks: scientific reasoning, travel planning, video production, music composition, poster design

How do you install or deploy this agent?

Prerequisites: Python 3.10+ and Docker. Install Docker if not present:

curl -fsSL https://get.docker.com -o get-docker.sh && sh get-docker.sh
dockerd > /var/log/dockerd.log 2>&1 &

Install via pip:

pip install llm-in-sandbox==0.2.0

Or from source:

git clone https://github.com/llm-in-sandbox/llm-in-sandbox.git
cd llm-in-sandbox
pip install -e .

The default Docker image (~400MB) is pulled automatically on first run. No local GPU is needed when using API services. Tested on Ubuntu 22.04 with Python 3.10.

How do you use this agent?

Option 1: cloud/API services (supply a base URL and API key):

llm-in-sandbox run \
    --query "write a hello world in python" \
    --llm_name "openai/gpt-5" \
    --llm_base_url "http://your-api-server/v1" \
    --api_key "your-api-key"

Option 2: self-hosted models. Start a vLLM server:

vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct \
    --served-model-name qwen3_coder \
    --enable-auto-tool-choice \
    --tool-call-parser qwen3_coder \
    --tensor-parallel-size 8  \
    --enable-prefix-caching

Then run the agent in a new terminal:

llm-in-sandbox run \
    --query "write a hello world in python" \
    --llm_name qwen3_coder \
    --llm_base_url "http://localhost:8000/v1"  \
    --temperature 0.7

SGLang serving DeepSeek-V3.2 is also documented (add --extra_body '{"chat_template_kwargs": {"thinking": True}}'). Common parameters: --input_dir (mount input files), --output_dir (default ./output), --max_steps (default 100), --prompt_config (default ./config/general.yaml). Run llm-in-sandbox run --help for all options. See llm_in_sandbox/benchmark/README.md to reproduce paper results.

What are this agent's strengths and limitations?

Pros
  • Backend-agnostic: works with OpenAI, Anthropic, vLLM, SGLang and any OpenAI-compatible endpoint, avoiding vendor lock-in
  • Docker-isolated execution, a concrete security differentiator versus unrestricted setups like OpenClaw
  • File system as long-term memory with up to 8× token savings per the paper, and cross-domain gains without extra training
  • v0.2.0 benchmark module for direct reproduction; the RL release includes code, models, data, and wandb logs
Limitations
  • Docker is mandatory; the sandbox image pulls ~400MB on first run
  • Effectiveness depends on the underlying LLM — cloud APIs incur per-use costs and self-hosted models need GPU hardware
  • The value rests on research findings; the README offers no documentation for production deployment, authentication, or multi-tenant use
  • Validated on Ubuntu 22.04 with Python 3.10; compatibility on other systems is not explicitly documented

How does this agent compare with similar options?

The README contrasts the project with 🦞 OpenClaw: OpenClaw is an unrestricted agent environment, while LLM-in-Sandbox emphasizes Docker isolation for security. Design and code borrow from R2E-Gym. Related ecosystem releases by the authors include scale-openclaw (Docker-free large-scale OpenClaw trajectory collection on a single machine) and ClawGym (a scalable framework for building claw agents).

Key facts side by side with the most closely related agents.

Agent Source review Form / cost Stars Updated Language Full support on
LLM-in-Sandbox This agent 52 · Major gaps CLIFree + model costs ★ 245 1mo ago Python OpenAI API · Claude API
Functionary: Conversational LLM for Controlled Tool Use 30 · Major gaps Self-hosted serviceFree ★ 1.6k 3mo ago Python OpenAI API
OSWorld 2.1 Computer-Use Agent Benchmark 53 · Major gaps CLIFree + model costs ★ 376 4d ago Python OpenAI API · Claude API
MARTI: Multi-Agent Reinforced Training & Inference for LLMs 36 · Major gaps CLIFree ★ 570 1mo ago Python —

How does FollowAgents rate this agent?

FollowAgents source review · FARS-2.1
Major gaps
52/ 100 5-point scale 2.6 / 5
Trust 11/29
Reliability 6/14
Adaptability 9/18
Convention 13/18
Effectiveness 9/13
Verifiability 4/8
Why each dimension lost points
Trust11 / 29 · 1.9/5

README claims Docker isolation (contrasted with unrestricted setups like OpenClaw), a positive least-privilege signal, but the actual permission boundary inside the sandbox and exposure of mounted input_dir/output_dir are not verifiable from the provided files — scored 1. User confirmation: the Docker image is auto-pulled on first run and the agent runs up to 100 turns by default with no confirmation gate. Data flow and sensitive data handling: only CLI --api_key and env-var handling are documented; passing keys on the command line is a known anti-pattern, and no redaction/logging policy is evidenced. Dependency security: README claims dependencies are 'pinned in pyproject.toml', but they are open-ended >= constraints, not pins — the claim contradicts the evidence, hence the deduction. External effects and rollback: no evidence (writes to ./output without overwrite prompts; no undo mechanism). Source attribution is decent: named authors and explicit acknowledgment of reused R2E-Gym code.

Reliability6 / 14 · 2.1/5

Dependency availability is reasonable: pinned Docker image tag (cdx123/llm-in-sandbox:v0.1), explicit Python range, and a tested environment (Ubuntu 22.04, Python 3.10). However, the README's 'pinned' claim conflicts with the actual >= constraints in pyproject — an internal inconsistency; sandbox-internal dependencies and litellm compatibility are unverifiable. Failure messages, error handling, and retry logic have no code or documentation evidence — scored 1.

Adaptability9 / 18 · 2.5/5

Audience and scenarios are clear: developers and researchers, multiple backends (OpenAI/Anthropic/vLLM/SGLang), multi-domain examples — scored 2. But capability boundaries (what the agent can/cannot do, failure modes beyond max_steps) are only implied by the parameter table. Trigger precision and configuration behavior (prompt_config templates) are unevidenced. Environment fit is well documented: no local GPU needed, image size, and install time are quantified.

Convention13 / 18 · 3.6/5

Installation notes are the strongest area: stepwise Docker install, pip and source options, image pull timing, system requirements, and reproducibility notes — scored 3. Information architecture is good: table of contents, subsections, links to benchmark and examples sub-READMEs. Naming is stable (consistent PyPI name, CLI entry, version 0.2.0). Examples/FAQ are linked via examples/README but their content is not in the evidence — scored 2. Known limitations are minimal (one reproducibility note, no real limitations list). License is a complete Apache-2.0 text — scored 3. Versioning is shown via the News section and release links, but there is no CHANGELOG file. Maintenance responsibility: issue channel plus two direct contact emails (including a microsoft.com address giving real attribution) — scored 2.

Effectiveness9 / 13 · 3.5/5

Output usability is decent: each run produces a timestamped folder with answer.txt, artifacts, and trajectory.json, clearly documented. Marginal value: the core claim (sandbox elicits cross-domain gains, 8× token savings) targets clear research/engineering value and a benchmark reproduction module is provided. Cost-benefit is quantified (~1 min install, ~400MB image, no local GPU needed) — scored 2. All performance claims are unverified by this static review.

Verifiability4 / 8 · 2.5/5

Claim traceability is weak-to-moderate: arXiv link, wandb logs, and release tags are provided, but the headline numbers (cross-domain gains, 8× savings) have no inspectable table or config in the files. Cross-source corroboration is good: project page, Hugging Face, YouTube, and a benchmark README provide multiple channels — scored 2. Fact/inference separation is poor: conclusions like 'significantly outperforms standalone LLMs' are stated unconditionally without scoping to specific models/tasks, and the News dates (2026) are beyond routine verification, warranting conservative treatment — scored 1.

Risks and how to mitigate them
  • Dependencies are not actually pinned despite the README claim: pyproject.toml uses >= minimum constraints, so builds are not reproducible; generate a lockfile before enterprise adoption.
  • API keys are passed via the --api_key CLI flag, exposing them in process listings and shell history; prefer environment variables only and audit logs for redaction.
  • The Docker image cdx123/llm-in-sandbox:v0.1 is auto-pulled and is not built from this repository — a third-party artifact; build your own image via the provided Dockerfile for production.
  • The permission boundary inside the sandbox, exposure of mounted directories, and network access policy are undocumented; verify Docker isolation coverage of filesystem and network before deployment.
  • Headline claims (cross-domain gains, 8× token savings) come from the paper's own assertions and were not verified in this static review; reproduce independently via the benchmark module before adoption.
  • This is a static source review with low confidence; no code was executed.
Evidence confidence: Low Reviewed Oct 15, 2026 Reviewed revision b58c85c1447b
See the full review method →

Recent releases

Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.

  1. v0.2.0
    Release notes excerpt
    What's New Benchmark Module - Added benchmark framework to reproduce our paper results and evaluate any LLM/task - Support reward function to facilitate LLM-in-Sandbox-RL - Support for LLM-in-Sandbox and vanilla LLM modes - LLM-as-Judge evaluation Improvements - Restructured README and benchmark docs - Better error handling and Docker cleanup guidance - Clean action, improve observation PyPI - pip install llm-in-sandbox==0.2.0
    View on GitHub ↗

FAQ

Do I need a local GPU?
No. LLM-in-Sandbox is backend-agnostic and connects to any OpenAI-compatible endpoint (OpenAI, Anthropic, or a hosted vLLM/SGLang server). GPUs are only needed if you self-host a model; hardware needs then depend on the model and serving framework.
How long does the first run take?
On a normal desktop, installation takes about 1 minute and the one-time Docker image pull (~400 MB) about 1 minute; subsequent runs start instantly. The quick-start demo completes in ~1 minute, excluding model inference latency.
How do I reproduce the paper's results?
v0.2.0 ships a benchmark module (llm_in_sandbox/benchmark/README.md) for reproducing paper results, evaluating any LLM, and adding your own tasks.
Where does the output go?
Each run creates a timestamped folder in the output directory (default ./output) containing files/answer.txt (final answer), produced files, and trajectory.json (execution history).
Can I use a custom environment?
Yes. Modify docker/Dockerfile and run llm-in-sandbox build to create your own image, then point to it with --docker_image.
View on GitHub ↗ Install ↓

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents