remote-compute-modal

You're dispatching to the user's Modal account: containers spin up in Modal's cloud, on hardware you name in plain terms (gpu/cpu/memory/timeout), under their workspace, on their bill. That's the reason there are two approval cards rather than one, and the reason the env-setup surface is a separate kernel rather than something you can call inline from the control-plane kernel: each card is the user consenting to a specific, bounded use of their credential, and the architecture keeps those grants legible by keeping the surfaces apart.

If compute.create('byoc:modal', …) returns unknown provider 'byoc:modal', Modal isn't enabled in this install — ask the user to enable it under Settings → Compute → Modal (or surface the prompt; you can't enable it for them).

For first-time environment setup, see env-setup.md in this skill directory — it walks through driving the compute_provider kernel to build and record images.

Two timeouts, one timeline

Modal has two deadline timers. Both live INSIDE the sandbox, and neither can cost you the outputs of a job that ran. The timeline every job runs on:

1. Container life starts at sandbox creation — staging the inputs counts against it, so a big upload spends container time before the job runs.
2. The job runs. If it exceeds its own budget (the job timeout below), it is TERMed there.
3. Near end of container life — one harvest margin before the provider destroys the sandbox — the in-sandbox harvest watchdog TERMs whatever is still running. It runs on the sandbox's own clock, so a wrong desktop clock or a slow upload can't make it fire late.
4. After any TERM there is a grace window for checkpoint-on-TERM handlers to flush, then the process group is stopped.
5. Whatever is under ./out/ (plus the logs) is tarred and staged UNCONDITIONALLY — on success, timeout, failure, and crash alike — and harvested back into the workspace. Staging is unconditional; delivery isn't. If the stream is refused or gives up (result_rejected, harvest_failed), the staged copy waits on the sandbox, and a third, post-job timer — the idle watchdog — terminates it after ~30 min of inactivity. See "When the job fails".

The container timeout (provider_params.modal.timeout) is how long the sandbox lives; omitted, it fills from the Settings default for this provider (Settings → Compute → Modal; ceiling: Modal's 24 h platform lifetime, minus the staging margins — 85,500 s). The job timeout (timeout_seconds on submit_job) is an optional runaway guard for one job; omitted, it defaults to the container's remaining life minus the harvest margin. Name one when you know the job's budget — a hung job then costs that budget, not the whole container, and the warm container survives for the next submit.

A deadline-ended job lands as status: 'timed_out' — not a generic failure — with its partial outputs already harvested, plus a note saying the deadline (not the workload) ended the run and suggesting the remedy: a larger timeout_seconds, or resuming from a harvested checkpoint. A deadline ends the run, never the results.