Dev box sandbox template

Use the Dev box profile for repositories whose setup crosses language boundaries: a Python service with a web frontend, a native extension or a build that needs system packages. Treat the checkout as disposable. The useful deliverable is a reviewable patch and the commands that validated it, so the sandbox does not need permission to push or deploy.

• Clone a specific commit or upload a source archive without your home directory or credential files.
• Install repository dependencies from pinned manifests and lockfiles.
• Document the working directory and required build commands before the agent starts editing.

git -C /work/project diff --check

• A patch with changed paths and a base commit.
• Build and test results including exit codes.
• A short report of environment dependencies the build required.

Build an unchanged checkout first. Apply a small known patch, run the same validation, and confirm the exported diff contains only task changes.

Start with 4 vCPU and 8 GB of RAM, then measure peak memory and task duration on a representative fixture. These are workload planning values, not a benchmark or a provisioned configuration. Use the sandbox cost calculator to estimate running time and retained snapshots.

• Repository scripts are executable input, including test setup hooks.
• Use short-lived read access for private source; keep write and deployment tokens in the control plane.
• Compilers and parallel test suites can exceed 8 GB; measure peak memory before increasing concurrency.

Keep model inference separate from this execution profile. A hosted model or gpuOS can decide the next action while the CPU environment runs it. The quickstart describes the account workflow and the proposed runtime contract.