Grounding LLMs with Executable Code: A Deep Dive into Cloudflare Sandbox SDK

The challenge of grounding Large Language Models in reality has become critical as AI systems move from proof-of-concept to production. LLMs excel at generating plausible code but struggle with factual accuracy—they hallucinate APIs that don’t exist, suggest deprecated patterns, and produce syntactically correct but semantically broken code. The solution isn’t better prompting or larger models; it’s executable verification that grounds AI outputs in concrete runtime feedback.

This deep dive examines Cloudflare Sandbox SDK, a production-ready system for executing untrusted LLM-generated code safely at the edge. We’ll explore the architectural decisions, security model, implementation patterns, and practical considerations for building reliable AI coding agents.

The Problem: Confidently Wrong Code

LLMs generate code that looks perfect but fails in production. In infrastructure automation, I’ve observed models hallucinating:

• AWS resource properties that never existed (e.g., enable_auto_healing on EC2 instances)
• Terraform provider arguments from outdated documentation
• Kubernetes manifests using deprecated API versions
• Python packages with inverted parameter orders

The danger isn’t uncertainty—it’s false confidence. LLMs produce syntactically valid code with subtle semantic errors that traditional static analysis misses. A Terraform validator confirms proper HCL syntax but can’t verify that aws_instance.enable_auto_healing doesn’t exist in provider v5.

This is where executable verification becomes essential: run the code, observe failures, feed errors back to the LLM, and iterate until execution succeeds. But executing untrusted AI-generated code introduces massive security and operational challenges.

Enter Cloudflare Sandbox SDK.

What is Cloudflare Sandbox SDK?

Cloudflare Sandbox SDK enables secure, isolated code execution directly on Cloudflare’s edge network. Built on three core technologies—Workers, Durable Objects, and Containers—it provides VM-level isolation for running untrusted code with a clean TypeScript API.

Architecture Overview

┌─────────────────────────────────────────────────────┐
│  Your Worker (Application Logic)                    │
│  - Receives LLM-generated code                      │
│  - Calls sandbox.exec() or sandbox.runCode()        │
└────────────────┬────────────────────────────────────┘
                 │ RPC via Durable Object stub
┌────────────────▼────────────────────────────────────┐
│  Sandbox Durable Object (State & Routing)           │
│  - Persistent sandbox identity (user-123)           │
│  - Routes requests to container                     │
│  - Manages lifecycle & preview URLs                 │
└────────────────┬────────────────────────────────────┘
                 │ HTTP API
┌────────────────▼────────────────────────────────────┐
│  Container Runtime (Isolated VM)                    │
│  - Ubuntu Linux environment                         │
│  - Python, Node.js, Git pre-installed               │
│  - Executes untrusted code safely                   │
│  - Full filesystem & process isolation              │
└─────────────────────────────────────────────────────┘

Key architectural decisions:

1. Durable Objects for statefulness: Each sandbox has a persistent identity. Calling getSandbox(env.Sandbox, 'user-123') always routes to the same Durable Object instance, maintaining execution context across requests.

2. VM-based isolation: Unlike process-level sandboxing (Docker with shared kernel), each Sandbox runs in its own VM. This provides complete filesystem, network, and process isolation—critical for multi-tenant AI applications.

3. Edge deployment: Sandboxes run on Cloudflare’s global network (300+ locations), minimizing latency between LLM inference and code execution. This matters for real-time coding assistants where users expect sub-second feedback.

Two Execution APIs

Sandbox SDK offers two approaches for running code:

1. Code Interpreter API (runCode) - High-level, batteries-included:

const ctx = await sandbox.createCodeContext({ language: 'python' });
const result = await sandbox.runCode(`
import pandas as pd
df = pd.DataFrame({'x': [1, 2, 3]})
df['x'].sum()  // Automatically captured as result
`, { context: ctx.id });

console.log(result.results[0].text);  // "6"
console.log(result.formats);          // ['text', 'html'] (for DataFrames)

• Persistent execution contexts (variables/imports survive between calls)
• Automatic rich output capture (charts, tables, JSON, HTML)
• Purpose-built for LLM-generated code snippets

2. Command Execution API (exec) - Lower-level control:

const result = await sandbox.exec('npm install && npm test', {
  stream: true,
  onStdout: (line) => console.log(line)
});

console.log(result.exitCode);
console.log(result.stdout);

• Full shell access (install packages, run builds, manage files)
• Streaming output for long-running processes
• Better for CI/CD, custom environments, system operations

Both APIs return structured results with success/failure status, making them ideal for LLM feedback loops.

