Work, sandboxes, and runtimes

OpenPond exposes one compute system through three levels of control. Pick the highest-level surface that still gives your application the control it needs.

Decision table

| Surface | Who plans the work? | State that survives | Best for | | --- | --- | --- | --- | | Work | An OpenPond-hosted model | Your conversation plus outputs persisted by your application | Reports, documents, analysis, code edits, and other outcome-focused tasks | | Raw sandbox | Your application | The sandbox filesystem until you stop, archive, or delete it | Known commands, build jobs, tests, services, and file processing | | Sandbox Runtime | Your workflow engine plus optional agents | Runtime identity, events, checkpoints, source state, artifacts, and retention decisions | Review flows, scheduled jobs, replay, promotion, and multi-step products |

Work mode

openpond.work.run creates or reuses isolated compute, gives a model bounded file and command tools, detects completed files, and returns a structured lifecycle result. For ordinary Work, prefer fresh compute per turn:

1. Supply the prompt, history, and any durable prior files through inputs.
2. Set cleanup: "delete".
3. Persist each output in persistOutput.
4. Treat result.lifecycle.cleanup.status as the cleanup receipt.

This keeps arbitrary scratch state transient. A later turn can still revise prior work because the application stages the latest durable output revisions into a new sandbox.

Raw sandbox mode

Use openpond.sandboxes when commands and paths come from your application rather than a model. A raw sandbox gives you direct access to files, commands, processes, PTYs, preview ports, Git operations, snapshots, receipts, and lifecycle actions.

Raw sandboxes do not delete themselves merely because an HTTP request returned. Your application owns cleanup. Use explicit spend, duration, idle, command, port, and snapshot limits at creation, then delete the sandbox when its result has been exported.

Runtime mode

A Sandbox Runtime is a durable control-plane record around one or more periods of compute. It can materialize a sandbox, record sparse events and checkpoint intent, wait for user input, preserve source state, and later resume or recreate compute.

The runtime is durable; its sandbox does not need to stay running. This distinction is useful for scheduled work and review workflows: keep the workflow record and its artifacts, but release compute between active steps.

A practical rule

• Start with Work when the user describes an outcome.
• Start with a raw sandbox when your code already has the execution plan.
• Add a Runtime when the workflow needs identity, review, replay, scheduling, checkpoints, or promotion beyond one compute session.

Next, review pricing and budgets and workflow modes.