Portaldocs
Help

Known limits

Every limit and risk to weigh before you run a workload through Portal, in one place, with what to do about each.

Warnings and limits

  • This page gathers the limits that decide whether a workload goes through, in words. Each is also on the page it belongs to, and the numbers are on Limits.
  • Portal tells you about a limit when it applies: in a plan, in the job's events (portal explain JOB), or in the sentence that refuses a request. This page is for reading before you launch.
  • Portal is open to anyone with an active Clusy account and a verified email address.

Before you launch

  • Your quotas and capacity come first. A connection proves neither quota nor capacity, and Portal never requests an increase. AWS EC2, Azure VM and Google Cloud VM quotes read your vCPU, GPU and spot quotas and list an offer your quota cannot fit as unavailable, with the quota named; a quota Portal cannot read is reported as unknown, never as room. See Quotas and capacity.
  • A quote reserves nothing. Capacity can be gone by the time Portal launches. When no offer has capacity, Portal tries up to 4 offers, then ends the job as no_capacity (exit code 4) with choices: the same machine on-demand, spot in pools it did not try, or, for a GPU type Modal could not schedule, Modal's other GPU types, each with its price and an exact on= spec. Portal never switches on its own.
  • Modal's L4 pool is scarce. A Modal job pinned to one GPU type ends no_capacity after 5 minutes without it; T4, A10 and A10G start at once as a rule. A GPU job on Modal says what it waits for every minute. See Modal.
  • What goes up. A launch uploads the directory you run it from: files over 100 MB are left out, a project over 500 MB is refused, and files that may hold credentials never go up. See Run a job.
  • Your packages win over Portal's. The job's environment installs Portal's own dependencies (dill, cloudpickle and the rest) as compatible ranges, so your pins decide. Requirements that cannot resolve together fail the environment build, and the job's error carries uv's reason. On Modal the environment is an image built on first use, 30 minutes at most, and built once more afresh after a failure.
  • Python 3.12 by default, 3.13 or 3.14. Portal runs a script, not a notebook.
  • Google Cloud organizations that deny external IPs. Portal's VMs need a way out to reach Portal. Where the organization policy constraints/compute.vmExternalIpAccess denies VMs external IPs, they go out through Cloud NAT with private networking: connecting picks that when Cloud NAT serves the network, and otherwise stops with the commands that set it up. Portal never changes the policy. See External IPs.
  • Windows. The CLI runs on macOS and Linux; on Windows, in WSL. See Install.
  • Stored secrets cannot be used in runs yet. See Known issues.

While it runs

  • A spot machine's notice decides what can be saved. AWS spot 2 minutes, Google Cloud 120 s (25 s when Google refuses the longer notice), Azure spot VMs 20 s (the event names a time 22 to 27 s out, less than the 30 s Azure documents, and Portal's node sees it within a second), Modal GPU sandboxes 5 s; Azure Container Apps, Lambda, on-demand machines and your own machines give none. A checkpoint must pause the program, save and upload inside the notice. Portal warns in the plan when a job's state is larger than the offer's notice can save: take an on-demand machine or a longer notice. See Spot and checkpoints.
  • Azure Container Apps gives no interruption notice. If Azure stops the execution, progress since the job's last checkpoint is lost; Portal parks a Container Apps job only on your suspend, a move or a policy. On 2026-10-31 a stopped execution's replica was gone 0.55 s later, before any checkpoint. Every Container Apps quote, the plan that chooses one and the job's events say so, and portal interrupt is refused there: test resilience with a suspend or a move. See Azure.
  • A pause waits for a pause point. A long native call, a running thread, an open file, a child process, os.walk, a finally block, asyncio or a comprehension in progress keeps the program from pausing until it ends. The job's events say why (pause, once per reason in 5 minutes). A spot checkpoint that cannot pause inside the notice loses the work since the last checkpoint.
  • Some values cannot be carried. An open file, a socket in use, a thread, another process, or a file outside the working directory. A move or suspension you ask for is refused when the job holds one, with the value's name, and the job stays where it is; a spot checkpoint fails. An in-memory StringIO or BytesIO, and a closed socket, move.
  • Out of memory. Rescued only when Python raises the error inside a loop of your script's own code; the iteration that failed runs again from its start after the resume. On Linux CPU machines Portal caps the program's memory a little under the machine's (a reserve of 10%, 256 MiB to 1 GiB), so running out raises a Python MemoryError instead of the operating system killing the process; there is no cap on GPU machines. A rescue whose checkpoint fails twice for the same reason ends the job with the capture's message. See Out of memory.
  • Provider time limits. Modal sandboxes and Container Apps replicas run 24 hours at most, Google Cloud VMs 24 hours by default; Portal checkpoints and suspends the job 30 minutes before. The time limit policy stops a job after 72 hours of running time, and an idle job (30 minutes under 5% of a core) is suspended. See Automatic actions.
  • Budgets and caps act early and hard. A budget acts 2 minutes of the machine's price early, and must cover the machine's first lease (90 minutes) at the price the provider reserves, on EC2 spot the dearest zone's, or the launch is refused. A connection's cap refuses a machine whose worst case would pass it. A job whose budget or cap is spent cannot be resumed or moved until it is raised. See Caps and budgets.
  • A Modal region is Modal's choice unless you pin one (region=us, eu or ap, at Modal's premium): a sandbox can land far from the others, and a move of a large state pauses longer.
  • A job that finished keeps its machine until the provider confirms the end (minutes for an EC2 GPU instance). The console reads it as Finishing, nothing after the program's exit is charged, and a stop sent then changes nothing.

After a notice, a move or a suspension

  • Portal never resumes a job on its own. After a notice, an out-of-memory rescue, a spent budget or a provider's limit, the job is suspended and waits for you or your coding tool. See Suspend and resume.
  • A suspended job's checkpoint expires after 3 days (a warning 18 hours before), and the job fails. After an end Portal decided, checkpoints are kept 7 days. See Checkpoints and retention.
  • While a move runs, both machines can bill, and the job does no work. A move to an exact destination is quoted first: a destination its provider cannot price, or without the job's GPU, is refused when asked.
  • A pinned job is not moved for a cheaper offer: a job started with an exact --on keeps its machine until a notice, a rescue, a limit or you move it.

Money

  • Costs and savings are estimates from recorded rates and running times, not invoices. Quotes leave out disks, public IPv4 addresses, data transfer, taxes, credits and discounts. Azure Container Apps jobs also use a Basic container registry Portal makes in your subscription, which Azure bills. See Prices.
  • A saving is never negative. What you paid beyond rate times time (a pause billed on two machines at once, a provider's minimum, a slow termination) is shown as Portal overhead on its own line. See Savings.
  • Spot prices change. Portal prices a spot machine at the rate it recorded when the machine started.

Storage and retention

  • A job's output is kept 7 days, its logs 30 days from when each part was written, and only the first 256 MiB of its output is kept. Portal keeps a job's newest 20,000 events and 20,000 samples (about 55 hours). See Outputs and logs.
  • Checkpoints are encrypted with a key of each job's own; outputs and logs are not. Keep files you would not upload out of the working directory.
  • portal pull works once a job has ended. No output is saved when a suspended job is stopped, when its checkpoint expires, or when its machine was lost.

Portal itself

  • One Portal process serves every workspace. A release pauses it for a few seconds: a request Portal accepted before the release is kept and runs after it, and nodes redial at once.
  • The job list and the overview answer from a cache kept 20 s: a job's creation, status change or deletion shows at once, other changes within 20 s.
  • Changing settings, approving machines and cleaning up leaked resources are an Owner's, in the console only. See Known issues.

On this page