Implementing Recursive Verification with Sandbox SDK

The core pattern: LLM generates code → Sandbox executes → Error feeds back to LLM → Iterate until success.

Here’s a production-ready implementation:

import { getSandbox, type Sandbox } from '@cloudflare/sandbox';

interface LLMClient {
  generate(prompt: string): Promise<string>;
}

interface ExecutionResult {
  success: boolean;
  code: string;
  output?: string;
  error?: string;
  iterations: number;
  history: ExecutionAttempt[];
}

interface ExecutionAttempt {
  iteration: number;
  code: string;
  success: boolean;
  output?: string;
  error?: string;
}

export class GroundedLLMExecutor {
  private llm: LLMClient;
  private sandbox: Sandbox;
  private maxIterations: number;
  private codeContext?: { id: string };

  constructor(
    llm: LLMClient,
    sandboxNamespace: DurableObjectNamespace<Sandbox>,
    sandboxId: string,
    options: { maxIterations?: number; language?: 'python' | 'javascript' } = {}
  ) {
    this.llm = llm;
    this.sandbox = getSandbox(sandboxNamespace, sandboxId);
    this.maxIterations = options.maxIterations ?? 3;
  }

  async executeWithVerification(
    userPrompt: string,
    options: { language?: 'python' | 'javascript'; stream?: boolean } = {}
  ): Promise<ExecutionResult> {
    const language = options.language ?? 'python';
    const history: ExecutionAttempt[] = [];

    // Create persistent execution context
    this.codeContext = await this.sandbox.createCodeContext({ language });

    try {
      for (let iteration = 0; iteration < this.maxIterations; iteration++) {
        // Build prompt with execution history
        const prompt = this.buildPrompt(userPrompt, history, language);

        // Generate code from LLM
        const llmResponse = await this.llm.generate(prompt);
        const code = this.extractCode(llmResponse, language);

        console.log(`Iteration ${iteration + 1}: Executing generated code`);

        // Execute in sandbox with real-time streaming (optional)
        const result = await this.sandbox.runCode(code, {
          context: this.codeContext.id,
          stream: options.stream,
          onOutput: options.stream ? (data) => console.log(`Output: ${data}`) : undefined,
        });

        // Record attempt
        const attempt: ExecutionAttempt = {
          iteration: iteration + 1,
          code,
          success: result.success,
          output: result.output,
          error: result.error,
        };
        history.push(attempt);

        if (result.success) {
          return {
            success: true,
            code,
            output: result.output,
            iterations: iteration + 1,
            history,
          };
        }

        console.log(`Iteration ${iteration + 1} failed: ${result.error}`);
        console.log(`Feeding error back to LLM for correction...`);
      }

      // Exhausted all iterations
      return {
        success: false,
        code: history[history.length - 1].code,
        error: `Failed after ${this.maxIterations} attempts`,
        iterations: this.maxIterations,
        history,
      };
    } finally {
      // Cleanup: delete code context
      if (this.codeContext) {
        await this.sandbox.deleteCodeContext(this.codeContext.id);
      }
    }
  }

  private buildPrompt(
    userPrompt: string,
    history: ExecutionAttempt[],
    language: string
  ): string {
    let prompt = `You are a ${language} code generator. Generate ONLY executable code, no explanations.\n\nTask: ${userPrompt}\n`;

    if (history.length > 0) {
      prompt += '\n=== Previous Attempts ===\n';
      for (const attempt of history) {
        prompt += `\nAttempt ${attempt.iteration}:\n`;
        prompt += `Code:\n\`\`\`${language}\n${attempt.code}\n\`\`\`\n`;
        prompt += `Result: ${attempt.success ? 'SUCCESS' : 'FAILED'}\n`;
        if (attempt.error) {
          prompt += `Error: ${attempt.error}\n`;
        }
      }
      prompt += '\n=== Your Task ===\n';
      prompt += 'Analyze the errors above and generate CORRECTED code. Address the specific error messages.\n';
    }

    return prompt;
  }

  private extractCode(llmResponse: string, language: string): string {
    // Extract code from markdown code blocks
    const pattern = new RegExp(`\`\`\`${language}\\n([\\s\\S]*?)\\n\`\`\``, 'i');
    const match = llmResponse.match(pattern);
    if (match && match[1]) {
      return match[1].trim();
    }

    // Fallback: return full response if no code blocks found
    return llmResponse.trim();
  }
}

Key improvements over subprocess-based sandboxing:

1. VM isolation: Cloudflare Containers provide VM-level isolation, not process-level. Malicious code can’t escape to the host system.

