Climate ensemble forecasts
A weather lab runs 4,000-member regional precipitation ensembles overnight, distributed across volunteer browsers in the same time zone as the model domain.
Billions of capable GPUs are sitting idle in phones, laptops, and desktops while another data center gets built somewhere. Warppool runs your embarrassingly parallel workloads — Monte Carlo, ML inference, parameter sweeps, rendering — across those instead. Runs in any tab. No new silicon, no new substation, no new cooling tower. Stop the madness.
Researchers run free. Everyone else pays only for the milliseconds their job actually consumed.
Global data centers consumed roughly 415 TWh in 2024 — about 1.5% of all electricity — and the forecast is to double by 2030. Every marginal AI workload arrives as more substations, more cooling water, more concrete poured somewhere with cheap land.
Meanwhile, the device you're reading this on has a GPU that's idle most of the day. So does almost every device on the network. The math capacity is already paid for, manufactured, and shipped — it just isn't being used.
Move the compute to the silicon, instead of building more silicon. Browsers are the only thing we need.
Every dot is a browser tab somewhere with a discrete or integrated GPU, lent for a few seconds at a time.
You either ship work into the pool, or you lend cycles to the pool. Same protocol, opposite ends.
Wrap your problem as a WGSL shader (or pick one from the kernel library), describe how to chunk it, and submit. The scheduler farms the chunks out, verifies them by redundancy, and hands you the aggregated result.
Each chunk needs to run independently and finish in a few seconds on a mid-range GPU. Monte Carlo seeds, image tiles, batched inputs all qualify.
WGSL source for the compute kernel, plus a JSON manifest describing chunk count, parameters, and the reducer (sum, concat, max, custom).
Capability profile (memory, workgroup size, throughput score) and latency to the coordinator determine who gets what. Bigger GPUs get fatter chunks.
Results are compared within a numeric tolerance. Disagreement triggers a third opinion. Lying nodes get quietly downranked.
You get back the aggregate, the per-chunk receipts, and an audit trail of which workers ran what.
Drop a script tag on your site. Visitors who opt in run a worker inside a hidden iframe sandbox while they read your content. You get credit; they get a site without ad networks tracking them.
One <script> line. The visitor sees a small, unobtrusive consent strip explaining what it does before any compute begins.
If they say no, the tag does nothing. If they say yes, a Web Worker thread attaches to the coordinator and waits for chunks.
Each chunk is bounded — fixed memory ceiling, fixed wall-clock, throttled when the page goes to a background tab.
Per worker-second, scaled by the worker's benchmark score. Credit either pays out to your site, or funds research-pool jobs in your name.
No persistent state. Closing the tab releases the GPU instantly. The coordinator reassigns any in-flight chunk to another worker.
Shipping a chunk across consumer connections costs real time. The job pays for itself only if computing the chunk takes meaningfully longer than transferring the bytes that describe it. Rule of thumb: high FLOPs-per-byte, embarrassingly parallel, tolerant of stragglers.
A weather lab runs 4,000-member regional precipitation ensembles overnight, distributed across volunteer browsers in the same time zone as the model domain.
A classroom batches 220k video frames through Apple's open FastVLM model for captioning research. Each chunk is one frame; chunks stream to whichever idle WebGPU device picks them up first.
A studio renders 8k stills as 64×64 tiles. The coordinator stitches them back as chunks return. Coffee-break renders, not real-time.
An ML team sweeps 20k learning-rate × batch-size combinations on a small classifier. Each chunk is one config × 5 seeds. The coordinator returns the best 50.
Replica-exchange MD simulations split into independent temperature ladders. Volunteers run 200 ps slices and ship back trajectory deltas.
A graph-theory grad student enumerates 4-regular graphs up to N=22 isomorphism. Each chunk owns a slice of canonical labelings; the union is returned.
Submitters can't trust volunteer machines; volunteers can't trust submitter kernels. The protocol is built so neither side has to.
Every chunk goes to 2–3 independent workers. Results are compared within numeric tolerance. Disagreement triggers re-runs on disjoint nodes; persistent disagreement quarantines the kernel for human review.
A fraction of dispatched chunks have known answers seeded by the coordinator. Workers don't know which. Returning the wrong answer to a canary downranks the worker silently.
Workers run WGSL inside the browser's WebGPU sandbox. No filesystem access, no native APIs, no persistent state across reloads. Bounded memory per chunk. Visitor closes the tab — the worker is gone.
Every dispatch and result for your job is appended to a log keyed by worker ID and chunk hash. You can replay it, verify the reduction, and check that no worker's output was silently dropped. The submitter chooses whether to publish the log or keep it private.
Volunteer compute is not zero-trust compute. We protect submitters from lying workers via redundancy, and volunteers from malicious kernels via the WebGPU sandbox — but kernels you submit are visible to the workers that run them. Don't put secrets in your shader source.
The coordinator is a small FastAPI service. Workers are browser tabs. The messages between them are JSON. The actual math is WGSL on each visitor's GPU.
No — and we built the network specifically to be the opposite. Cryptominers run inside ads, without consent, and benefit the site operator at the visitor's expense. Warppool requires explicit per-session opt-in, surfaces what's running, throttles to background-tab limits, and pays the credit to whoever the visitor authorized. The first thing on every roadmap is making fraud easy to spot.
Researchers with verifiable institutional affiliation (university, public lab, school) run free — no cap, just don't be silly with it. Everyone else is billed per millisecond of completed compute: you pay only for chunks that returned a verified result. Failed chunks, timeouts, canary chunks, and redundant re-runs cost nothing. Indicative rate is around $0.04 per GPU-hour. Embed the worker tag on your own site and you earn credits back at the same rate.
A mid-range integrated GPU (M-series, recent Intel) returns ~1.5 GFLOPS-equivalent on the Monte Carlo benchmark you see in the hero. A discrete RTX-class card returns 30–80×. Calibration runs on join, so the scheduler always knows roughly how big a chunk a given worker can swallow in ~2 seconds.
Every chunk has a wall-clock deadline. If the result doesn't come back, the scheduler reassigns the chunk to another worker. Most reassignments happen within 200ms — well before a human would notice. The original worker simply doesn't get credit for that chunk.
No. WebGPU runs in the browser's sandbox. The kernel has access only to the buffers the worker explicitly binds, which contain only the chunk parameters you sent. It can't read disk, can't open network connections, can't query the GPU's host-side memory.
WGSL, the standard WebGPU shading language. Numpy/Torch-style kernels need to be ported; there's a library of common compute primitives (matmul, reduce, scan, sort, FFT) you can import. We're working on a Python → WGSL transpiler for simple element-wise kernels.
Warppool runs the production coordinator — a small FastAPI service that sits between submitters and workers. It's the only piece of the network that needs a server. Enterprise customers with sensitive workloads can run on a private coordinator (a dedicated deployment on isolated infrastructure); same protocol, same kernel library.
Walk through the submit flow, see the kernel format. Researchers: apply for a free grant. Everyone else: pay per millisecond of completed compute.
Submitter docsEmbed the worker tag. Visitors opt in. You get the credit; they get a site without trackers.
Site-owner guide