Portal starts machines in cloud accounts you connect, and those machines cost money. They are billed to you by your providers under your agreements with them. Every charge for a machine Portal starts is yours: while it runs, after a move, including a move Portal makes by itself, after an interruption, and after a failure on our side.
What Portal does
Portal moves a running Python job from one machine to another. It pauses the job at a safe point, saves what it has in memory and in its working directory as a Checkpoint, carries the Checkpoint through storage we operate, restores it on the destination, and checks that what arrived is what left before the destination takes over. It shows prices across the Cloud Accounts you connect and starts a job on the offer that you, or a Coding Tool acting for you, choose. When a provider gives notice that it is taking a spot machine back, when a job runs out of memory in a way Portal can recover from, and about 30 minutes before a provider’s fixed time limit, Portal saves a Checkpoint and suspends the job rather than losing it. Portal does not resume a suspended job by itself: you, or a Coding Tool acting for you, choose when and where it resumes.
Portal also acts on running jobs by itself. Unless you change these settings for your workspace, a project or a job, Portal:
- moves a job to a cheaper offer, or from an on demand machine back to spot capacity, when the move saves at least 20% and at least three times what the move costs;
- moves a job on spot capacity to an on demand machine when its state has grown past what the provider’s notice could save;
- suspends a job that has made no progress and used under 5% of one processor core for 30 minutes; and
- stops a job after 72 hours of running time. A suspended job also ends once 72 hours have passed since it was created or last resumed, and you can still resume it from its Checkpoint for seven days after that.
A job you start on one exact machine is not moved in these ways. Otherwise, unless you limit the providers and regions a job may use, a move Portal makes by itself can go to any machine the job’s requirements allow, in any Cloud Account and region you have connected, and the job’s memory and files go with it. Each move starts a new machine that your provider bills, and both machines bill while the move runs.
You use Portal through the Portal Software on your own machine and the console at portal.clusy.io, both of which work through Portal’s server. You sign in with your Portal account, as section 2 describes.
Other arrangements. Portal as these Terms describe it is our hosted service. If we agree to provide Portal to your organisation in another form, such as a dedicated deployment, a separate written agreement with your organisation governs it and sets its price, its support and its security commitments. Where that agreement and these Terms differ, that agreement controls.
Access and limits
Anyone who meets section 4 and section 22 may sign up for Portal, and Portal makes a workspace for you once your email address is verified. We may limit who can use Portal, which providers, regions and kinds of machine it supports and how much it will run at once, and we may change or withdraw any of that without notice; the limits in force are in our documentation. Treat Portal as a preview under section 5: it is not yet the place for work you cannot afford to lose.
Your Cloud Accounts
You connect a Cloud Account by giving Portal a way into it: a role it can assume, a federated identity, or a token or key, as our documentation describes for each provider. Connect only accounts you are authorised to use, with the narrowest access that works. The account stays yours. You are responsible for its bills, its quotas, its security and for complying with the provider’s terms, and you can revoke Portal’s access at the provider at any time.
If you connect a Cloud Account from the command line tool with your own cloud login, or let a Coding Tool do that for you, the Portal Software uses the cloud command line tools you are signed in to on your machine to make what the connection needs in your Cloud Account, such as an IAM role and policy on AWS, a resource group and an app registration with access to it on Azure, or a service account, a custom role and a key on Google Cloud. That can include registering Azure resource providers and turning on Google Cloud APIs. It shows the plan first and makes nothing until the plan is confirmed. Portal’s server also turns on Google Cloud’s Compute Engine API if the key you save allows it. To quote prices and check costs, Portal reads your Cloud Account’s prices, quotas and spot placement scores, and on AWS it reads Cost Explorer once a day, which AWS charges for. Portal never asks your provider for more quota, but its instructions to Coding Tools tell them to request the increases you need with your own cloud login, when you agree or have already authorised it. Requests and changes a Coding Tool makes in your Cloud Account with your own login are yours, under your agreement with that provider.
In a connected account Portal creates what a job needs, such as virtual machines with their disks, public addresses and network interfaces, container tasks and the clusters and environments they run in, security groups, networks, log groups, SSH keys whose private half it discards and, the first time you run on Azure Container Apps, a container registry. It tags what it creates, or names it where a provider has no tags, so that it can be told apart from your own resources. It records every machine before starting it, sets a hard deadline on the machine itself so that it powers off even if Portal’s server is unavailable, and sweeps for leftovers. That protection has limits. Some providers keep billing for a machine or disk that has stopped: a Lambda instance or an Azure virtual machine bills until Portal deletes it, which Portal cannot do while its server is unavailable. A provider can accept a stop request and take time to carry it out. The Azure container registry stays, and Azure bills you for it, until you delete it. Portal stops and deletes only what it created and tagged or named. On AWS its machines start in your account’s default network, which is tagged for Portal’s use when you connect the account. Check your provider’s console, and treat anything still running in your account as yours to stop.
Removing a connection deletes the credentials Portal stored for it straight away, although they remain in our database backups for about seven days. Portal refuses to remove a connection while a machine runs on it, its setup is running or an unfinished job is pinned to it. Removing it does not revoke Portal’s access at your provider and deletes nothing in your account: roles, keys, app registrations, service accounts, the tags on your default networks, the container registry and anything else Portal or its setup made stay there until you remove them.
Computers you enrol
You can also enrol a computer of your own so that Portal runs jobs on it. An Owner of your workspace approves each computer with a pairing code. Jobs there run as the user Portal’s agent runs as, normally the user who installed it, with that user’s files and permissions and no sandbox, so a job can do whatever that user can. Jobs on the same computer share those files, so one job can change what a later one uses. Spending caps do not apply there, and Portal never powers the computer off; it stops only its own jobs. Enrol only computers you are authorised to use, and run there only jobs you trust.
Prices, estimates, caps and budgets
The prices Portal shows are quotes from provider price lists, read live where a provider publishes them that way and otherwise taken from a copy we keep, which can be out of date; where a region’s own price cannot be read, a quote can use another region’s. A quote leaves out disks, public addresses, data transfer, taxes, credits and discounts. The costs Portal shows are estimates: the rate recorded for each machine when it started, times the time the provider bills for, counting the provider’s minimum billing, plus the data transfer of the job’s moves. They leave out everything else a quote leaves out and anything a provider charges late, and they are never an invoice or a promise about one.
A spending cap on a connection and a budget on a job are optional, and off unless you set them. A cap stops Portal starting a machine, or extending a running machine’s deadline, beyond what the cap covers, and when the cap would be reached Portal suspends the running job, or stops it if the suspension fails. A budget suspends its job, or stops it if you choose, shortly before the job’s estimated cost reaches the budget, and a failed move can take a job past its budget by what the abandoned destination cost. Neither caps what your provider can charge.
Where Portal reports a saving, it is an estimate: what the dearest machine the job used would have cost at its on demand price for all the machine time you paid for, plus the work Portal preserved through spot interruptions and out of memory rescues, less what you paid, and never below zero. What moving cost you is shown separately. Your providers bill it, except the transfer from our storage described in section 6, which we pay for and do not bill you for today.
What travels, and what can be lost
Portal moves Python programs. A move needs the same Python minor version and compatible library versions on both machines, and storage both can reach. What travels is the program’s state: its objects, tensors and arrays, its position in its loops, its random number streams and its working directory. Some things cannot travel: open files, sockets in use, threads, other processes, some native objects and files outside the working directory. A move or suspension is refused while the job holds one of them, and a Checkpoint taken for a provider’s notice then fails. Functions compiled with numba are compiled again where the job lands.
On arrival Portal checks every tensor and array against the digest taken when it left and compares fingerprints of the whole state; a difference aborts the move and the original keeps running. That check confirms the state is the same. It cannot confirm that your program behaves the same on different hardware or with a differently built library, and we have seen a restored model compute differently after a move that reported success. Test moved work before you rely on it.
Work since the last Checkpoint can be lost. A Checkpoint has to finish inside the time a provider gives before it takes a machine back, which is two minutes with some providers and a few seconds with others, and a Checkpoint that does not finish in time saves nothing. Azure Container Apps and Lambda give no notice at all. A process that is killed before it saved cannot be checkpointed afterwards. Keep your own copies of inputs and results, and write results out as you go.
When you start a job, Portal uploads your working directory. Files over 100 MB are left out, and so are files whose names look like credentials and JSON files that hold a private key; Portal does not otherwise look inside your files for secrets. A directory over 500 MB is refused. Do not keep secrets in files Portal would upload or in environment variables you pass to a job, which are stored readably; use Portal’s secrets, which are stored sealed and given only to the jobs that name them. A Checkpoint can hold any secret your program has read into memory.
What we store, and for how long
Portal’s server keeps the credentials for your Cloud Accounts, sealed with a key for your workspace that is itself protected by a key held in AWS Key Management Service, never shown back to you and never given to a machine Portal starts. The one exception is a job on Azure Container Apps: Portal stores a registry credential in that job’s settings in your own subscription so that Azure can fetch Portal’s image, and for a connection made with a client secret that credential is the secret itself. Portal’s server also keeps your job records, including the script path, arguments and environment variables you pass; what each machine reports about itself and the job, including its installed packages, its resource use and where a failed program exited; cost records; and an audit log of actions.
Your uploaded working directories, each job’s output stream, up to its first 256 MiB, and job outputs are kept in object storage we operate, and Portal adds no encryption of its own to them. Checkpoints are encrypted with a key made for that job, which Portal’s server holds, unless an Owner of your workspace has turned that off for new jobs. They are kept in object storage we operate at Cloudflare, Amazon Web Services, Google Cloud or Microsoft Azure, chosen for the speed of the transfer, which can be outside the United States. This is not end to end encryption against us: people who administer Portal’s AWS account for us can, in principle, read a Checkpoint, and section 21 applies to it as it does to other content. They can also export your workspace’s records, add a person to your workspace in any role from their next sign in, approve a computer waiting to join your workspace without its pairing code, freeze your workspace, end your access to Portal, and create a time limited token for a Coding Tool in your workspace. Each of those commands is recorded in the audit log. A token made that way is not one you approved; it appears in your workspace’s list of agents, where you can revoke it.
A suspended job’s Checkpoint is kept for three days, a period we set and you cannot change yourself. About 18 hours before it expires, Portal marks the job as expiring in its events, but does not email you; when it expires the job ends, and its Checkpoints are kept seven more days. A Checkpoint is deleted once a move it carried succeeds or the job resumes from it, and a job’s Checkpoints are deleted when it finishes or you stop it. When Portal ends a job for another reason, such as a failure, a lost machine, a time limit or the end of your access, its Checkpoints are kept seven days. A failed move’s Checkpoint is normally deleted an hour after the move, and a Checkpoint that fails its arrival check is kept for one day so the mismatch can be examined. Job outputs are kept for seven days from when they are saved. An uploaded working directory that no job takes is deleted after one day, and a job’s own copy of it when the job ends, though copies of its working files may remain on Portal’s server’s file system and in its backups.
Portal sets no expiry on your job records, each job’s output stream, your cost records or the audit log: they are kept for as long as your workspace exists, though a storage rule may remove an output stream sooner, and section 29 says what happens when you ask us to delete them. Removing an ended job from your history hides it and stops it being continued, but it does not erase the job’s records or its output stream, and its cost still counts; its outputs and Checkpoints are deleted only on the schedule above. Our security page describes the controls, and the Privacy Policy what we keep after you leave.
Coding Tools acting for you
Portal’s MCP server and command line tool let a Coding Tool run Portal for you, under a sign in that an Owner or Administrator of your workspace approves in the console, or under a token made there. Either carries only the scopes approved for it, which can never include administration. A tool with the jobs scope can start work that costs money in your Cloud Accounts, give a job the secrets stored in your workspace and remove ended jobs from your history, and a tool with the connections scope can change connections, secrets and spending caps. Actions a tool takes under access you approved are your actions under these Terms, including under section 17.
A sign in from the command line tool or MCP server lasts until it is signed out or revoked, and a token made in the console lasts 1, 7 or 30 days. Approve the narrowest scopes that will do, give a tool a budget where you can, and revoke access you no longer need. A budget on a sign in or token limits each job the tool starts, not all of them together. Our software tells Coding Tools to ask you before they launch, spend, connect an account or delete anything; that is advice to the tool, not something our servers enforce. The scopes, budgets and caps are. What a Coding Tool reads from Portal, such as job details and output streams, and what Portal finds about the cloud logins on your machine, goes to that tool and the AI provider behind it under your agreements with them, not through us.