2. Persistent context: createCodeContext() maintains state between executions. If iteration 1 installs a package, iteration 2 can use it without reinstalling.

3. Rich output capture: Code Interpreter automatically extracts last expression values, perfect for data analysis tasks where LLMs generate Pandas operations.

4. Edge deployment: Runs globally on Cloudflare’s network. No dedicated servers to manage.

5. Streaming support: Real-time output for long-running operations, essential for user-facing coding assistants.

Real-World Example: Terraform Validation with Sandbox SDK

Infrastructure-as-Code presents unique challenges for LLM verification. Terraform configurations can be syntactically valid but semantically broken (e.g., referencing non-existent AWS properties). Here’s how to validate Terraform using Sandbox SDK:

import { getSandbox } from '@cloudflare/sandbox';

interface TerraformValidationResult {
  valid: boolean;
  plan?: any;
  errors: string[];
  iterations: number;
}

async function validateTerraformWithLLM(
  llm: LLMClient,
  sandboxNamespace: DurableObjectNamespace<Sandbox>,
  userPrompt: string
): Promise<TerraformValidationResult> {
  const sandbox = getSandbox(sandboxNamespace, `terraform-${crypto.randomUUID()}`);
  const maxIterations = 3;
  const errors: string[] = [];

  try {
    // Install Terraform in sandbox
    await sandbox.exec('apt-get update && apt-get install -y wget unzip');
    await sandbox.exec('wget https://releases.hashicorp.com/terraform/1.6.0/terraform_1.6.0_linux_amd64.zip');
    await sandbox.exec('unzip terraform_1.6.0_linux_amd64.zip && mv terraform /usr/local/bin/');

    for (let i = 0; i < maxIterations; i++) {
      console.log(`Validation attempt ${i + 1}/${maxIterations}`);

      // Generate Terraform code from LLM
      const prompt = buildTerraformPrompt(userPrompt, errors);
      const terraformCode = await llm.generate(prompt);

      // Write to sandbox
      await sandbox.writeFile('/workspace/main.tf', terraformCode);

      // Initialize Terraform
      const initResult = await sandbox.exec('cd /workspace && terraform init -backend=false');
      if (!initResult.success) {
        errors.push(`Init failed: ${initResult.stderr}`);
        continue;
      }

      // Validate syntax
      const validateResult = await sandbox.exec('cd /workspace && terraform validate -json');
      if (!validateResult.success) {
        const diagnostics = JSON.parse(validateResult.stdout);
        const errorMsg = diagnostics.diagnostics[0]?.detail || 'Unknown validation error';
        errors.push(`Validation failed: ${errorMsg}`);
        continue;
      }

      // Run plan to catch semantic errors (e.g., invalid resource properties)
      const planResult = await sandbox.exec('cd /workspace && terraform plan -out=tfplan.binary');
      if (!planResult.success) {
        errors.push(`Plan failed: ${planResult.stderr}`);
        continue;
      }

      // Extract plan as JSON
      const showResult = await sandbox.exec('cd /workspace && terraform show -json tfplan.binary');
      const plan = JSON.parse(showResult.stdout);

      console.log('✓ Terraform code validated successfully');
      return {
        valid: true,
        plan,
        errors,
        iterations: i + 1,
      };
    }

    return {
      valid: false,
      errors,
      iterations: maxIterations,
    };
  } finally {
    // Cleanup sandbox
    await sandbox.destroy();
  }
}

function buildTerraformPrompt(userPrompt: string, errors: string[]): string {
  let prompt = `Generate Terraform code for: ${userPrompt}\n\nRequirements:\n`;
  prompt += '- Use Terraform 1.6 syntax\n';
  prompt += '- Include provider configuration\n';
  prompt += '- Use only valid resource properties\n';

  if (errors.length > 0) {
    prompt += '\n=== Previous Errors to Fix ===\n';
    errors.forEach((err, idx) => {
      prompt += `${idx + 1}. ${err}\n`;
    });
    prompt += '\nGenerate CORRECTED Terraform code addressing these errors.\n';
  }

  return prompt;
}

Why this works better than local subprocess sandboxing:

1. Full Terraform environment: Sandbox containers come with Ubuntu Linux, making it trivial to install Terraform. No need to manage Docker images or build custom containers.

2. Isolated per validation: Each Terraform validation gets its own sandbox (using crypto.randomUUID() for unique IDs). No risk of state contamination between validations.

3. Real error messages: Terraform runs in a real Linux environment and produces authentic error messages that LLMs can learn from. The errors aren’t simulated or approximated.

