Home›Products›GPU Pods
Sort offers by scorecard, rent by the second, connect over SSH or Jupyter. The second you shut down, billing stops; you don't pay for seconds that don't work anyway.
This is the product that works today. We are in Phase 0: supply comes from the pools of integrated providers, and our own host network joins the same marketplace in Phase 1.
The flow
Four steps. No sales call, no commitment, no minimum duration, no reservation fee in between.
Narrow the pool by GPU model, VRAM, price range, scorecard threshold, region and a Verified-only filter. The default sort is by score: price, host scorecard and network are weighed together — the cheapest row is not always on top. Filters are written into the address bar, so you can share a search.
Pick the image (a ready template or your own), give the disk size and environment variables, and set a separate budget cap for the pod if you want. Before you confirm, the hourly, daily and end-of-month cost preview stays on screen. If the offer went stale before you pressed the button, we show the new price and ask again.
Once the pod is up, the SSH command and the Jupyter link are ready in the pod detail. A browser terminal, live log stream, GPU/VRAM/temperature/power telemetry and the files on disk are all on the same screen. Your secrets are encrypted at the application layer; they never land on the host's disk.
The counter ticks every second; live cost and the end-of-month estimate stay on screen. Say stop and payment stops, the disk stays. Say delete and the disk goes too — and we state that plainly before deleting.
Why here
Every host is benchmarked continuously. The placement score weighs price, the reliability scorecard and network latency together; the components of the score expand above the row. The scorecard is not a black box — you should be able to see why a row sits where it does.
Spend updates every second. The monthly cap is not an indicator but an enforced rule: notices go out at 80% and 95%, and when the cap fills, pods are stopped — not deleted, and your disk stays. Storage and traffic are separate, visible line items.
Pin your pod to a country or a group of regions; the pin is enforced server-side, and an interface filter is not treated as a security boundary. For an unpinned pod the screen shows different, honest wording — we don't let anyone read a guarantee that isn't there.
The SLA-backed, on-site audited Verified host tier falls under Phase 3 and is not open yet. What works today is scorecard scoring and region pinning. Detail: sovereignty.
API
One key to search offers, spin up a pod, stream logs. The CLI and the Python SDK use the same endpoints; for anyone who wants to poke by hand there is a thin REST surface.
Hardware
Hosts set the price and competition pushes it down; our commission is 15 percent and we do not hide it. The rows below are example starting prices from the pool — the live ones are in the console.
| GPU | VRAM | Typical work | Starting price (example) |
|---|---|---|---|
| RTX 3090 | 24 GB | Stable Diffusion, small LLMs | $0.21/hr |
| RTX 4090 | 24 GB | Fine-tuning, image generation | $0.42/hr |
| L40S | 48 GB | Inference, video | $0.79/hr |
| RTX A6000 | 48 GB | Long context, render | $0.88/hr |
| A100 PCIe | 80 GB | Training, 70B inference | $1.32/hr |
| H100 SXM | 80 GB | Serious training runs | $2.19/hr |
These are illustrative figures; on the marketplace they move second by second with supply and demand. Storage and network traffic are separate line items, tracked with a live counter on the billing screen. Many GPUs in one machine exists today; clusters that join several nodes into a single job do not exist yet.
The guarantee
Not a marketing sentence but a rule in the code that produces the invoice: a second that fails the health check enters no line item.
The pod's health is measured at regular intervals and every measurement is recorded. The green band in the pod detail shows this; if health drops, the band turns to a warning and a "not being billed right now" counter starts.
The moment a measurement record is marked unhealthy, that second does not enter the compute line item. It is not an amount refunded later; it is an amount that never formed. In the metrics tab those intervals are marked on the chart — you can count them with your eyes.
If a health correction arrives after the invoice was issued, the equivalent is written to your account as a credit row and appears in the "refunded" total on the billing screen. Which pod, which minutes — the breakdown expands.
When the cap fills, pods are stopped, not deleted; the disk is preserved and you get a notification. Raise the cap and continue where you left off.
Let us write the limit down too: if your job crashes while the machine is healthy — out of memory, faulty code, the wrong image — those seconds are billed, because the hardware you rented was working. The guarantee covers the time the hardware and the connection were not working. The exact definition of that limit is written in the docs; we don't leave it open to argument.
Frequently Asked
It does. A stopped pod's disk is preserved and is right where you left it when you start again. In exchange the storage charge keeps accruing: storage accrues on stopped pods too — and stops on a deleted pod. We don't bury that row in the invoice. If you want data to be independent of a pod's lifetime, look at persistent storage.
First billing stops: a second that fails the health check is never written. Then the pod is marked "failed", the reason sits in the event stream in machine-readable form, and a "restart on a similar offer" action appears in the console. If something goes wrong on the provider side at the moment of renting, we move to the next best offer and tell you about that switch explicitly — whose GPU spins underneath is our job to handle, but staying quiet is not.
Today you can bring your own container image; common images such as PyTorch, vLLM and ComfyUI sit as ready options on the rent screen. Images are verified with cosign, and an unsigned image is rejected. Turning the templates into a real model catalog, with version pinning and pre-pull, is planned; it is not live yet.
A running pod's hardware does not change on its own. A change happens in only two cases: if the provider cannot deliver the capacity at the moment of renting we move to the next offer, or if the machine loses its health check the job is moved to another host. Both are written to the event stream, and in both cases the time that did not work is not billed. For a moved job to continue where it left off you need to write checkpoints — that is not something we can invent on your behalf.
Get started
No commitment, no minimum duration. If you don't like it, stop it; payment stops that second.