Create your account and workspace
Create an account, then open the dashboard. Use the workspace to organize your sandbox records, API credentials and execution profiles. Existing account holders can sign in directly.
The public site presents cpuOS's intended execution platform. Account and workspace management are separate from the runtime: a sandbox record is a request to execute a task, and it becomes a running machine only when an execution backend provisions it. The application does not run Firecracker or execute generated code by itself.
Choose an execution profile
Start from the template catalog. Python suits data analysis, Node suits JavaScript tooling, Browser suits rendered pages, Dev box suits repository builds, and Custom describes an image you prepare. Workload recipes such as Rust builds or document processing explain how to prepare one of these bases; they are not additional built-in images.
- Choose the smallest CPU and memory allocation that passes a representative fixture.
- Set a command deadline and a separate maximum session lifetime.
- Define required inputs, allowed network destinations and expected output artifacts.
- Estimate running time and retained snapshots with the cost calculator.
Understand the proposed runtime contract
The SDK examples on this site describe the intended integration shape. Before installing a package, confirm its availability, version and the endpoint provided by your execution service. The code below is an API contract sketch; it requires that service and is not a working runtime bundled with the website.
// Proposed SDK contract, requires a connected runtimeimport { Sandbox } from "@cpuos/sdk"const sandbox = await Sandbox.create({ template: "python", vcpu: 2, memory: "4GB", timeout: "15m",})await sandbox.files.write("/work/input.csv", csv)await sandbox.files.write("/work/analyze.py", generatedCode)const result = await sandbox.exec("python /work/analyze.py", { timeout: "2m",})// Return a bounded result to the model and retain useful artifacts.if (result.exitCode !== 0) { throw new Error("Analysis failed; inspect bounded stderr")}const chart = await sandbox.files.read("/work/output/chart.png")const pausedId = await sandbox.pause()The model call stays outside the sandbox. A tool wrapper validates the action, writes its input, executes the bounded command and sends stdout, stderr and the exit code back to the model. See the code interpreter guide for that loop and the integrations for framework-specific wiring.
Handle task lifetime and results
| Phase | Application responsibility |
|---|---|
| Create | Authorize the workspace, pick a base profile and enforce resource and spending limits. |
| Execute | Validate arguments, bound runtime and output, preserve failures as tool results. |
| Collect | Return a result manifest, download approved artifacts and redact credentials. |
| Wait | Pause through the execution backend if supported; store the session ID with its owner. |
| Finish | Terminate the runtime and apply your retention policy to files and snapshots. |
A recorded status must reflect a confirmed backend action. Do not label a task running, paused or complete merely because an API request was accepted. Handle timeout, provisioning failure and loss of the runtime connection explicitly.
Validate the connected execution service
- Run a small successful script, a failing script and a timed-out script. Verify exit codes and bounded logs.
- Create two sessions with distinct marker files. Confirm their files, credentials and process state remain separate.
- Use a staging destination to test allowlist enforcement and denial of unintended network destinations.
- Verify resource limits, snapshot ownership, cleanup and billing behavior before accepting user workloads.
- Run repository or document inputs inside the isolation boundary, including dependency installation and parsers.
The safe code execution guide explains these boundaries. For the model side, gpuOS serves open models on your own GPUs; cpuOS's role is to organize the CPU actions those models request.