A rented GPU costs money from the moment it boots and long before it can do anything useful, so five measurements decide — inside a hard time budget — whether it ever gets work, and the ones that fail are destroyed rather than parked.
Renting compute from a marketplace is a two-stage problem, and the stages have very different prices. The first stage is cheap: filter a catalogue by an allow-list of acceptable GPU models, a ceiling on hourly price, a floor on memory, a floor on the host's own reliability history, then take the cheapest offer that still qualifies. Nothing has been spent at this point — and nothing has been verified either, because a catalogue entry is a description written by the seller.
The second stage is expensive, because it happens on hardware you are already paying for. The billing clock starts at "rented", not at "ready to work." Boot, first answer, and every measurement taken afterwards are all spend against a machine that has demonstrated nothing. That window is the reason the audit is bounded by wall-clock time rather than retried until it succeeds.
The home page shows the short version of this: ask a pool for five machines, watch more than five get booted, watch each one get measured, and watch the ones that fail get killed. This page is what measured means, and why the window in which you are paying for an unproven machine is deliberately short.
Each check runs on the machine itself, in a fixed order, cheapest first. The first failure ends the audit — there is no reason to time the disk of a box whose card is already wrong.
The sequence starts with authentication, and that is not a formality. A marketplace can mark a machine ready as soon as its login port accepts a connection; that is a statement about the port, not about the machine. Completing an actual authenticated session is the first thing that distinguishes a running host from an open socket, and a whole class of broken rentals lives in the gap between those two facts.
| Check | What it actually measures | What it catches |
|---|---|---|
| Authenticate | A login session completes, not merely a port answering | A host that is listening but not usable |
| The GPU | The card responds and its memory is read from the driver | A different card, fewer cards, or less memory than listed |
| The specs | Core count, system memory, disk capacity | An oversubscribed host handing you a slice of what was advertised |
| Disk speed | A timed 512 MB write to the working volume | Shared or throttled storage — a model load that takes an hour |
| Network speed | A timed 100 MB download | A link too slow to pull model weights in usable time |
This is the check anyone would write, us included, and it is the reason this page exists. A card does not report the size it is sold as. The driver holds back a slice for its own bookkeeping, so the figure you can measure sits a little under the figure on the listing. Write the comparison the obvious way — measured memory must be at least the requested memory — and it rejects exactly the hardware you asked for, every single time, with nothing that looks like a bug anywhere in the code.
The consequence is not a rejected machine. It is a loop. The rental is destroyed for failing a check it can never pass. The next search returns the same shape, because the same shape is still the cheapest offer matching the request. It is rented, it reports the same number, it is rejected again. Each pass around that circle is a real rental with a real bill and no output — and from the outside it does not look like arithmetic. It looks like scarcity: capacity that can never quite be found.
The fix is small and unglamorous: measured capacity is compared against the requested figure less five percent. That absorbs what any driver holds back and is nowhere near enough to admit a card of a genuinely smaller class. A threshold set to exactly the right number is a threshold that is sometimes wrong, because hardware does not report round numbers.
A machine that fails is torn down within seconds of the verdict. If the measurements lived on that machine, every failure would be permanently unexplainable: you would know that something failed, never what was measured or by how much it missed. So each check writes its result away from the machine as it completes — which step, what value, and the reason for the verdict, not merely pass or fail.
Passes are recorded as well as failures, and that is the part people skip. A single box failing a disk timing is a bad box. Every box of one shape failing the same timing this week is a supply problem worth acting on, and the second pattern is only visible if you kept the numbers from the machines that passed. Records that only exist when something goes wrong cannot tell you that things are getting worse.
Four outcomes, two of which are refusals. The refusals are the ones that cost nothing and save the most.