Per-rental API reference

Authentication

When you rent a GPU you instantly get an API key (gpurent_…), shown on your rental page. Send it as a Bearer token on every request:

Authorization: Bearer gpurent_your_key_here

The key works for exactly as long as your rental — when the time you paid for runs out, the key is deactivated automatically. The API allows cross-origin requests, so you can call it from browsers, servers, notebooks, anywhere.

Endpoints

Base URL: …/api/v1

Method	Path	What it does
GET	/me	Your rental: GPU model, VRAM, time remaining, agent status.
POST	/jobs	Submit a job. Body: {"command": "…", "timeout_s": 300} (timeout 5–3600s, optional). Returns the job with id.
GET	/jobs	List your jobs (without output).
GET	/jobs/:id	One job, including its full output so far. Poll this while status is queued/running.
DELETE	/jobs/:id	Cancel a queued or running job.
PUT	/files?path=…	Upload a file into the rental's workspace — the request body is the file's bytes.
PUT	/files?path=…&offset=N	A file of any size, in pieces of up to 16 MB (one upload carries about 36 MB): offset=0 starts the file, and each next piece starts at the size the last answer gave. A piece that does not start where the file ends gets 409 with the file's real size — carry on from there.
GET	/files?path=…	Download a file from the rental's workspace — one file (not a folder), up to 2 GB, streamed with its length. Move bigger files off the machine from a job, to your own storage.

Errors come back as JSON: {"error": "human readable message"} with an appropriate HTTP status. Rate limit: 120 requests/minute per rental.

Job lifecycle

• queued — accepted, waiting for the host’s RentGPUPower app to pick it up (usually < 3 seconds).
• running — executing on the host machine. output grows as the command prints.
• succeeded — exited with code 0.
• failed — non-zero exit, timeout, or the host's machine could not run it (see error).
• cancelled — you cancelled it.
• expired — the rental ended before the job ran.

Commands run with sh inside the rental's sandbox — a Linux container on the host's machine — starting in /workspace. (A listing marked ⚙ direct has its sandbox switched off: there they run straight on the host's machine.) Output (stdout+stderr) is capped at 512 KB per job.

Examples

curl

# submit
curl -X POST /api/v1/jobs \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"command": "nvidia-smi"}'

# poll (replace 42 with the job id you got back)
curl /api/v1/jobs/42 -H "Authorization: Bearer $KEY"

Python

import requests, time

API = "/api/v1"
H = {"Authorization": "Bearer " + KEY}

job = requests.post(f"{API}/jobs", json={"command": "python train.py"}, headers=H).json()["job"]
while job["status"] in ("queued", "running"):
    time.sleep(2)
    job = requests.get(f"{API}/jobs/{job['id']}", headers=H).json()["job"]
print(job["status"], job["output"])

JavaScript

const API = "/api/v1";
const H = { Authorization: "Bearer " + KEY, "Content-Type": "application/json" };

let { job } = await (await fetch(`${API}/jobs`, {
  method: "POST", headers: H, body: JSON.stringify({ command: "nvidia-smi" }),
})).json();

while (["queued", "running"].includes(job.status)) {
  await new Promise(r => setTimeout(r, 2000));
  ({ job } = await (await fetch(`${API}/jobs/${job.id}`, { headers: H })).json());
}
console.log(job.output);

Working on the GPU from your browser

Every rental opens in the browser — there is no SSH key to make, no port to forward, and nothing to install. The host's machine never opens an inbound port: your browser talks to RentGPUPower, and the host's agent pulls the traffic out over its own outbound connection.

• Terminal — a real interactive shell inside the rental's sandbox.
• Notebook / app — whatever your template starts (JupyterLab, an inference server), on the same link.
• Files — browse, upload and download the workspace, or pull a dataset straight from a URL.

Clusters: several machines, one private network

A cluster is several machines from one host, rented together in one step from its page (the marketplace lists them). Each machine is an ordinary rental — its own workspace, API key and per-second settlement — and /rental-group/<id> runs a command on all of them, adds time to all of them, or stops them together.

Where the cluster’s page says so, their workspaces share a private network: every machine is node1, node2, … in its cluster’s own 10.77.N.0/24, in /etc/hosts; each finds its own name in /etc/gpurent-node and the whole list in /etc/gpurent-cluster. It runs over WireGuard through RentGPUPower’s server, so it works whatever network each host sits on — right for coordinating work and moving moderate amounts of data (up to the allowance shown on the cluster’s page), not for datacenter-speed gradient exchange.

Each machine also knows its place in its shells: NODE_RANK (0 on node1), NUM_NODES, MASTER_ADDR (node1) and MASTER_PORT (29500) — the names PyTorch, Lightning and most launchers read — and NCCL and Gloo are pointed at the cluster’s link (NCCL_SOCKET_IFNAME=wg0). So one command, the same on every machine and run on all of them at once from the cluster’s page, starts a PyTorch job across them; put it in the background for anything longer than a few minutes.

