Auto-stop
Walk away from a GPU and it warns you, captures your environment and volume, and releases the machine. A pod you forgot about stops billing instead of running all weekend.
Provider coverage
Works the same way on every provider: auto-stop captures your environment and volume, then releases the machine using the same mechanism a manual Stop does, not a provider-specific stop API. Idle detection reads the same utilization data as Live GPU Metrics, so a GPU profile that can't report utilization (for example, a vGPU-based card) shows as "we can't read utilization on this box" instead of being guessed at.
Off until you turn it on
Nothing you deploy is watched unless you ask for it. In the console deploy sheet, switch on Stop it when it goes idle and the pod is watched from the moment it comes up. You can also turn it on later from that pod's Idle tab. Leave it off and nothing is watched or stopped.
It is per pod, never account-wide, and it is never switched on retroactively for boxes you already have running. A pod created through the API or the aq CLI has it off unless you set the policy explicitly.
The toggle works the same way on every provider: it captures your environment and volume, then releases the machine using the same create-and-terminate mechanism a manual Stop uses, not a provider-specific stop API, so there's no per-provider list to check before you rely on it. Start later brings that pod back on a fresh machine, possibly on a different provider. It is the same round trip manual Stop and Start use.
Left at their defaults, the thresholds are 5% GPU utilization, a warning at 30 minutes idle, and auto-stop at 60 minutes.
Warn, then auto-stop
Set a GPU utilization threshold that counts as idle, how many minutes of that before you're warned, and how many minutes before it acts. Utilization at or under the threshold for the warn period sends an email. The box is still running and still billing at that point. Staying idle past the act threshold captures your environment and volume first, then releases the machine.
The warn threshold always has to sit below the act threshold; the console won't save a configuration where the warning would fire after the box was already stopped.
Four states, and unknown is a real one
A pod with auto-stop configured shows one of: in use, idle, idle past the auto-stop threshold, or we can't read utilization on this box. That last one is not a rounding of "probably idle": it's an explicit unknown, shown whenever utilization or on-box presence can't be read, and it never triggers an auto-stop.
Presence is read from the on-box agent, which sees SSH logins and browser-terminal sessions. The system doesn't infer that nobody is on a box from silence: an unreadable signal stays unknown rather than being treated as idle.
FAQ
Is auto-stop on by default?
No. It is off unless you turn it on, on every surface. In the console, switch on "Stop it when it goes idle" in the deploy sheet before deploying, or turn it on later from the pod's Idle tab; through the API or the aq CLI, set the idle policy explicitly. Once on, it works the same way on every provider: it captures your environment and volume then releases the machine, the same mechanism a manual Stop uses everywhere. It is per pod rather than account-wide.
What happens right before it stops the box?
It captures your environment and volume to storage first, the same capture used for a manual Stop, then releases the machine. It's a file save, not a resume point for whatever was running in memory.
What does "we can't read utilization" mean?
It means the platform genuinely can't tell whether the box is idle or in use: the utilization reading or the on-box presence signal is unavailable. It's shown as its own state and never treated as idle, so it can't trigger an auto-stop on a guess.
Can I change the thresholds after deploying?
Yes. Open the pod's Idle tab to turn auto-stop on or off, or change the utilization threshold, warn minutes, and act minutes at any time.
Does it work the same on every provider?
Yes. Capturing the environment and volume and releasing the machine uses the same create-and-terminate mechanism a manual Stop uses on every provider, not a provider-specific stop API, so there's no per-provider list to check. Idle detection itself reads the same utilization data as Live GPU Metrics everywhere, so a GPU whose virtualization profile can't report utilization shows as unknown rather than being marked idle.
