Move, suspend and resume

Move a running job to another machine, suspend it with its state saved, resume it later, or stop it.

Warnings and limits

A move pauses the program, saves its state and starts it on the new machine. While it moves, the job does no work, and both machines can bill.
A suspended job runs no machine; its checkpoint is kept 3 days by default, and the job fails when it expires. Portal warns 18 hours before.
The time limit (ttl, 72 hours by default) counts the time machines run the job; a suspended job is not stopped by that count. While it is suspended, the same number of hours counted on the clock from its creation ends it instead, with its checkpoint kept 7 days for portal resume to continue it (see Suspend below).
A job whose budget is spent cannot be resumed or moved: raise the budget first.
Stopping a job saves its outputs (it gets up to 15 s to exit). Stopping a suspended job saves no outputs.
Requests about one job are handled one at a time, in order, and each is checked again when its turn comes: a suspend or a move that waited behind a suspension is refused, since the job is no longer running.
A move to an exact destination is quoted before it is accepted: a region or instance type its provider cannot price, more than 8 GPUs on Modal, or a GPU job's move to a CPU machine is refused with the reason ("SPEC is a CPU machine; the job needs a GPU (A10, 24 GB)"). An exact GPU type (aws:g4dn.xlarge, lambda:gpu_1x_a10, modal:gpu=T4) counts as the GPU machine it is. A move that waits for a pause point says why in the job's events; its paused time counts from the pause itself, and the wait before it is shown separately.
A job whose program has already exited is not moved, even while its machine is still shutting down and the job still reads running: the request is refused with "the job already finished" (or failed). A move accepted a moment before the program's end is dropped with an event, "move dropped: the job finished before it started", which portal events, portal explain and the console show.
portal move waits up to 15 s and prints the move's outcome: where it landed, or why it did not (for example "the job finished before it reached a point it can pause at; the job goes on where it was"). A move still under way after that is left to portal ps and portal events JOB; --no-wait returns as soon as the move is accepted, and so does --json unless --wait is given.
A move from Modal or Azure Container Apps counts the source machine against your connection's cap only for the move's window, not for its whole 24 hours.
A move, suspend or resume Portal accepted is kept until it runs, across Portal's own releases and restarts.

Move a running job

Preview first, then move:

portal move JOB --gpu L4 --plan
portal move JOB --gpu L4
portal move JOB --to SPEC

Use either --to SPEC or requirements (--gpu, --gpus, --cpus, --mem, --providers), not both. Portal pauses the program at a safe point, saves its state, starts the destination and continues there from the statement after the pause. If anything fails before the new machine takes over, the job goes on where it was. A job you move with --to stays on that machine type until you move it again.

A --to GPU that is not scheduled within Portal's bounded wait (5 minutes on Modal) leaves the job where it runs, with an event. Add --gpu-fallback same_provider or --gpu-fallback any to move to that provider's, or any provider's, cheapest other GPU of the job's size instead; the event names what was asked, what the job runs on and the price difference. See Run a job. portal move follows the move for up to 15 s and prints its outcome on one line: where it landed and how long it paused, or why it did not move. A move still under way after that is shown by portal ps once it lands, and portal events JOB says why if it does not. --no-wait returns as soon as the move is accepted. --json returns at once too, with outcome accepted, unless --wait is given: then outcome is landed, aborted (with reason), parked or pending. The MCP move tool answers the same fields: accepted at once, or with wait (at most 15 s) the move's outcome.

Suspend

portal suspend JOB

Portal saves the program's state as a checkpoint and releases the machine. Nothing bills for compute while the job is suspended; the checkpoint is kept in storage.

Time suspended does not count toward the running time limit (ttl, 72 hours by default): a job resumed after a day suspended still has what was left of its limit, and the resume event says how much ("71 h 50 min of its 72 h limit left"). A suspended job is not kept forever, though. Two clocks end it:

Its checkpoint expires 3 days after the suspension by default (the retention_days setting), when the job fails with "the checkpoint expired" and the checkpoint is deleted.
The time limit, counted on the clock from the job's creation while it is suspended: a job with a 72 h limit that is still suspended 72 hours after it was created ends with "time limit of 72 h reached while suspended; continue with portal resume JOB until <date>". It reads Stopped, its checkpoint is kept for 7 days from then, and portal resume JOB (the MCP resume, or Continue on the run's page in the console) continues it from that checkpoint within those days; portal status JOB shows the date. A job continued this way counts its suspended time, and its checkpoint's 3-day retention, from the resume on, never from before it. A job Portal is still landing after a notice is not ended by the limit while that landing is owed.

Set a shorter limit with --policy ttl.hours=N when a job should not wait long, or --policy ttl.on=false for one that may.

Resume

portal resume JOB
portal resume JOB --gpu T4
portal resume JOB --on SPEC

Without options, Portal picks the best offer that fits the job's requirements. With --on, it resumes exactly there. The job continues from where it paused. Portal never resumes a job on its own, after a notice or otherwise: resuming is always your choice, or your coding tool's on your behalf.

Stop

portal stop JOB

The script gets SIGTERM and, 10 s later, SIGKILL. Its working directory is saved as the job's output and its machine is terminated. On your own machine, stopping ends only the job: Portal never powers the machine off. A finished job, or one a person stops, has its checkpoints deleted.

Delete ended jobs from the history

portal rm JOB
portal rm --ended --project demo --before 2026-10-01

portal rm takes ended jobs out of every listing. It shows what it will delete and asks first (--yes skips the question). A running or suspended job must be stopped first. Costs and savings totals keep counting deleted jobs, and nothing in storage is deleted by it. A job whose end Portal decided still has its checkpoints for 7 days: deleting it means it can no longer be continued from them.