# PyTorch across the machines — the same command on every machine
nohup torchrun --nnodes=$NUM_NODES --node-rank=$NODE_RANK \
  --master-addr=$MASTER_ADDR --master-port=$MASTER_PORT \
  --nproc-per-node=gpu train.py > train.log 2>&1 &

# Ray: on node1, then on every other machine
ray start --head --port=6379
ray start --address=node1:6379

AI models on devices

Some listings are not a machine but an AI model, served from a device on its host's own network — a Mac running Ollama or LM Studio, a PC whose graphics card only such an app can use, a games console running a model server. The marketplace shows them as 🧠 AI model, with the model's name, the speed its host's app measured and its context, and you rent them as the model: a chat on the rental page, and an OpenAI-compatible address for your own code.

• The address is on the rental page: its base URL, the model, and the rental's own key (gpurent_…) as the API key. Any OpenAI client or library works with them.
• Three calls, nothing else: GET /v1/models, POST /v1/chat/completions and POST /v1/completions, streaming included. Every other path is refused before it reaches the device, and such a rental has no terminal, files, jobs or SSH.
• Its model is fixed: whatever model a request names, the device's own answers, with one answer per call.
• Billing is that of any rental: per second, held in escrow, paid to the host only for the time the model really answers. A device that stops answering leaves the marketplace at once, and the time it did not deliver comes back to you.
• Privacy: what you send is processed on the host's device, by a model server its owner runs. Keep passwords, keys and private data out of it.

From the Compute API, with an account key (gpuapi_…): GET /api/v1/compute/models lists the models idle devices serve, and a POST /api/v1/compute/chat/completions naming one rents the cheapest idle device that serves it — half an hour reserved, paid per second from your credits — and answers that same call. Its X-RentGPUPower-Instance header names the instance: later calls use it, and DELETE /api/v1/compute/instances/ID stops it.

from openai import OpenAI

client = OpenAI(base_url="/api/v1/compute", api_key="gpuapi_…")
reply = client.chat.completions.create(
    model="qwen3.8-27b",
    messages=[{"role": "user", "content": "Hello!"}],
)
print(reply.choices[0].message.content)

For GPU hosts

Easiest way — the Launcher. Get the Launcher (one line to paste), log in with your RentGPUPower account, and it detects your GPU, creates your listing, and puts you online with one click. It runs renter jobs inside an isolated Docker sandbox by default so nobody can touch your machine. No tokens, no terminal.

Linux hosts: the sandbox in one command

On Linux the installer sets the sandbox up for you as its third step — Docker Engine (the free, open-source Docker, not Docker Desktop), the service switched on at boot, your user's permission to use it (the docker group), and the NVIDIA Container Toolkit when there is an NVIDIA card. sudo asks for your password once. If you ever need it again — a new user, a reinstalled Docker, the control panel saying the sandbox is what is missing — it is this one line (curl or wget, whichever the machine has), and it only does what is still missing:

(curl -fsSL /setup-docker.sh || wget -qO- /setup-docker.sh) | sh

