September 18, 2026

An asset is now simply its files — the version axis is gone, repeat harvests store far less, and folders no longer overwrite each other — plus hardware re-verification that reliably runs, and Pod asset actions that fail fast with a real reason.

Major features

An asset is its files — versions are gone

Until now, every harvest or upload into an existing asset created a new version, and the asset page made you choose between them. That axis is gone. An asset is simply the set of files it holds.

Harvest now adds new files and replaces a file at a path the asset already has. Nothing else in the asset is touched, and unchanged content is skipped.

What this changes for you:

Repeating a harvest costs much less. Unchanged files are no longer stored again for every version. A training run that keeps syncing the same folder now stores roughly a third of what it used to.
Rotated checkpoints stay. A checkpoint your script deletes on the Pod’s disk remains in the asset — harvest only adds and replaces.
Two folders no longer end up sharing one asset. Folders whose names differed only by a trailing number — outputs and outputs-2 — could previously be treated as the same series and overwrite each other’s files. Each folder is now tracked by the folder it actually came from.
A replaced file is kept for a grace period before it is cleaned up, so an accidental overwrite isn’t instantly unrecoverable.
Asset lists and pages are simpler. No version picker, no version column — you see the files, their sizes and when each arrived.

Assets you already had were carried across. Where an asset genuinely held unrelated content under different versions, those were separated into their own assets so nothing was lost.

If you read assets through the SDK, the version-shaped fields still respond for one more release so existing scripts keep working; they are deprecated and will be removed.

How harvest works → · Using assets → · Asset billing →

Improvements

Asset actions on a Pod now fail immediately, with the reason. Asking a Pod to receive, inject, or release an asset when it cannot — the target path is outside what the Pod mounts, the Pod has no asset transfer, or only linked assets are attached — is now refused when you ask, with an explanation. Previously the action appeared to be accepted and quietly did nothing.
The asset drawer shows what actually happened. A file set whose download failed at start-up used to still appear as a green Injected / Ready. Failures now carry their cause, and an injection that fails while the Pod is running records why.
Assets follow a Pod that moves to another machine. When a Pod restarts on a different machine, input assets that lived on a local volume are fetched onto the new machine rather than silently going missing.
Machine metrics no longer read as a real zero. When a GPU figure can’t be read, the Status tab shows — or the reason instead of 0%, and a machine that is switched off explains itself instead of returning an error page.
Live utilization no longer counts unreadable memory as 0 GB when summing VRAM for a running task.
Pod Edit is clearer. The machine the Pod is currently on is offered as a choice, a refused edit states the actual reason, and the move dialog explains why a move is being suggested.
Steadier Pod listings and host tables. Fixes to the Clients tab header, to listing toggles that acted on the wrong machine, and to storage machines showing controls that only apply to compute machines.

For hosts

Hardware changes are re-verified again. Swapping or losing a GPU is now detected from a baseline recorded once the driver is up, and the follow-up mini stress test starts only when every GPU is idle and requires a stable load reading from each one before it passes. Previously this check could be skipped entirely, or get stuck part-way and stay there.
The onboarding stress test is honest about image download time. The countdown now shows Starting… while the test image is pulled and only begins counting once load actually starts, so a slow download no longer eats the measurement window.
Boot analysis is more accurate. Ordinary reboots are no longer reported as thermal shutdowns, and power and error-log signals are read more carefully.
Updating packages no longer upgrades your container runtime. It is held at the version your machine is running, so an update can’t move it underneath your Pods.
Package updates no longer stall waiting for a prompt that nobody can answer.
A failed setup step now tells you what went wrong. The command’s output is included, with credentials masked, and the failure is recorded in your machine’s history instead of disappearing.
Reference GPU prices refresh weekly, so the pricing guidance you see tracks the market on its own. A price you set by hand is kept while it is in use.

Fixes

A brief gap in GPU device reporting no longer stops your Pod. A machine that momentarily reports no GPU devices used to look like it was short of capacity, which could stop a running Pod. It is now treated as a device outage: the Pod waits and resumes.
A stalled operation no longer blocks a Pod forever. A lifecycle operation that never completed could permanently block later create, start and stop requests on that Pod. Stale operations now expire and are cleared automatically.
Setup retries are capped. A machine stuck repeating a setup step now stops after ~60 attempts and reports the failure by email, instead of retrying indefinitely.
One machine’s setup failure no longer affects others. A failure during a batch of machine checks could previously stop the rest of that pass or mark unrelated machines as failed.
Cancelling a benchmark now takes effect instead of being dropped.
Storage allowance refunds that crossed midnight no longer leave the wrong day’s usage recorded.