Reasoning produces an action. Execution produces evidence.
An agent can propose a script, a browser action or a code change. It still needs a computer to carry out that proposal and return a result. The useful loop is concrete: the model chooses an action, the application authorizes it, the execution environment runs it, and the model uses the resulting evidence to decide what comes next.
cpuOS describes the CPU side of that loop: task-scoped Linux environments for code, files, browsers and builds. gpuOS describes the GPU side: open models served from your own hardware. The two roles can be used with other providers; a sandbox does not require a particular model.
User task ↓Model reasoning (gpuOS or another provider) ↓ tool requestApplication authorization, limits and task state ↓CPU execution environment ↓ result, exit code and artifactsModel decides the next step or returns an answerGive each task the environment it needs
| Action | CPU profile | Evidence returned |
|---|---|---|
| Analyze uploaded data | Python | Computed values, script and charts |
| Fix a repository bug | Coding agent | Patch and test results |
| Check a web interface | Browser QA | Assertions and failure traces |
| Extract document facts | Document processing | Text with source and page references |
| Review a generated app | Web preview | Preview and build result |
These profiles describe preparation, outputs and limits rather than assuming every task needs the same image. Install the necessary toolchain, pass only the relevant data and preserve artifacts that a user can inspect. The catalog separates the five base profiles from specialized recipes.
Keep authority in the application
A model's proposed action is input to your system, not permission to act. The control plane decides which workspace owns a task, which destinations it may reach, how much CPU and memory it may use, and which operations require review. Long-lived credentials stay outside the environment that runs generated code.
- Give each user task separate files, process state and ownership.
- Bound execution time, tool-result length, retry counts and total spend.
- Approve publication and other external effects as separate application actions.
- Return failures honestly so the model can revise its approach instead of reasoning from invented success.
Firecracker is the intended microVM boundary in the product design. A working runtime also needs host hardening, guest image preparation, networking, scheduling, cleanup and observability. The current web application manages accounts and workspace state; connecting the execution service is a separate step described in the quickstart.
Measure action time separately from model time
A browser or compiler uses CPU resources while it runs. A model call uses its provider's inference resources. Separating those costs helps you choose an appropriate toolchain and avoid keeping execution environments idle throughout a long conversation. Pausing and snapshots belong to the execution backend's lifecycle, and their billing behavior must be verified there.
Use the sandbox cost calculator to compare task volume, running minutes, CPU, RAM and snapshot retention against the site's published planning rates. Then measure a real workload: dependency installation, browser tabs and test parallelism can change the numbers substantially.
Start with one bounded tool. The integrations cover framework wiring, and the guides cover isolation, code interpreters and browser workflows.