DEV Community: Viswaretas Kotra

GPU cloud pricing, October 2026: what an H100, H200, B200 or B300 costs per hour

Viswaretas Kotra — Fri, 09 Oct 2026 02:08:27 +0000

Short answer (Oct 8, 2026): on Nodus, an H100 SXM 80 GB is $2.60/hr, H200 SXM $3.59/hr, B200 $5.50/hr and B300 $6.94/hr on demand. Consumer and prosumer cards go much lower: an RTX 4090 is $0.29/hr and an RTX 3090 is $0.18/hr. Modal's listed rates for the same data center GPUs run from 2% higher (B300) to about 2.5x higher (L40S) depending on the card.

Prices below are per GPU-hour, USD, taken from the public Nodus pricing page on October 8, 2026, which lists Modal's published rate beside each one.

Data center GPUs

GPU	VRAM	Nodus	Modal
B300	288 GB	$6.943	$7.099
B200	180 GB	$5.500	$6.250
H200 SXM	141 GB	$3.593	$4.540
H100 SXM	80 GB	$2.600	$3.949
A100	80 GB	$1.090	$2.498
A100	40 GB	$0.904	$2.099
RTX PRO 6000	96 GB	$1.350	$3.031
L40S	48 GB	$0.793	$1.951
L4	24 GB	$0.430	$0.799

Budget and prosumer GPUs

GPU	VRAM	Nodus
RTX 5090	32 GB	$0.480
RTX 4090	24 GB	$0.290
RTX 3090	24 GB	$0.180
RTX 6000 Ada	48 GB	$0.743
RTX A6000	48 GB	$0.333
RTX A4000	16 GB	$0.173

Which one should you rent?

Fine-tuning a 7B to 14B model with LoRA: a 48 GB card (L40S, A6000) or a 24 GB card with QLoRA. A100 80 GB if you want full fine-tunes of small models.
Full fine-tunes and pretraining at scale: H100 or H200. H200's 141 GB helps with long context and larger batch sizes.
Serving frontier-size open models: B200 or B300. B300's 288 GB per GPU means fewer GPUs per replica, which often lowers cost per token even though the hourly rate is higher.
Experiments, evals and small jobs: RTX 4090 / 5090 at under $0.50/hr are hard to beat.

What the hourly rate does not tell you

Boot and teardown. Some platforms bill from machine creation to deletion. On Nodus the bill is split into Boot, Running and Teardown segments so you can see it.
Price changes mid-run. Nodus freezes the rate when the machine is chosen for the whole run.
Interruptions. Spot capacity is cheaper, but only if your job checkpoints. Otherwise one preemption can wipe out the savings. See our preemption guide.
Reserved terms. For multi-month commitments on B200/B300, reserved pricing is quoted separately and depends on term length, location and interconnect. Nodus handles these through Reserved Compute.

FAQ

What is the cheapest H100 per hour in October 2026? On Nodus, $2.60/hr for an H100 SXM 80 GB, on demand.

How much does a B300 cost per hour? $6.94/hr on demand on Nodus as of Oct 8, 2026. Reserved terms are quoted per request.

Is there a free tier? New Nodus accounts get a $30 starter grant valid for 30 days.

We refresh this table monthly. Live prices: nodus-compute.ai/pricing

How to give Claude Code, Codex or Cursor access to GPUs (MCP setup)

Viswaretas Kotra — Fri, 09 Oct 2026 02:00:11 +0000

Short answer: connect your coding agent to a GPU platform's MCP server. The agent can then estimate, launch, watch and fetch results from GPU jobs from the same chat where it wrote the code. With Nodus that is one command per client, and every paid action shows a dry run and cost estimate before it runs.

Coding agents are great at writing a training script and terrible at the part after: finding a GPU, shipping code to it, watching logs, copying results back. MCP closes that loop.

Claude Code

claude mcp add --scope user --transport http nodus https://api-next.nodus-compute.ai/mcp

Then run /mcp, pick nodus, and sign in in your browser.

Codex

codex mcp add nodus --url https://api-next.nodus-compute.ai/mcp
codex mcp login nodus

Cursor

Add this to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "nodus": { "type": "http", "url": "https://api-next.nodus-compute.ai/mcp" }
  }
}

Any other MCP client

Add a remote HTTP MCP server with URL https://api-next.nodus-compute.ai/mcp and follow the sign-in prompt. Prefer a local server? Install the CLI and run nodus mcp install, which configures the agents on your machine.

Verify without spending money

Ask the agent: "List my Nodus jobs." That is read only. A good first prompt for any agent that can read URLs:

Read https://nodus-compute.ai/connect.md and help me connect Nodus to this agent.
Verify setup by listing my jobs. Do not start paid compute.

What the agent can actually do

The server exposes generic tools over every resource: get, describe, logs, estimate, apply, exec and more. In practice that means prompts like:

"Run train.py on a 24 GB GPU with a $5 cap and stream the logs."
"Why did job/train fail?"
"Fine-tune Qwen3 0.6B with LoRA on chats.jsonl and download the adapter."
"What did my sandboxes cost this week?"

