Budget sandbox runtime around complete task stages

Budget for the complete workflow

A useful runtime budget includes setup, execution, verification, export and cleanup. Allocating enough time only for the main transformation can leave the task with an unreviewed artifact or an unresolved running resource. Estimate the stages before creating the sandbox and define a smaller scope that remains useful if time is tight. Human verification, billing enrollment, provider configuration and workspace permissions are prerequisites, not stages the agent can silently bypass. A bootstrap key does not authorize paid compute. Check readiness before asking the workload to depend on a resource that cannot be allocated.

Keep resource and command time separate

The container resource has an authorized running interval, while each synchronous command has its own requested timeout. A long command timeout does not extend the resource's runtime. The Boat adapter also has a provider request deadline, so a client may lose the response before it knows what happened inside the guest. Choose short observable stages and leave enough resource time to reconcile an uncertain command. In billing-enforced workspaces, finite runtime reservations are validated against plan limits and the billing-cycle boundary before the provider mutation. Read the actual rejection rather than guessing that more retries will create more time.

Interpret usage_seconds as runtime

Lupin's usage_seconds combines completed running intervals with the current interval when the resource is running. It is not CPU time, the sum of command durations or a prediction of an invoice. An idle sandbox can accumulate runtime while the agent is writing a report or waiting for an operator. Conversely, several commands within one running interval do not each define a new resource lifetime. Review the current billing catalog and workspace usage instead of inventing a machine size or rate from provider marketing. The public adapter does not expose a general compute-sizing control to tune.

{"name":"bounded-transform","timeout_seconds":120}

Remove waits that do not need compute

Prepare prompts, inspect local inputs and decide the verification plan before creating the resource when those steps can happen without it. Export the final artifact and stop the sandbox before spending a long time polishing the answer. For a human review that cannot fit the remaining runtime, save the relevant result and use a later authorized stage rather than keeping an unexplained idle machine running. Reuse a running sandbox for related approved commands when it is appropriate, but do not make reuse a reason to retain unnecessary services, secrets or public ports.

Stop at a known stage boundary

As the budget shrinks, finish or cancel the current stage through the program's supported mechanism, save verified partial output and stop the resource. Report which work completed and which did not. If a command's outcome is unknown, preserve its key and inspect history or artifacts before launching a replacement in another sandbox. An expired resource is not a successful task checkpoint. Good time budgeting produces a reviewable partial result when completion is impossible, along with confirmed cleanup or a precise unresolved lifecycle issue, rather than a vague claim that the task will continue somewhere in the background.

Sources & verification

Reviewed against the current Lupin route, provider adapter and shared input contracts, plus the linked official references. Examples were not run against live services.

• docs.boat.dev · long-running-tasks · auto-stop ↗Checked 2026-11-05
• docs.boat.dev · snapshots · stop ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.