Skip to main content

Set the application contract

Choose these values in application code:
  • Modal Environment;
  • one supported Function and Sandbox region selector;
  • Function and Sandbox CPU and memory;
  • Function and Sandbox Images;
  • timeouts, retries, and scaling limits;
  • warm-capacity settings.
The canonical example uses retries=0, min_containers=0, and no Sandbox warm pool.

Deploy the Function once

The owner can then create a desktop, produce its handle, and invoke the deployed Function. Keep the owner alive until that call reaches a terminal outcome.

Verify placement before mutation

The Function decorator and ComputerConfig.runtime.modal_region must use the same selector. Borrow entry compares that request with the observed Function and target placement. A public narrow selector can resolve to concrete AWS, GCP, or Azure region identifiers. A granted granular selector requires an exact runtime match. Missing or unverifiable placement fails before desktop mutation.

Inspect cost-bearing settings

The report omits tokens, URLs, typed text, clipboard text, screenshots, and artifacts. Record the Function settings separately because the Function and Sandbox have independent resources and billing.

Clean up in ownership order

  1. Stop new work.
  2. Wait for the Function call or seal its outcome.
  3. Release the borrow.
  4. Close the owner and terminate its Sandbox.
  5. Confirm that no unintended warm or billable capacity remains.
Use ComputerSandboxManager.cleanup_expired(..., dry_run=True) before any stale-resource cleanup.