Thunder Compute vs Aquanode
GPU cloud focused on a local-IDE developer workflow
Thunder Compute has the better local-editor story, full stop — a real VS Code, Cursor and Windsurf extension with a connect button, which we do not have. Aquanode's argument is not the editor: it is that a Thunder snapshot stays inside Thunder, while an Aquanode snapshot restores onto a different provider.
Where Thunder Compute wins
- A genuine local IDE integration — an installable VS Code / Cursor / Windsurf extension that connects you to a remote GPU from the editor. Aquanode has no editor extension. Our CLI writes a managed SSH alias and that is all; Remote-SSH working at all is a side effect of the alias existing, not a feature we built.
- Very low published rates on A100 and H100 PCIe capacity.
- A simpler product surface if a single-vendor GPU box is all you want.
Where Aquanode wins
- A snapshot taken on Aquanode restores onto a different provider. Thunder's snapshots stay inside Thunder — if their capacity or price moves against you, the environment does not follow you out.
- Your environment survives the box. Pause a deployment, come back tomorrow, resume with packages, model weights and config intact — instead of rebuilding from a fresh image every session.
- One account across every provider we broker, so you are not maintaining separate logins, keys and billing per vendor to chase capacity.
- Automated backups are on by default when you attach storage at deploy time, at a 6-hour interval — you do not have to remember to configure them.
Thunder Compute pricing vs Aquanode
Thunder Compute figures are Published on-demand rates, per GPU, read from their own pricing page on 2026-08-05. The Aquanode column is the lowest live per-GPU rate in our marketplace feed and moves on its own — the two columns are not measured the same way, so treat this as a starting point, not a quote.
Source: https://www.thundercompute.com/pricing — Published on-demand rates, per GPU. Verified 2026-08-05. Vendors change prices; check theirs before deciding.
What we do not claim
Restoring an environment requires a snapshot that already exists. Stopping a deployment yourself captures it on the way out, so you can bring it back later on any provider. A provider-side termination is different: it is only recoverable if you had already switched automated snapshots on for that deployment, and it costs you the work since the last one. Automated snapshots are opt-in — nothing runs until you start it — and with none running there is nothing to restore.
`aq deploy --snapshot <id>` rents the cheapest matching GPU and restores your snapshot onto it — including onto a different provider than the one it came from. Creating the snapshot is a separate step today: the standalone ogre CLI on the box writes it.
Thunder Compute vs Aquanode: common questions
Does Aquanode have a VS Code extension like Thunder Compute?
No. Thunder ships a real editor extension and we do not. Our CLI writes a managed SSH config entry so you can reach the box by an alias, which Remote-SSH can then use, but that is not an editor integration and we are not going to call it one.
What can Aquanode do with snapshots that Thunder cannot?
Restore one onto a different provider. `aq deploy --snapshot <id>` rents the cheapest matching GPU across the providers we broker and restores your snapshot onto it. Thunder's snapshots are scoped to Thunder's own fleet.
Can I create a snapshot from the Aquanode CLI?
Not yet. Today `aq` restores a snapshot; creating one is done with the standalone ogre CLI on the box, or from the console. Restoring across providers is the part that works today.
