Agents can hold a GPU, and you can run several deployments and Tinker sessions
The Compute MCP server can create and use held machines, and an account can keep several model deployments and Tinker sessions live at once.
compute_create_machine holds a GPU after you confirm the spend, and compute_get_machine reports when it is ready. Pass its machine_id to compute_run, or to compute_dry_run then compute_run on the hosted server, to run on it without a new boot; compute_delete_machine stops it.
Deploy a model and Start a Tinker session no longer wait for your other deployments, sessions or runs. Each one bills and stops on its own.
compute tinker run and compute tinker shell now start a new session instead of offering to stop or join one that is already live.
The local MCP tools and the Tinker change need CLI 0.1.23.
Keep a GPU warm between runs, and run several machines at once
compute machines create holds a GPU that later runs use in seconds instead of booting a new machine, and an account is no longer limited to one live machine.
compute machines create --gpu SKU starts a machine and waits until it is ready. compute run --machine ID and compute exec --machine ID then run on it one job at a time, with no new boot. compute machines rm ID stops it.
A held machine bills per minute while it is up, including idle minutes between jobs, and holds credit for its whole lifetime when you create it. It stops by itself after 10 minutes with no job (--idle) or 8 hours after it became ready (--max-lifetime).
Runs, model deployments, Tinker sessions and held machines no longer block each other. Prepaid credit and the per-hour and per-day spend limits still bound what an account can spend.
compute exec runs a shell command on a GPU, streams its output, and brings the files it changed back to your project. On a held machine it uses the machine's image.
Deploy models on AMD MI300X, and start with a smaller balance
Safetensors models can deploy with vLLM on AMD MI300X, and a spend limit now lowers the balance a deployment needs to start.
When Hot Aisle has MI300X capacity, Deploy a model offers vLLM 0.29 on AMD next to NVIDIA machines. GGUF models still run on MI300X with llama.cpp. Until AMD vLLM completes its first live deployment, the deploy page marks it unproven and bills startup from allocation.
Starting a deployment needs $0.50 plus the lesser of one hour at the quoted rate and your spend limit, and at least $1.00. On MI300X, a $0.90 limit needs $1.40 instead of $3.77.
Stopping a deployment while its machine is still being allocated now finishes, a failed stop shows its error on the deployment page, and a deployment whose host was replaced during startup bills and stops normally.
MI300X capacity is no longer hidden when Hot Aisle also lists a two-GPU machine.
One-touch model deployments are generally available
Deployments is now available to every signed-in customer from the dashboard.
Open Deployments, choose Deploy a model, and paste a Hugging Face model ID or URL to get a recommended machine and a current price.
Review the configuration, billing terms, and spend limits before deploying. Follow startup, access your private endpoint, and stop the deployment from its detail page.
Model and hardware availability still depend on compatible runtimes, model access, and provider capacity.
Startup evidence stays with the run, and uncertain provider cleanup remains visible.
Use compute logs RUN_ID --format jsonl, or compute_get_logs with format=jsonl, to inspect startup observations even when application logs are empty.
Provider status, reported container uptime, agent readiness and workload start are recorded separately. Missing or zero uptime is not proof that your code ran.
If an allocation response is lost, cleanup stays unconfirmed until the provider identity is reconciled. The release adds guarded monitoring delivery; live routing and exact-target GPU qualification are tracked separately.
Reinstall from the quickstart for CLI 0.1.18. Existing clients remain supported.
compute report files a bug report with a durable acknowledgement id, and answers at once when the cause is already known. Reinstall from the quickstart to get CLI 0.1.12.
compute report "<summary>" --run run_… stores the report before returning rpt_…, and attaches the run's status, provider, and error so you do not have to.
Outdated CLI, low balance, a known provider condition, or a duplicate of your own open report get an immediate reply; everything else is answered by an operator, visible with compute report status rpt_….
Agents get the same through the compute_report_issue and compute_get_report tools in compute mcp and mcp.compute.cx.
