What's New in CloudRift: Agent Skills, Fairer Billing, and Saved Disks
Everything that shipped in versions 0.62 and 0.63, translated from the changelog
Engineering posts every CloudRift release in our Discord, and the changelog carries the full notes. Those notes are written for people who run the platform. This post is for everyone else. It covers what changed between early September and late October 2026, what it means if you rent GPUs, and what it means if you host them.
Your coding agent can rent the GPU now
CLI version 0.62.1 ships a skill install for coding agents. One command, rift agent install, adds CloudRift skills to Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, and OpenCode. The installer detects which agents you have, and the shell installer refreshes the skills on every CLI update while keeping your local edits. The API exposes the same operations as MCP tools, so an agent that speaks MCP can discover capacity, rent an instance, and read its hardware without a wrapper.
Around that, the CLI grew the commands a rental needs, whether a person or an agent is typing. rift instance list shows your rentals across personal and team accounts, with JSON output for scripts. rift instance inspect prints the hardware and the SSH command. rift instance ssh connects by name or ID, and rift instance reset, new in 0.63.0, power-cycles a VM that stopped answering. The Instance Management and AI Agent Skills pages have the details.
You pay for a running VM, not for waiting
Two releases closed gaps in how rentals were charged. Since 0.62.0, the funds for a rental are held when you create it and charged once the VM is running. If the VM never starts, or the node stops responding, the hold is returned and you are not billed. Since 0.63.0, billing stops the moment you terminate, even if the node is still cleaning up behind the scenes. Reservation purchases and extensions now check your balance in the same transaction that charges, which fixed a race where two purchases in the same minute could overdraw an account.
Keep your disk between rentals, where the provider allows it
Volumes remain the way to keep data you cannot lose. On top of that, a terminated VM's disk can now outlive the rental. Since 0.61.0 you can re-attach a saved disk to a new rental on the same node. Version 0.63.2 added the rules: the new rental must be a VM with the same or a larger disk. Version 0.63.3 keeps the disk beyond the node's erase window as long as the node has free space, and erases the oldest disks first when a new rental needs the room.
How long a disk survives depends on the provider and on demand for that node. It can be minutes, and it can be days. Treat it as a convenience and put anything important on a volume.
For operators: roles, privacy, and a fleet view that scales
Version 0.63.3 is the operator release. You can now give people or teams access to your provider account by role. Operators run the fleet day to day. Viewers get read-only dashboards with no access to customer passwords. Roles are set per provider account, so the same person can operate one and only view another. In the same release, customer names and emails disappeared from everything provider staff see: node listings, networks, allocations, team members. Your staff work with tenant IDs, and only platform admins see identities.
The node list also grew up. It accepts search, filters, sorting, and pagination, and returns a summary with totals and status counts. Each node now reports its datacenter, its provider, the health of each GPU, and the Rift version it runs, which rift node list shows too.
Two earlier changes matter for how you set up nodes. Since 0.62.1 a network can carry an outbound proxy, and every VM that gets an address from it receives the proxy settings for package downloads, Docker, and curl through cloud-init. And a node with an allocation is no longer closed to other customers: whatever the allocation does not hold stays rentable by everyone else, and the node reports that unallocated capacity explicitly.
Two more are about resilience. Since 0.63.0 the platform recovers on its own after a node reboot or an agent restart: running VMs start again, stopped ones stay stopped, and the server reconciles what it finds instead of trusting a stale cache. Since 0.63.2 a VM's disk is allocated in full when the rental is provisioned, so a node that cannot hold the disk fails the rental up front instead of running out of space while the VM is in use.
Smaller things you will notice
Catalog VM images are checked against the GPU before the VM is created, so an image with the wrong NVIDIA driver flavour is rejected with a message that names an image to pick instead. Since 0.63.3 that check reads the image's own metadata rather than recipe tags. Listings no longer offer more RAM than a host can back from its hugepage pool, which used to surface as a boot error. Nodes survive a libvirt restart, which previously broke every VM operation until the agent was restarted. And instances carry free-form tags you can filter by, from the CLI with --tag and from the API.
How to get it
Re-run the CLI install script to pick up the current version. Node operators receive agent updates through the platform; the changelog marks the releases where a client update matters. Release posts land in Discord first, and the changelog follows within days.