Works on Debian, Ubuntu and the systems built on them (Linux Mint, Pop!_OS, Raspberry Pi OS), Fedora, RHEL and its clones (Rocky, Alma, Oracle Linux), Amazon Linux, SLES and openSUSE, Arch and Alpine. A machine that runs Podman instead (Fedora Silverblue, Bazzite, RHEL with podman-docker) is used as it is — RentGPUPower runs on Podman, and an NVIDIA card is handed to it through CDI. Docker from the Snap store and a rootless Docker are started the way they need; on NixOS it tells you the configuration line instead. A machine with no desktop session (a server on SSH) is shown the tunnel that reaches the control panel: ssh -L 4091:127.0.0.1:4091 you@that-machine, then open the link RentGPUPower printed there (http://localhost:4091/?k=… — the k is the panel's key, which keeps other accounts on that machine out; run RentGPUPower again to print it). AMD cards need nothing beyond Docker itself (ROCm hands containers the kernel driver's device nodes), and a machine with no GPU hosts as a CPU unit with nothing extra.

Windows and macOS hosts: Docker Desktop

On Windows and macOS the sandbox is Docker Desktop. If it is installed but not running — the usual state of a home PC — the Launcher starts it for you: press Go online and your GPU goes online by itself when Docker is ready, usually under a minute, with nothing else to click. If it is not installed, the control panel installs it for you: Install Docker for me downloads Docker Desktop from docker.com, checks it is signed by Docker, and installs it — Windows asks for your permission once (and may need one restart, after which RentGPUPower opens by itself and carries on); a Mac asks for its password once. The download and the one-line install (winget install -e --id Docker.DockerDesktop on Windows, brew install --cask docker on a Mac) work too. Once it is installed, Docker Desktop's own "start at login" setting keeps hosting-at-boot unattended.

A Mac, a machine with Intel graphics, or an AMD card ROCm cannot see cannot rent out its graphics yet — but the Launcher offers its processor as a CPU unit (Ollama and PyTorch on cores, priced by cores), through the same sandbox. Nothing is turned away that has something to sell.

Everything goes through the app. The agent that runs renter work is part of the RentGPUPower app: the app installs it, starts one per card, keeps it up to date and hands it your settings (the sandbox, keeping renters off your home network, whole-machine mode). It is not offered as a separate download.

The agent polls the marketplace over plain HTTPS — no inbound ports, works behind NAT and home routers. If it stops, your listing shows offline within 90 seconds and can't be rented. An active rental does not pause: the renter's clock keeps running, that time counts as undelivered so you are not paid for it, and after 30 minutes of continuous outage the rental auto-cancels and the renter is refunded the rest.

Machines with no GPU at all

A computer with no usable graphics card can still be rented — as what it is. The launcher (or the agent) detects the CPU as the compute unit, the listing self-labels ("… — CPU only") with the machine's RAM as its memory, and renters are offered only the environments that genuinely run on cores: PyTorch, TensorFlow and Ollama, with Ollama the default. GPU-only environments (like vLLM) are refused at checkout rather than sold and failed. Pricing comes from the core count and is honest about how slow CPU compute is — typically single-digit cents per hour.

AMD cards (ROCm)

AMD is supported, with three conditions that are checked rather than assumed:

• Linux. ROCm hands the container the kernel driver's device nodes (/dev/kfd, /dev/dri) and there is no equivalent on Windows or macOS.
• A working ROCm install — the agent checks for those device nodes and for rocm-smi at startup and tells the marketplace whether it found them. Until it does, the listing stays unrentable and says exactly what is missing. Having a ROCm image in our catalogue is not the same as your machine being able to run it.
• The environments built for it. An AMD host is offered the ROCm templates (PyTorch on AMD, Ollama on AMD) and is not offered the CUDA ones — those images do not exist for your card, and being offered them would only produce a rental that fails.

The Launcher lists AMD cards too — it asks rocm-smi the way it asks nvidia-smi, so on Linux with ROCm installed the card appears on the host tab and goes online with one click, sandbox and all. If rocm-smi is missing, the Launcher says so, and what to install. The one-line sandbox setup applies to AMD hosts too: Docker Engine and the docker group are what it needs, and it knows an AMD card needs no container runtime installed.

An AI model on any device

What the sandbox cannot rent out — a Mac's graphics, an AMD or Intel card on Windows, a games console — can still earn, as the model it runs. Start an app that serves an OpenAI-compatible API on that device (Ollama, LM Studio, llama.cpp's server, vLLM, PS5LM) with its model loaded. Then, in the RentGPUPower app, open AI devices on your network → Add an AI device: type its address (this computer, or another device on your network), its API key if it asks for one, and press Check it — the app reads the model, the server and its context, and measures its speed. Add and go online lists it.

• Your network stays closed. The app sends the device only the three model calls above, with its model pinned, and only to an address inside your own network: a public address is refused, and a name is looked up again before each use. Renters get no shell, no files and nothing else on the device, and nothing reaches your other devices.
• Keep it running. The app asks the device every few seconds. When it stops answering, or serves another model, the listing leaves the marketplace until it is back, and renters get back the time it did not deliver.
• Priced by what it does. The suggested price comes from the model's size and the speed the app measured — usually a few cents an hour; change it on the listing's page. While nobody rents it, it also earns from the Compute API, which rents it by its model.

Use your own device, and software you have the right to run on it.

Hardware verification

Every listing is checked against what the host’s app reports before it can be rented:

• When the host’s RentGPUPower app connects, it reports the GPU that nvidia-smi actually detects (model, VRAM, driver, GPU UUID).
• The marketplace compares that to the listed model. Names are normalized ("NVIDIA GeForce RTX 4090" = "RTX 4090") and VRAM must cover what the listing promises.
• ✔ verified — hardware matches; the listing is rentable.
• ✖ mismatch — the machine reports a different GPU (or none). Renting is blocked until the owner fixes the listing or moves the agent to the right machine. Re-checked on every reconnect.
• ◇ simulated — a pretend card, used to test the site, with no real hardware behind it. It can be rented only on a demo marketplace, never on a live one.

Escrow & automatic refunds

Payments are never handed straight to the host — they are held in escrow and released for service actually delivered:

• Every ~10 seconds the marketplace checks each active rental: agent heartbeat fresh? jobs being picked up? Time passes as delivered only when both are true.
• A host that stays "online" but ignores queued jobs for 2+ minutes is treated as not delivering (anti-blocking protection).
• At the end of the rental: host gets total × delivered% minus the platform fee; the renter is refunded the rest automatically, onto their RentGPUPower balance. A rental paid from the balance puts the money back exactly as it was. What a card, PayPal or crypto payment paid comes back as credit: it pays for any rental but cannot be withdrawn — only money earned by doing work here cashes out (hosting, or a phone's tasks for API customers where they are offered), from Dashboard → Earnings. A paid rental that never starts is different: a card payment goes back to the card, in full.
• If the host is unreachable for 2+ minutes, the renter can end the rental early and recover all undelivered time. After 30 minutes of continuous outage it auto-cancels.
• So: a host who never delivers earns $0.00, and "renting" a GPU you don't intend to provide pays nothing — there is no scam payout to collect.

Reputation: reviews & reliability

Every host carries a public track record so renters can choose with confidence:

• Reviews — after a rental starts, the renter can leave a 1–5★ rating and a comment (one per rental). Ratings show on listing cards, the listing page, and your dashboard.
• Reliability — automatically computed from the escrow uptime accounting, and measured rather than self-reported. Across a host's completed rentals it averages the % delivered — but what it is measured against depends on why the rental ended. If the host went dark (or the renter stopped because the host wasn't delivering — a call we make from our own signals, not the renter's word), it is measured against the whole booking, so a machine that fails after two minutes of a two-hour rental scores near zero rather than hiding behind those two minutes. If the renter simply finished early, or the rental idled out, it is measured against the time actually held — a host is never penalised for someone else's decision to leave. Rentals under a minute, and Compute API rentals, are excluded so short bursts can't swamp the signal.
• Trust score — a blend of reliability (60%) and rating (40%) used for the marketplace's Most trusted sort. Hosts with no history sit in the middle, not the top.
• Favorites — save any listing with the ♥ and find it again under Dashboard → Saved, or filter the market to “Saved only”.
• Extend — add hours to an active rental from its page; the extra time is escrowed and metered exactly like the original, and your API key keeps working uninterrupted.

Security model

• Renters execute arbitrary shell commands on host machines — that is the product, the same model as any cloud GPU provider. The RentGPUPower app runs each rental inside a Docker container by default, which keeps renter code off the host's own files; a host can switch that off on a dedicated machine, and its listing then says ⚙ direct.
• The “🔒 sandboxed” badge is reported by the host, not verified by us. A listing shows it when that host’s agent says it runs jobs in a Docker container with GPU passthrough. We cannot currently prove that from the outside — a host running a modified agent could claim it and still see what you run. Treat any machine you rent as untrusted with secrets: don’t paste long-lived API keys or credentials you can’t rotate, and prefer short-lived tokens. (Attestation is on the roadmap; we would rather label this honestly than imply a guarantee we can’t make.)
• For hosts: the sandbox is bounded. A renter's container gets a memory ceiling with no swap, a CPU ceiling that leaves your machine a core, a process limit, and a floor of free disk it cannot write below — what it runs is stopped first. Files a renter downloads are read inside the container, so a link planted in /workspace can never reach a file on your computer.
• API keys and host tokens are random 192-bit secrets. Rotate a host token any time from the manage page.
• Apps running on a rented GPU are treated as untrusted. They reach your browser through the relay, never directly, and each one has its own private link, which opens only for the account that rented the GPU. Where an operator has configured a separate app domain they are served from their own origin, so their JavaScript has no access to your RentGPUPower session; where they are not, they run under a sandbox CSP that has the same effect. Either way a host cannot set or read your RentGPUPower session cookie: on the marketplace origin the relay strips Set-Cookie and the app's own security headers outright, and on a separate app domain the app may set cookies and its own CSP for its own hostname only — the Domain= attribute is removed, so nothing it sets can reach RentGPUPower.
• Writes from other sites are refused. Any request that changes something and is authenticated by your login cookie must come from RentGPUPower's own pages; a cross-site request is rejected outright rather than silently acted on.
• No third-party JavaScript. Every script this site runs is served from this domain — nothing is pulled from a public CDN. A script loaded from someone else's server runs with your full signed-in authority, and on the payment page it would be the code deciding where your money goes. Each library we ship is pinned to a hash published by npm and re-verified before every deploy. The one exception is Stripe.js, which must come from js.stripe.com so your card details stay inside Stripe's own frame and never touch this server. Web fonts are self-hosted too, so no visit to any page is reported to a third party.
• Hourly prices are locked at rental time; hosts changing prices never affects a paid rental.
• Listings are hardware-verified (see above) and payments escrowed against delivered uptime — fake or no-show listings earn nothing and refund automatically.
• In demo payment mode no real money moves. With Stripe configured, card data goes only to Stripe — never to this server.