12 November 2026 · VRAMfarm team

Don't pay for an idle GPU: auto-stop, tmux and stopping from code

An RTX 4090 left running from 6 pm until 9 am bills 15 hours: €8.85 for a night of nothing. With idle auto-stop, the same mistake typically costs about three hours, €1.77, and your /workspace folder is saved on the way out. Auto-stop is the safety net, though. The real savings come from a few habits: stopping between sessions, running night jobs so they don’t need you, and letting the job stop the server itself.

How idle auto-stop works

A server that nobody uses for about two hours gets a message from us: in the dashboard chat and, if you are not on the site, by email. If it stays idle for one more hour and its folder can be saved, the server saves /workspace and stops. You get a notice that it was stopped and that your folder is waiting for the next server. If the folder can’t be saved (your own Docker image, see below) you only get the warnings, and the server keeps running until you stop it. If an upload fails, the server also stays running, and you are told so.

What counts as use. We look at three signals:

• an open connection to the server through our address: SSH, Jupyter, or the app (ComfyUI, the chat, vLLM);
• data still flowing over those connections in the last half hour;
• GPU load above a few percent.

Any one of them is enough to treat the server as busy. A training run counts as GPU load, so it is never stopped while it computes, even with nobody connected. The times in the table are approximate. The two hours count from the last moment the server was in use, so after a long GPU job or a closed session the warning arrives about two hours later, give or take ten minutes.

What looks idle. An open Jupyter kernel with no browser tab and an idle GPU. A job that runs only on the CPU, such as unpacking a big archive or tokenising a dataset. A long download started on the server with nothing connected. If your work has quiet phases like these, press Still working when the message arrives, keep a connection open, or switch auto-stop off for that period.

Where it doesn’t apply. Auto-stop only stops a server whose folder can be saved, because stopping without saving would delete your files. That rules out servers started from your own Docker image: their folder can’t be saved yet, so they are never auto-stopped. You still get the idle message, but stopping those is up to you or your script, which the API guide for batch jobs covers.

Switching it off, and why you usually shouldn’t

The setting is in Settings: “Stop an idle server automatically and save its folder”. With it off, you still get the idle messages, at most every six hours per server, but nothing is stopped.

Turn it off only when you have a reason: a job with hours of CPU work between GPU steps, or a server you keep as a test endpoint that people call now and then. A one-off quiet phase is better handled with Still working, which leaves the safety net in place for next time.

Without auto-stop, a forgotten server runs until you stop it or until your balance runs out. A stop at zero balance doesn’t save anything: the disk is deleted along with whatever you had there. The billing guide has the details of what happens at zero.

The opposite problem: connections that keep a server busy

Because open connections count as use, a forgotten window can keep a server running all night just as well as a forgotten server. These are the usual suspects:

• a PowerShell or Terminal window with an SSH session you never closed;
• a Jupyter or ComfyUI tab left open in the browser;
• a VS Code or Cursor window still connected through Remote SSH.

From the server’s side, each of these looks like someone working. So when you finish, close the tabs and the session, or better, stop the server right away. Don’t wait for auto-stop to do it three hours later.

Habits that cut idle time

Stop between sessions. Preparing a server takes 2–5 minutes and isn’t billed. A new launch costs at least 15 minutes, and a ready-made app downloads its models again, which is billed. So the break-even depends on what you run:

A lunch break on an RTX 4090 costs €0.59 an hour if you leave it running. On an H100 at €3.90 an hour, or on a multi-GPU machine, the same hour hurts much more.

Use Save and stop, not Stop, when you’ll be back. Your LoRAs, outputs, notebooks and scripts come back on the next server, even on a different card. Storage costs €0.03 per GB per month. What is and isn’t kept is in what happens to your files when you stop a GPU.

Prepare where it’s cheap. Writing code, fixing imports and downloading a dataset don’t need an H100. Do them on your own computer or on a small card like the RTX 3060 at €0.12 an hour, save the folder, and launch the big card only when the job is ready to run.

Test on a slice of the data. Five minutes on 1% of the dataset shows the crash that would otherwise appear an hour into the full run, while the expensive card sits waiting.

Put the stop in the job. The best way to avoid paying for a finished job is to have the job stop the server. That is the last section below.

Overnight jobs with tmux

If you start a job in a normal SSH session and the connection drops (laptop lid, Wi-Fi, VPN), the job usually dies with it. tmux keeps it running on the server, independent of your connection. It works the same in the Jupyter terminal.

Check whether it’s installed with tmux -V. If not, install it; it goes outside /workspace, so repeat this on each new server:

apt-get update && apt-get install -y tmux

Then:

tmux new -s train          # open a session called "train"
python train.py            # start the job inside it
# press Ctrl+B, then D, to detach; the job keeps running
tmux ls                    # list sessions later
tmux attach -t train       # come back to it

Without tmux, nohup does the basic job and writes the output to a log file you can follow:

nohup python train.py > /workspace/train.log 2>&1 &
tail -f /workspace/train.log     # Ctrl+C stops watching, not the job

Two rules for anything that runs while you sleep. Write checkpoints into /workspace every 15–30 minutes, so a failure costs one interval, not the night. And top up before you start: a balance that runs out at 3 a.m. stops the server without saving.

While the job computes, auto-stop leaves it alone. When it finishes, the GPU goes quiet: about two hours later you get the warning, and an hour after that the server saves its folder and stops. That’s the safety net. The next section saves you those idle hours.

Stop the server from code when the job ends

Every server can be stopped through the API. Create a token in Settings → API tokens; it starts with gf_live_ and is shown once. Note your server number from My servers (the #1234 on the card). On the server:

export GF_TOKEN=gf_live_xxxxxxxxxxxxxxxx
export GF_ID=1234

python train.py; curl -s https://vramfarm.com/api/instances/stop \
  -H "Authorization: Bearer $GF_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"id\": $GF_ID, \"save\": true}"

The ; matters: the stop runs whether the training succeeds or crashes. With && instead, a crash would leave the server running. "save": true uploads /workspace first and then stops; billing continues for the few minutes the upload takes, and if the upload fails, the server keeps running. Leave it out to stop at once, with the disk deleted. On a server from your own Docker image, save has no effect and the server simply stops. Run the whole line inside tmux so the stop still happens if you disconnect.

In Python, the same idea with try/finally:

import os, requests

def stop_server(save=True):
    requests.post("https://vramfarm.com/api/instances/stop",
                  headers={"Authorization": f"Bearer {os.environ['GF_TOKEN']}"},
                  json={"id": int(os.environ["GF_ID"]), "save": save}, timeout=30)

try:
    train()                       # your training loop
finally:
    stop_server()

A word on the token. It sits on a machine that belongs to a host, so treat it as exposed: create a separate token for this, with a name like “self-stop”, and revoke it when the project ends. A token can launch, list and stop servers, but it can’t change your password or SSH key, or create new tokens. The Last used column in Settings shows whether a token is being used when it shouldn’t be.

If you’d rather keep the token off the server entirely, run the stop from your own computer or CI. A script there launches the server, waits for the job, copies the results and stops it. GPU API for batch jobs has that version in curl and Python, with a spending cap built in.