Guardrails that matter when an agent holds your credit card

Writes are dry-run first. The agent sees the object as it would be created plus the cost estimate, and it only runs once confirmed.
Same limits as you. The agent uses your account, projects, budgets and spending caps. A project budget stops it from overspending even if it gets creative.
Hard caps per job. maxCostUSD stops a job gracefully, with a checkpoint, before it passes the cap.
Frozen rates. The hourly rate is fixed when the machine is chosen and holds for the whole run.

FAQ

Do I need a separate "agents" product to use Claude Code with GPUs? No. MCP is enough. Nodus Agents is a different feature for running agent conversations inside Nodus.

Which GPU does the agent get? By default the cheapest offering that fits the request and can start now, within your limits. You can ask for a specific type like H100 or B200.

What does it cost to try? New accounts get a $30 starter grant, no card needed for the first runs.

Setup for every client: nodus-compute.ai/connect

How to make GPU training survive spot preemption (without babysitting it)

Viswaretas Kotra — Fri, 09 Oct 2026 01:59:34 +0000

Short answer: save your model, optimizer and step counter to one directory, write those files atomically, load them on startup, and run on a platform that copies that directory before the machine disappears and restores it on the next machine. Do that and a preemption costs you minutes of work, not the whole run.

Spot and interruptible GPUs are often a fraction of on-demand prices. The catch is that the provider can take the machine back. Here is the pattern we use at Nodus, and it works anywhere.

1. Put all recovery state in one directory

Everything you need to continue goes in one place: weights, optimizer state, LR scheduler, RNG state, data loader position, current step. Results you want to download (final model, eval reports) go somewhere else. Mixing the two makes checkpoints big and slow.

On Nodus that directory is /nodus/state (also in $NODUS_STATE_DIR), and outputs go to /nodus/outputs.

2. Write atomically

A checkpoint taken while you are halfway through writing a file restores a broken state. Write to a temp file, then rename it over the old one. Rename is atomic on POSIX filesystems.

import json, os
from pathlib import Path

STATE_DIR = Path(os.environ.get("NODUS_STATE_DIR", "/nodus/state"))
STATE = STATE_DIR / "progress.json"

def save(step, model, opt):
    STATE_DIR.mkdir(parents=True, exist_ok=True)
    tmp = STATE_DIR / "ckpt.pt.tmp"
    torch.save({"model": model.state_dict(), "opt": opt.state_dict(), "step": step}, tmp)
    os.replace(tmp, STATE_DIR / "ckpt.pt")

3. Resume on startup

Checkpoints restore files, not process memory. Your program starts from the top, so it has to check for saved state:

start = 0
ckpt = STATE_DIR / "ckpt.pt"
if ckpt.exists():
    s = torch.load(ckpt)
    model.load_state_dict(s["model"]); opt.load_state_dict(s["opt"]); start = s["step"]
    print(f"resumed from step {start}")
for step in range(start + 1, total_steps + 1):
    ...

4. Pick a checkpoint cadence

Too often and you waste GPU time writing files. Too rarely and each preemption throws away a lot of work. A practical rule: aim for at least four checkpoints per expected run, and keep checkpointing under about 10% of runtime. Capacity that is rarely interrupted can be checkpointed less often.

Nodus does this math for you with interval: auto, using how often that capacity actually gets interrupted and how long your saves take.

5. Save when the machine is about to go away

Most providers give a short reclaim notice. Use it. On Nodus your program can subscribe to checkpoint requests over a local socket and acknowledge when files are consistent:

import nodus  # pip install nodus-compute; no-ops outside Nodus

nodus.checkpoint.on_request(lambda: save(step, model, opt))

When the capacity gives notice, Nodus sends an urgent request, takes the checkpoint after your ack, and prepares a replacement machine at the same time. The replacement only starts once the old one is provably gone, so two machines never write the same state.

6. Hugging Face Trainer users

Trainer already saves and resumes. Point output_dir at the state directory, set save_steps and save_total_limit=2, and call trainer.train(resume_from_checkpoint=True) when NODUS_RESTORED=1. Or set integration: HFTrainer and Nodus registers the save-on-request callback for you.

Running it

pip install nodus-compute
nodus login
nodus run --gpu H100 --interruptible --checkpoint /nodus/state -d -- python train.py

nodus describe job/<name> shows each attempt, why it ended (for example Preempted) and the latest checkpoint. New accounts get a $30 starter grant, so you can test a preemption-safe run without a card.

FAQ

Does checkpointing restore GPU memory? No. It restores files. Your code reloads its own state.

What if a checkpoint is empty? An empty state directory never replaces an earlier useful checkpoint, so a crash before the first save cannot erase progress.

How many times will it retry? By default up to 8 recoveries (3 for distributed jobs). Two attempts in a row with no progress stops the run with NoProgress.

Does this work for multi-node? Yes, in beta. Each rank writes its shard with torch.distributed.checkpoint and rank 0 commits it.

Full guide: nodus-compute.ai/docs/guides/checkpoints