Ask Claude to start the training. Come back tomorrow and ask how it went.

A fine-tune runs for ten hours. The chat you started it from will not last ten hours, and neither will your laptop's battery. AI Commander starts the run as a detached job on your own GPU box, hands back a job id, and gets out of the way — the run keeps going after the chat ends, the laptop sleeps, or the network drops.

Nothing to keep open

You already know the ritual. Open a terminal, ssh into the box, start tmux so the session survives the connection dropping, launch the run under nohup with output redirected somewhere you will remember, detach, and then hope you can find your way back to the same pane tomorrow. Half of that is ceremony for keeping a session alive that nobody wanted to keep alive.

A detached job removes the ceremony. The agent spawns the process on the machine, writes its stdout and stderr to a file there, records the exit code to disk, and returns a jobId to the caller immediately. Nothing on your side has to stay connected for the run to continue:

• Close the chat — the job does not belong to the conversation, it belongs to the machine.
• Shut the laptop, get on a train, lose Wi-Fi. The run is not on your laptop.
• The machine drops offline for an hour. The process is untouched; you simply cannot query it until the machine is back.
• Pick it up tomorrow from a different client — the phone, another laptop, a script — with the jobId.

One honest exception, on the platform most GPU boxes run: on macOS and Windows the job also survives the AI Commander agent itself restarting. On Linux the agent runs as a systemd service and its jobs live inside that service's control group, so stopping, restarting or upgrading the agent takes running jobs down with it. Upgrade a Linux GPU box between runs, not during one.

No tmux, no screen, no SSH session to keep alive. Ask for the run, then ask later how it went.

Pick the machine, then reserve the card

Before anything starts, the agent needs to know where to put it. list_machines reports every machine on your account, and every NVIDIA card on each one — model, total and used VRAM in MiB, and current utilization. session_status reports the same for a single machine. That is enough to choose a box from data the client already has, instead of blind-probing each one with nvidia-smi:

No GPU section at all means no NVIDIA card or no driver on that machine — the agent should say so rather than try. Where a card is busy, the fix is not to hope: remember the card's index and pass it as gpu_index when starting the job. That takes an exclusive lock on the card and sets CUDA_VISIBLE_DEVICES for the job, so a second job asking for the same card is refused with gpu_busy, naming the job that holds it, instead of both runs hitting CUDA OOM four hours in. The lock is released when the job ends.

The figures are a reading the machine pushes about once a minute. While a machine is offline they are its last known values and may be stale.

The five tools, and their REST twins

Five MCP tools cover the whole life of a job, and each one has an HTTP equivalent for clients that do not speak MCP. code names the machine exactly as it does for /api/v1/exec — in the JSON body for the POST, and as a query parameter everywhere else.

cwd must be an absolute path that already exists, and env takes string values only. There is no elevated option for jobs — a job runs with exactly the rights remote_exec has on that machine. Full shapes and error codes are in the tool reference and the machine-readable OpenAPI spec.

What it looks like

A PyTorch fine-tune, in a uv workspace under the user's home, on the free card:

Nine hours later, from the phone, in a brand new conversation:

The offset_bytes round-trip is the whole trick for following a long run: each log reply carries a nextOffsetBytes, you hand it back on the next call, and you get only what was written since. Note that nothing polls on its own: there is no scheduler and no callback, so a job is looked at exactly when someone asks about it — which is why the jobId matters more than the conversation it was started in. See the GPU jobs skill for the full procedure an agent follows — workspace layout with uv, the CUDA sanity check, and where model weights should land.

What this is not

Your own box is a real alternative to Modal or RunPod for this work — it is your hardware, your disk, and a real shell. What it is not is a managed platform, and it is worth being blunt about the difference:

• Nothing schedules. There is no queue. A job starts when you ask for it, or it is refused — gpu_busy if the card is taken, too_many_jobs at 32 running jobs on a machine. Poll and retry, or pick another card.
• Nothing retries. A crashed run stays crashed until someone starts it again.
• Nothing is kept for you. Finished jobs — metadata, log and workspace — are retained for about a week and then removed automatically: the agent sweeps expired jobs in the background, roughly hourly, driven by job start and list activity. Starting or listing a job can therefore be the thing that deletes an older expired one. Copy out anything you want to keep well before the week is up.
• unknown means unknown. If the agent restarted and the process is gone with no recorded exit code, the outcome genuinely cannot be determined. It is not a quiet success; read the log and check your checkpoints.
• A job outlives you. Nothing stops one started by mistake — it burns GPU, CPU and disk until it finishes or is cancelled. Expensive work deserves an explicit confirmation before it starts.
• There is no file transfer. To get a checkpoint off the machine, have the job push it to storage you already control as its final step.

Set it up

On the GPU machine (Linux), install the agent:

Follow the signed Linux installer steps and verify the installer before sudo.

Connect your AI client, save the machine under an alias like gpu-box, and describe the run you want started.

FAQ