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:
| Operation | Timeout |
|---|---|
| Command execution | 30 seconds |
| Init script | 120 seconds |
| Sandbox creation | 120 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:
| Setting | Value | Description |
|---|---|---|
| Idle timeout | 10 minutes | Stops sandbox after inactivity |
| Auto-delete | Immediate | Deletes when stopped |
How idle timeout works
- Each command execution resets the 10-minute timer
- After 10 minutes without activity, the sandbox stops automatically
- 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.,
jqfor JSON,awkfor 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