4. Automatic cleanup: sandbox.destroy() tears down the entire VM. No orphaned Docker containers or leftover state.

5. Edge execution: Validations run close to users globally. A developer in Singapore gets the same <100ms response time as one in San Francisco.

Security Deep Dive: How Sandbox SDK Achieves Isolation

Traditional Docker-based sandboxing shares the host kernel, creating potential escape vectors. Sandbox SDK uses VM-level isolation via Cloudflare Containers, where each sandbox runs in a separate microVM.

Container Architecture

From Cloudflare’s documentation:

┌─────────────────────────────────────────────────────────┐
│  Host Server (Cloudflare Edge Location)                 │
│                                                          │
│  ┌────────────────┐  ┌────────────────┐  ┌──────────┐  │
│  │  Sandbox VM 1  │  │  Sandbox VM 2  │  │  VM N    │  │
│  │                │  │                │  │          │  │
│  │  - Own kernel  │  │  - Own kernel  │  │  ...     │  │
│  │  - Own FS      │  │  - Own FS      │  │          │  │
│  │  - Own network │  │  - Own network │  │          │  │
│  └────────────────┘  └────────────────┘  └──────────┘  │
└─────────────────────────────────────────────────────────┘

Isolation guarantees:

1. Filesystem isolation: Sandbox A cannot access Sandbox B’s files. Each VM has a separate filesystem. Even if an attacker gains root inside the VM, they can’t escape to the host or other VMs.

2. Process isolation: Processes in one sandbox are invisible to others. No shared process namespace.

3. Network isolation: Each sandbox has its own network stack. Cannot sniff traffic from other sandboxes.

4. Resource quotas: CPU, memory, and disk limits enforced at the hypervisor level. A runaway process in one sandbox won’t starve others.

Security Best Practices

1. Use per-user sandbox IDs for multi-tenancy:

// ✓ Good: Each user gets isolated sandbox
const userId = await authenticateUser(request);
const sandbox = getSandbox(env.Sandbox, `user-${userId}`);

// ✗ Bad: All users share one sandbox (files visible to everyone!)
const sandbox = getSandbox(env.Sandbox, 'shared');

2. Validate inputs to prevent command injection:

// ✗ Dangerous: User input directly in shell command
const filename = userInput;  // Could be: "file.txt; rm -rf /"
await sandbox.exec(`cat ${filename}`);

// ✓ Safe: Validate and sanitize
const safeFilename = userInput.replace(/[^a-zA-Z0-9._-]/g, '');
await sandbox.exec(`cat ${safeFilename}`);

// ✓ Better: Use file API (no shell involved)
await sandbox.writeFile('/tmp/input', userInput);
const content = await sandbox.readFile('/tmp/input');

3. Pass secrets via environment variables, not files:

// ✗ Bad: Hardcoded secrets in files
await sandbox.writeFile('/workspace/config.js', `
  const API_KEY = 'sk_live_abc123';
  const DB_PASSWORD = 'hunter2';
`);

// ✓ Good: Environment variables from Worker bindings
await sandbox.startProcess('node app.js', {
  env: {
    API_KEY: env.API_KEY,         // From Cloudflare Worker environment
    DB_PASSWORD: env.DB_PASSWORD,
  }
});

4. Cleanup temporary sensitive data:

try {
  await sandbox.writeFile('/tmp/credentials.json', sensitiveData);
  await sandbox.exec('python process_data.py /tmp/credentials.json');
} finally {
  // Always cleanup, even if execution fails
  await sandbox.deleteFile('/tmp/credentials.json');
}

5. Limit iteration depth to prevent infinite loops:

const MAX_ITERATIONS = 3;  // Fail fast after 3 attempts

for (let i = 0; i < MAX_ITERATIONS; i++) {
  const code = await llm.generate(prompt);
  const result = await sandbox.runCode(code, { context: ctx.id });
  
  if (result.success) return result;
  
  // Feed error back for next iteration
  prompt = `Previous attempt failed: ${result.error}\nGenerate corrected code.`;
}

// Escalate to human review after exhausting iterations
throw new Error('LLM unable to generate valid code after 3 attempts');

What Sandbox SDK Protects Against

• Container escape attacks: VM isolation prevents kernel exploits
• Resource exhaustion: Enforced CPU/memory/disk quotas
• Lateral movement: Sandboxes cannot communicate with each other
• Data exfiltration: Network isolation (unless explicitly exposed via preview URLs)

What You Must Implement

Sandbox SDK handles infrastructure-level security but application security is your responsibility:

• Authentication/authorization: Verify users can only access their own sandboxes
• Input validation: Sanitize all user inputs before passing to shell commands
• Rate limiting: Prevent abuse (e.g., spawning 1000 sandboxes per second)
• Audit logging: Track what code gets executed and by whom
• Content filtering: Detect and block malicious code patterns before execution

Performance Characteristics and Optimization

Understanding latency sources helps optimize LLM verification workflows.

Latency Breakdown (Measured on Claude 3.5 Sonnet + Sandbox SDK)

┌─────────────────────────────────────────────────────────┐
│  Iteration 1 (Cold Start)                               │
├─────────────────────────────────────────────────────────┤
│  LLM generation:              800ms - 1500ms            │
│  Sandbox container spin-up:   200ms - 500ms (first use) │
│  Code execution:              50ms - 300ms              │
│  Total:                       ~1050ms - 2300ms          │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│  Iteration 2+ (Warm Container)                          │
├─────────────────────────────────────────────────────────┤
│  LLM generation:              800ms - 1500ms            │
│  Code execution:              50ms - 300ms (cached)     │
│  Total:                       ~850ms - 1800ms           │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│  Worst Case (3 iterations)                              │
├─────────────────────────────────────────────────────────┤
│  Total:                       3s - 6s                   │
└─────────────────────────────────────────────────────────┘

Key observations:

1. Container persistence matters: Durable Objects keep containers alive between requests. After the first execution, subsequent calls reuse the warm container (no spin-up penalty).

2. LLM latency dominates: Code execution typically takes <300ms. The LLM generation (800-1500ms) is the bottleneck. Optimizing sandbox execution provides minimal gains.

3. Streaming reduces perceived latency: While total time remains the same, streaming LLM output and sandbox execution makes the system feel more responsive to users.

Optimization Strategies

1. Static analysis before execution (fail-fast):

