Sazabi
ChatSandbox

Memory and Resources

Understand sandbox resource limits, timeouts, and lifecycle behavior.

Sandboxes have resource constraints that balance execution capability with cost efficiency. This page covers the default limits and how sandbox lifecycle works.

Resource limits

Each sandbox runs in a containerized environment with dedicated memory, CPU, and storage resources. These resources are sufficient for most investigation tasks including data parsing, log aggregation, and visualization generation.

Resource limits are set at sandbox creation and cannot be adjusted dynamically. If a command exceeds memory limits, it will be terminated.

Execution timeouts

Different operations have different timeout limits:

OperationTimeout
Command execution30 seconds
Init script120 seconds
Sandbox creation120 seconds

Command execution

Each bash command or code execution times out after 30 seconds. This limit exists to prevent runaway processes and ensure responsive investigations.

For long-running operations:

  • Break work into smaller commands
  • Use background processes when appropriate
  • Consider whether the task is suitable for sandbox execution

Init script timeout

Init scripts run when a sandbox is first created. They have 120 seconds to complete all setup tasks including package installation, repository cloning, and configuration. See Init Scripts for guidance on keeping scripts within this limit.

Lifecycle and idle timeout

Sandboxes have automatic lifecycle management:

SettingValueDescription
Idle timeout10 minutesStops sandbox after inactivity
Auto-deleteImmediateDeletes when stopped

How idle timeout works

  1. Each command execution resets the 10-minute timer
  2. After 10 minutes without activity, the sandbox stops automatically
  3. Stopped sandboxes are deleted immediately to avoid storage costs

Resuming work

When you return to a thread after the sandbox was deleted:

  • A new sandbox is created automatically on the next command
  • The init script runs again to restore your environment
  • Files created in the previous sandbox are not preserved

Sandbox contents are ephemeral. Important files should be saved as artifacts or committed to a repository before the sandbox is deleted.

Persisted vs ephemeral data

Understanding what persists helps you work effectively with sandboxes:

Persisted across sandbox sessions:

  • Project memory at /memory (stored externally)
  • Cloned repositories (re-cloned on new sandbox)
  • Artifacts saved to the thread

Lost when sandbox stops:

  • Files outside /memory
  • Installed packages (reinstalled by init script)
  • Running processes
  • Environment variables set during commands

Working within limits

Memory-efficient patterns

When working with large datasets:

  • Stream data instead of loading entirely into memory
  • Process files in chunks
  • Use tools designed for large data (e.g., jq for JSON, awk for text)

Avoiding timeout issues

For complex operations:

  • Split work across multiple commands
  • Use the assistant to break down multi-step tasks
  • Let the assistant handle orchestration rather than writing monolithic scripts

Storage considerations

Sandbox storage is used for:

  • Cloned repositories
  • Installed packages
  • Temporary files from analysis

If you hit storage limits:

  • Clean up temporary files between operations
  • Consider whether all repositories need to be cloned
  • Remove unused packages from init scripts