GPU CLI 0.32: native Windows and remote GPUs for coding agents

GPU CLI 0.32 now runs natively on Windows.

That includes the gpu command, the background daemon, installation, updates, project initialization, daemon lifecycle commands, and the dashboard. No WSL. No Linux compatibility layer. A coding agent working in PowerShell can use the same remote GPU workflow as one running on macOS or Linux:

gpu run uv run python train.py

This is a big expansion of what GPU CLI can be. Windows is where a huge share of AI development, creative tooling, and local NVIDIA work already happens. With 0.32, those projects can keep their native local environment while sending expensive work to cloud GPUs through one consistent CLI.

The rest of the release makes that CLI much easier for coding agents to operate reliably.

Native Windows. Parallel GPU jobs. Built for coding agents.

GPU CLI 0.32 in one screen

• Native Windows CLI and daemon — Agents can work directly from PowerShell without WSL
• gpu prime and agent docs — The installed CLI teaches agents the current workflow
• Concurrent detached jobs — One agent can keep several named GPU instances busy
• Durable wait, logs, and exit codes — Long jobs survive terminals, laptops, and agent sessions
• Billing history and idle-spend limits — Autonomous work has visible cost boundaries

The agent learns the workflow from the CLI

gpu prime gives an agent a compact, project-aware operating guide:

gpu prime

It covers the conventions agents commonly get wrong: use uv instead of pip, forward secrets with --env, use GPU CLI port forwarding instead of raw SSH, and check gpu status or gpu logs when a run fails.

It also summarizes the current gpu.jsonc, including the provider, GPU preference, and encryption setting. gpu init installs a Claude Code hook that injects this guidance at session start and before context compaction. Other agents can call gpu prime directly; it is plain Markdown on stdout.

For command details, agents can query the installed binary instead of relying on stale documentation:

gpu agent-docsgpu agent-docs --json

GPU CLI also catches mistakes at run time. If an agent reaches for pip install, it suggests the project's uv workflow. If a command contains a literal token, the CLI names the variable without echoing its value and shows the safer pattern:

gpu run --env HF_TOKEN="$HF_TOKEN" -- uv run python train.py

Long GPU jobs now behave like automation

Agent sessions end. Terminals close. Laptops sleep. The remote job should keep going.

In 0.32, detached runs are owned by the background daemon. An agent can submit work, get structured identifiers immediately, and wait for the durable result later:

gpu run -d --json -- uv run python train.pygpu wait job_abc123 --json

gpu wait exits with the remote job's own exit code and returns the job id, terminal state, and exit code as JSON. gpu logs can recover output even after the pod is gone.

The rest of the automation contract is tighter too:

• gpu doctor exits non-zero on real failures
• JSON errors are one machine-readable line on stderr
• gpu --version prints one line
• Dropped log streams no longer determine whether a job succeeded
• Closing a terminal no longer kills a still-provisioning pod

For an agent, these details are the difference between guessing and knowing.

One agent can keep several GPUs busy

GPU CLI 0.32 removes the concurrent-session limit, so an agent does not have to wait for one experiment to finish before submitting the next. Detached jobs aimed at one pod can queue; jobs aimed at separate named instances run concurrently.

From PowerShell, an agent can dispatch two independent jobs and retain both receipts:

$jobs = @(  gpu run -d --json --target gpu-a -- uv run python train.py  gpu run -d --json --target gpu-b -- uv run python evaluate.py) | ConvertFrom-Json
$jobs | ForEach-Object { gpu wait $_.job_id --json }

Everything after -- is the project's command, not a GPU CLI option.

That makes parallel evaluation, data preparation, rendering, and experiment sweeps a normal CLI workflow. The agent can launch the work, continue editing locally, and collect each result through the same durable job interface.

Sync, spend, and security have stronger guardrails

GPU CLI 0.32 makes remote state safer when an agent is editing the local workspace at the same time.

Output pulls are atomic, declared outputs arrive before a job is marked complete, and stale local syncs no longer overwrite a job's results. Transfers use independent peer-to-peer streams, so one large checkpoint does not block every small file behind it. The new exclude setting keeps tracked weights, fixtures, or build output out of uploads:

{  "exclude": ["models/**/*.safetensors", "fixtures/golden/**", "build/**"]}

Cost is visible earlier and controlled more carefully. Provisioning pods appear in status immediately, terminated pods keep their historical spend, and an agent can request an account-wide rollup:

gpu status --billing

A dollar-denominated idle backstop protects against forgotten pods, even if the laptop disconnects:

gpu init --max-idle-spend 10

Stopping is safer as well. A bare gpu stop is scoped to the current project, and termination waits for the provider's real outcome instead of reporting success while a pod keeps billing.

The transport security moved forward with the reliability work. File sync and artifact transfers authenticate the owning daemon, the local daemon socket is restricted to the current user, and dispatched jobs do not inherit the daemon's provider credentials by default.

A shorter path from repository to GPU

From an agent's perspective, the complete workflow is now small:

# One-time setupgpu auth runpodgpu init --max-idle-spend 10
# Give the agent current project guidancegpu prime
# Run remotely and wait for a durable resultgpu run -d --json --env HF_TOKEN="$HF_TOKEN" -- uv run python train.pygpu wait job_abc123 --json
# Confirm what is billinggpu status --billing

There is no new framework to adopt. The agent works on the same repository and runs the same commands the developer would run locally. GPU CLI supplies the remote hardware, durable execution, sync, and cost boundary.

The move from 0.22.7 to 0.32 is substantial, but native Windows support is the headline. GPU CLI now gives agents on all three major desktop platforms the same direct path from a local repository to a remote GPU.

Update with:

gpu update