Workflow modes
Select the runtime policy for attempts, features, scheduled work, replay, evaluation, and review.
workflowMode is a runtime policy, not a model setting or machine type. It controls which source, artifact, snapshot, promotion, and lifecycle operations a durable Sandbox Runtime may perform.
Most applications should begin with attempt. Choose a more specific mode when the workflow requires stronger source-control, review, replay, or retention behavior.
Mode reference
| Mode | Use it for | State to preserve |
|---|---|---|
readonly | Inspecting an existing result or snapshot without mutation | Readable source, snapshot, logs, and artifacts |
attempt | One-off AI work, research, scratch compute, or trying a change | Events, outputs, and optional checkpoints |
feature | Durable app-backed code intended for review or promotion | Isolated source ref, commits, checks, and review checkpoints |
patch_only | Producing a diff that requires approval before commit | Patch artifact and review decision |
hotfix | Urgent app-backed change with explicit review visibility | Source checkpoint, validation artifacts, and promotion record |
scheduled_run | Recurring automation without permanently hot compute | Schedule, run history, receipts, outputs, and optional volume |
rollout | Evaluations, benchmarks, scorers, or training-data generation | Inputs, traces, metrics, rewards, and selected artifacts |
replay | Reproducing or debugging a prior run from pinned state | Snapshot, input payload, logs, and new replay artifacts |
template_build | Building and validating a reusable launch image | Manifest, validation evidence, and published snapshot |
multi_feature_batch | Comparing several code changes or strategies | Parent summary plus child runtime artifacts and source refs |
Common product choices
User interfaces can translate plain-language intent into these policies:
| User choice | Runtime policy |
|---|---|
| Do one task | App-less attempt |
| Try a code change | App-backed attempt |
| Build a reviewable change | feature |
| Review a patch first | patch_only |
| Run this repeatedly | scheduled_run |
| Reproduce this failure | replay |
| Compare many variants | rollout or multi_feature_batch |
Resource size, lifecycle, and workflow mode remain separate decisions. A feature runtime can use small or large compute. An attempt can be deleted immediately or retained by an explicit policy. A scheduled runtime should normally materialize compute only for each run.
Promotion and authorization
Modes define capability boundaries, but they do not replace application authorization. A checkpoint records intent; waitForUser records a pause; a promotion policy records the allowed path. Your product should still require an explicit decision before publishing source, opening public access, or mutating an external system.
Lifecycle pattern
- Create the runtime with a mode and promotion policy.
- Materialize bounded compute only when the active step needs it.
- Record events, outputs, source state, and checkpoint hints.
- Stop or delete compute while the workflow waits.
- Resume from durable state when work continues.
- Archive the runtime when review and retention obligations are complete.
See runtimes, snapshots, and cleanup for the SDK flow and pricing and budgets for cost controls.