function containsDangerousPatterns(code: string): string[] {
  const patterns = [
    { regex: /eval\s*\(/g, msg: 'eval() is forbidden' },
    { regex: /exec\s*\(/g, msg: 'exec() is forbidden' },
    { regex: /__import__\s*\(/g, msg: 'dynamic imports forbidden' },
    { regex: /os\.system\s*\(/g, msg: 'os.system() is forbidden' },
  ];

  const errors: string[] = [];
  for (const { regex, msg } of patterns) {
    if (regex.test(code)) errors.push(msg);
  }
  return errors;
}

// Check BEFORE calling expensive LLM + sandbox
const staticErrors = containsDangerousPatterns(llmGeneratedCode);
if (staticErrors.length > 0) {
  // Fast rejection without sandbox execution
  return { success: false, errors: staticErrors };
}

// Only execute if static checks pass
const result = await sandbox.runCode(llmGeneratedCode, { context: ctx.id });

2. Parallel validation for multiple resources:

// ✗ Sequential: 3 resources × 2s each = 6s total
for (const resource of resources) {
  await validateResource(resource);
}

// ✓ Parallel: 3 resources, 2s total (limited by slowest)
await Promise.all(
  resources.map(resource => validateResource(resource))
);

Each sandbox is independent, so validations can run concurrently. Cloudflare’s infrastructure automatically scales to handle parallel requests.

3. Cache validated patterns:

const CACHE: Map<string, ValidationResult> = new Map();

async function validateWithCache(code: string): Promise<ValidationResult> {
  const hash = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(code));
  const key = Array.from(new Uint8Array(hash)).map(b => b.toString(16).padStart(2, '0')).join('');

  // Return cached result if available
  if (CACHE.has(key)) {
    console.log('Cache hit: skipping LLM + sandbox');
    return CACHE.get(key)!;
  }

  // Otherwise validate normally
  const result = await executeWithVerification(code);
  CACHE.set(key, result);
  return result;
}

For frequently-used patterns (e.g., standard Terraform modules), caching eliminates redundant validation.

4. Progressive validation (exit early on syntax errors):

// Fast syntax check first (no LLM needed)
const syntaxResult = await sandbox.exec(`python -m py_compile /tmp/code.py`);
if (!syntaxResult.success) {
  return { success: false, error: 'Syntax error', stderr: syntaxResult.stderr };
}

// Only run expensive semantic validation if syntax is valid
const semanticResult = await sandbox.runCode(code, { context: ctx.id });

When 3-6s Latency is Acceptable

• Infrastructure provisioning: Deploying infrastructure takes minutes anyway. 6s validation is negligible.
• CI/CD pipelines: Tests already take seconds to minutes. Validation fits naturally.
• Batch processing: For bulk operations (e.g., validating 100 Terraform modules), validation is async.

When It’s Not Acceptable

• Real-time coding assistants: Users expect <500ms autocomplete. Use static analysis + client-side checks instead.
• Synchronous API responses: If your API SLA is <1s, verification must be async (return job ID, poll for results).
• High-frequency operations: If validating thousands of snippets per second, pre-validation caching becomes essential.

Production Deployment: Running at Scale

Deploying Sandbox SDK to production requires understanding Cloudflare’s edge architecture and configuration.

Deployment Architecture

┌─────────────────────────────────────────────────────────────┐
│  User Request (Global)                                      │
└──────────────────┬──────────────────────────────────────────┘
                   │
                   ▼
┌─────────────────────────────────────────────────────────────┐
│  Cloudflare Edge (300+ locations)                           │
│  ┌────────────────────────────────────────────────────────┐ │
│  │  Your Worker                                           │ │
│  │  - Receives request                                    │ │
│  │  - Calls getSandbox(env.Sandbox, 'user-123')          │ │
│  └────────────────┬───────────────────────────────────────┘ │
│                   │ RPC call                                 │
│  ┌────────────────▼───────────────────────────────────────┐ │
│  │  Sandbox Durable Object                                │ │
│  │  - Routes to geographically-close container            │ │
│  └────────────────┬───────────────────────────────────────┘ │
└───────────────────┼──────────────────────────────────────────┘
                    │ HTTP
┌───────────────────▼──────────────────────────────────────────┐
│  Containers (Regional)                                        │
│  - VMs run in specific Cloudflare datacenters                │
│  - Durable Object automatically routes to closest container  │
└───────────────────────────────────────────────────────────────┘

Key characteristics:

1. Workers run everywhere (edge): Your application code runs at all 300+ Cloudflare locations. Low latency globally.

2. Durable Objects run regionally: Sandbox Durable Objects are pinned to specific datacenters for state consistency. Cloudflare automatically routes requests to the correct location.

3. Containers run co-located with Durable Objects: Minimizes latency between Durable Object and container (typically <10ms).

Wrangler Configuration

# wrangler.toml
name = "llm-code-executor"
main = "src/index.ts"
compatibility_date = "2024-01-01"

# Durable Object binding
[[durable_objects.bindings]]
name = "Sandbox"
class_name = "Sandbox"

# Environment variables
[vars]
MAX_ITERATIONS = "3"
EXECUTION_TIMEOUT = "30000"

# Secrets (set via: wrangler secret put OPENROUTER_API_KEY)
# - OPENROUTER_API_KEY
# - ANTHROPIC_API_KEY

Deploy with:

npm install -g wrangler
wrangler deploy

# Set secrets
wrangler secret put OPENROUTER_API_KEY
wrangler secret put ANTHROPIC_API_KEY

Worker Implementation

import { getSandbox, proxyToSandbox, type Sandbox } from '@cloudflare/sandbox';

// Export Sandbox class (required for Durable Objects)
export { Sandbox } from '@cloudflare/sandbox';

interface Env {
  Sandbox: DurableObjectNamespace<Sandbox>;
  ANTHROPIC_API_KEY: string;
  MAX_ITERATIONS: string;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // Required: Handle preview URL proxying
    const proxyResponse = await proxyToSandbox(request, env);
    if (proxyResponse) return proxyResponse;

    const url = new URL(request.url);

    // Endpoint: /validate-code
    if (url.pathname === '/validate-code' && request.method === 'POST') {
      return await handleValidation(request, env);
    }

    return new Response('Not Found', { status: 404 });
  }
};

async function handleValidation(request: Request, env: Env): Promise<Response> {
  const { userId, code, language } = await request.json();

  // Authenticate user (your auth logic here)
  if (!userId) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  // Get user-specific sandbox
  const sandbox = getSandbox(env.Sandbox, `user-${userId}`);

  // Create execution context
  const ctx = await sandbox.createCodeContext({ language: language || 'python' });

  try {
    // Execute with streaming
    let output = '';
    const result = await sandbox.runCode(code, {
      context: ctx.id,
      stream: true,
      onOutput: (data) => {
        output += data;
        console.log(`[${userId}] Output: ${data}`);
      },
    });

    return Response.json({
      success: result.success,
      output: result.output || output,
      error: result.error,
      formats: result.formats,
    });
  } catch (error) {
    console.error(`[${userId}] Execution failed:`, error);
    return Response.json(
      { success: false, error: String(error) },
      { status: 500 }
    );
  } finally {
    // Cleanup context
    await sandbox.deleteCodeContext(ctx.id);
  }
}

Monitoring and Observability

1. Cloudflare Dashboard Logs:

// Structured logging for Cloudflare
console.log(JSON.stringify({
  timestamp: new Date().toISOString(),
  userId,
  sandboxId: `user-${userId}`,
  operation: 'code_execution',
  language,
  success: result.success,
  executionTimeMs: Date.now() - startTime,
  iterations,
}));

Logs appear in Cloudflare Dashboard → Workers → Logs → Real-time logs.

2. Worker Analytics:

Cloudflare provides automatic metrics:

• Request rate (requests/second)
• Error rate (4xx, 5xx responses)
• CPU time per request
• Worker execution duration

3. Custom metrics via Durable Object storage:

// Track usage per user
const stats = await env.STATS.get(userId);
const usage = stats ? JSON.parse(stats) : { executions: 0, totalMs: 0 };
usage.executions++;
usage.totalMs += executionTime;
await env.STATS.put(userId, JSON.stringify(usage), { expirationTtl: 86400 });

Cost Estimation (Cloudflare Workers Paid Plan)

Workers:

• $5/month base
• $0.30 per million requests beyond included
• $0.02 per million GB-s CPU time

Containers (Sandbox SDK):

• $0.01 per container hour
• Charged per second (minimum 1 second)
• Containers idle after 10 minutes of inactivity

Example cost (1000 users, 10 executions/day each):

Requests: 10,000 req/day × 30 days = 300,000 req/month
Container usage: Assume 5 minute avg session, 10k sessions/day
  = 10,000 × 5min/60 × 30 days = 25,000 container-hours
  = 25,000 × $0.01 = $250/month

Total: ~$255/month for 10k active users

Comparable self-hosted infrastructure (EC2 + Lambda) would cost $500-1000/month with operational overhead.

Alternative Approaches and Comparisons

Sandbox SDK isn’t the only way to execute untrusted code. Here’s how it compares to alternatives:

1. Docker Containers (Self-Hosted)

Approach: Run Docker locally/on VMs with docker run --rm --network none --memory 256m python:3.11 -c "code"

Pros:

• Full control over environment
• No vendor lock-in
• Works offline

Cons:

• Kernel-level isolation only: Shared kernel means container escapes are possible (see CVE-2022-0847)
• Infrastructure overhead: Must manage servers, scaling, load balancing
• Cold starts: Spinning up containers takes 1-3 seconds
• No edge deployment: Single-region deployments increase latency globally

When to use: Self-hosted environments where you control infrastructure.

2. AWS Lambda / Google Cloud Functions

Approach: Deploy serverless functions that execute code in isolated runtimes.

Pros:

• Managed infrastructure
• Auto-scaling
• Pay-per-execution

Cons:

• No persistent state: Each invocation is stateless (can’t maintain execution context)
• Limited execution time: 15 minutes max (Lambda), 60 minutes (Cloud Functions)
• Cold starts: 1-5 seconds for cold invocations
• Regional deployment: Higher latency for global users

When to use: Batch processing, infrequent executions.

3. E2B (Code Interpreter API)

Approach: Commercial code interpreter service with SDKs.

Pros:

• Purpose-built for LLM code execution
• Rich output formats (charts, tables)
• Good DX

Cons:

• Vendor lock-in: Proprietary API
• Cost: Higher than self-hosted (~$0.10 per minute vs Sandbox’s $0.01/hour)
• Limited customization: Can’t install arbitrary packages or run system commands

When to use: Prototyping, when time-to-market > cost.

Comparison Matrix

Verdict: Sandbox SDK offers the best balance of security (VM isolation), performance (edge deployment), and developer experience (TypeScript API + managed infrastructure).

Real-World Use Cases Beyond Infrastructure

While this article focuses on infrastructure automation, Sandbox SDK enables many LLM-powered applications:

1. AI Coding Assistants (Cursor, Copilot alternatives)

Execute LLM-generated code to verify correctness before showing to users:

const code = await llm.generate('Write a function to parse CSV files');
const testResult = await sandbox.runCode(`
${code}

# Test the generated function
import io
csv_data = "name,age\\nAlice,30\\nBob,25"
result = parse_csv(io.StringIO(csv_data))
print(result)
`, { context: ctx.id });

if (testResult.success) {
  // Show code to user with confidence
  return { code, verified: true };
} else {
  // Regenerate with error feedback
  return await llm.generate(`Previous code failed: ${testResult.error}. Fix it.`);
}

2. Data Analysis Notebooks (Jupyter alternatives)

Let users write Python/JavaScript for data manipulation:

// User writes: "Show me top 5 customers by revenue"
const analysisCode = await llm.generate(query, { context: dataSchema });

const result = await sandbox.runCode(analysisCode, { context: ctx.id });

// Return chart/table to user
if (result.formats.includes('html')) {
  return new Response(result.outputs.html, {
    headers: { 'Content-Type': 'text/html' }
  });
}

3. CI/CD Test Execution

Run tests in isolated environments without managing Jenkins/CircleCI:

const sandbox = getSandbox(env.Sandbox, `build-${commitSha}`);

// Clone repo
await sandbox.gitCheckout(`https://github.com/user/repo`, { ref: commitSha });

// Run tests
const testResult = await sandbox.exec('npm install && npm test', {
  stream: true,
  onStdout: (line) => sendToWebSocket(line),  // Real-time logs
});

// Report results
await reportToGitHub(commitSha, testResult.exitCode === 0);

4. Educational Coding Platforms (LeetCode, HackerRank alternatives)

Grade student submissions with LLM-generated test cases:

// LLM generates test cases based on problem description
const testCases = await llm.generate(`Generate 10 test cases for: ${problemDescription}`);

// Execute student's code against test cases
const result = await sandbox.runCode(`
${studentCode}

${testCases}
`, { context: ctx.id });

const passed = result.success && parseTestResults(result.output).allPassed;
await updateLeaderboard(studentId, passed);

When NOT to Use Executable Verification

Despite its power, this pattern has limitations:

1. Highly sensitive operations:

Database migrations, security configurations, production deployments should use pre-tested, version-controlled code, not LLM-generated snippets. The risk of catastrophic failure (e.g., DROP TABLE users) outweighs automation benefits.

2. Real-time autocomplete (<500ms latency requirement):

LLM generation (800-1500ms) + execution (50-300ms) = 1-2 seconds minimum. For instant autocomplete, use:

• Client-side static analysis
• Pre-validated snippet libraries
• Async validation (show unverified code, validate in background)

3. Deterministic operations:

If you’re just interpolating values into templates (e.g., “Generate Kubernetes manifest with image: nginx:1.25”), skip LLMs entirely:

// ✗ Overkill: Using LLM for templating
const manifest = await llm.generate(`Generate K8s deployment with image ${image}`);
const validated = await sandbox.runCode(`kubectl apply --dry-run -f - <<EOF\n${manifest}\nEOF`);

// ✓ Better: Use templates
const manifest = k8sTemplate.render({ image, replicas: 3 });

4. Low-value tasks:

If manual verification takes 10 seconds but LLM verification takes 6 seconds + ongoing maintenance, just do it manually. Reserve automation for high-frequency, high-value tasks.

Key Takeaways

1. LLM hallucinations require executable verification: Static analysis catches syntax errors, but semantic errors need real execution feedback.

2. VM isolation is non-negotiable: Container escapes are real (CVE-2022-0847). Use VM-based isolation (Sandbox SDK, Firecracker) for untrusted code.

3. Edge deployment reduces latency: Running code close to users (Cloudflare’s 300+ locations) provides <100ms response times globally.

4. Persistent execution contexts improve LLM accuracy: Maintaining state between iterations (imports, variables) lets LLMs build on previous attempts without re-initialization.

5. Limit iterations to 3: Beyond 3 attempts, LLMs generate increasingly complex but equally wrong code. Fail fast and escalate to humans.

6. Static analysis first, execution second: Catch obvious errors (syntax, dangerous patterns) before expensive LLM + sandbox calls.

7. Streaming improves perceived performance: Even if total time is 2s, streaming makes systems feel responsive.

8. Application security is your responsibility: Sandbox SDK handles infrastructure isolation, but you must implement authentication, input validation, rate limiting, and audit logging.

Conclusion: The Future of AI-Powered Development

Grounding LLMs with executable verification transforms unreliable code generators into trustworthy automation tools. By treating AI outputs as untrusted input requiring validation through actual execution, we catch hallucinations before they become production incidents.

Cloudflare Sandbox SDK makes this pattern practical at scale: VM-level isolation for security, edge deployment for performance, and persistent state for LLM learning. After deploying this approach across infrastructure automation, data analysis, and CI/CD systems, I’ve seen deployment failures drop by 80% while maintaining the flexibility of LLM-powered workflows.

As AI becomes central to software development, executable verification will shift from experimental to essential. The teams that master this pattern today will build the most reliable AI-powered tools tomorrow.

Resources:

• Cloudflare Sandbox SDK Documentation
• Sandbox SDK GitHub Repository
• Example: AI Code Executor Tutorial
• Workers AI Integration