§ Platform / Distributed compute
Pool your devices. Pool your lab. Pool the crowd.
One mechanism turns the devices you can reach into a working cohort: a job — a program plus a declared way to split it, a declared way to combine the results, and a rule for who may take part — is broken into pieces, a Pool of peers computes them, and a result counts only once it has been verified. The same mechanism spans your own machines, a consortium of signed institutions, and an open crowd of strangers — three levels of trust the platform never blends. Its coordinator is implemented and tested; pooled jobs across real browsers are in active bring-up.
One mechanism, from solo to swarm
Distributed compute here is not a family of subsystems; it is one thing. A Job is fixed and identified by its contents: a program, a declared rule for where the work splits, a declared rule for how the results combine, and a policy for who may take part. Every piece carries the exact inputs it was handed and its own reproducible slice of randomness, so any peer can recompute exactly the piece it was given — a piece that never comes back is simply re-issued, never lost.
One shape covers data-parallel training, parameter sweeps, ensembles, k-fold validation, Monte-Carlo simulation, and batch analysis. A pool of one device is an ordinary solo run, with no coordinator — pooling never weakens the offline core, and nothing you build ever depends on someone else showing up. Work that must cross devices in a fixed order — where one machine's output is the next machine's input — is deliberately a separate mechanism rather than being forced into this one.
Your devices, a consortium, or the open crowd — never blended
Every pool declares who may join, and the three answers are never collapsed into one vague trust slider. Your own devices — laptop, desktop, workstation — join as one cohort: full trust, no consent friction. A consortium is built from institutionally signed members; it is the only setting in which safety-critical or regulated work may run at all. An open crowd is anonymous strangers: pure compute, restricted to inputs that are already public, spot-checked by independent re-execution — choosing the checked pieces so no peer can predict them is still in bring-up — and capped by a budget you set.
Lending compute and co-editing are different acts, and the platform keeps them apart: a stranger can lend you a GPU while reading none of your data and writing none of your document — working on the same document together is live collaboration, a separate decision. The honesty runs the other way too: a peer that executes your work necessarily holds what it computes on, so a model or a dataset you mark confidential refuses the open crowd outright. The wider trust machinery lives on security.
Sweeps, simulations, and batch analysis are first-class
Idle laptops and workstations are meant to fuse into one cluster that runs any work you can cut into independent pieces — a parameter sweep, an ensemble, k-fold validation, a Monte-Carlo simulation, a batch analysis over a large dataset — with no training machinery involved at all: independent pieces, a plain declared way to combine them, no gradients anywhere. Whichever peer is free takes the next piece, so a slow peer, a peer that disappears, and a peer that fails are one recovered case rather than three separate patches.
Inputs are designed to spread between peers rather than fanning out one by one from a single source, so a large dataset does not become the bottleneck. Results are to be folded in only after they have passed verification — you cannot un-fold a bad sample from a running mean; today the coordinator flags an unconfirmed result rather than holding it back — and long simulations stream through accumulators of constant size instead of piling up millions of samples in memory. A sweep is meant to fill in piece by piece while it runs; the distributed-compute guide walks through the mechanism.
What pools well — and what honestly doesn't
Different work scales differently. The table says so out loud.
| Workload | Scales | The honest reason |
|---|---|---|
| Parameter sweeps & batch analysis | near-linear — expected, not yet measured | Independent pieces, no waiting; whoever is free takes the next one, so a straggler and a failure are the same recovered case. |
| Monte-Carlo & ensembles | near-linear — expected | Independent seeds; designed to fold into a constant-size accumulator only after verification. |
| Training that stays in step | sub-linear — tens of stable peers at best | Everyone waits for the slowest; it grows by syncing less often, never by deeper coordination — not yet wired across browsers. |
| Federated learning | by participants | Grows the cohort and the statistical power — never the wall-clock speed. |
| Models too big for one device | split the model itself | Copying the model to more devices adds throughput, not room; fitting it means splitting the model across them — the planner names how. |
No numeric speedup is promised anywhere on this page — the named mechanisms (sending smaller updates, overlapping computation with communication, giving faster devices bigger pieces) are the claim.
Near-linear speedup is the expected shape — and precisely scoped: it holds for work whose pieces never have to wait for each other, and it has not yet been measured across browsers. Training that stays in step is sub-linear, held by slow peers and by people closing their laptops to roughly tens of stable peers at best, and it grows by syncing less often rather than by deeper coordination — pooled training across browsers is not wired yet. Churn, not the mathematics, is the dominant cost of pooling.
Two more limits survive into every sentence on this page. Pooling multiplies throughput, not capacity: a model too large for one device is still too large for ten copies of it — fitting it means splitting the model itself across devices, and the planner names which. And a browser tab in the background is frozen, not computing: contribution is designed around a foregrounded, plugged-in device. We promise mechanisms, never multipliers — the rest lives in honest limits.
“Serverless” describes the data, never the coordination
A browser tab cannot accept an incoming connection, so a coordinator is in the loop for every join and every reconnect. Its role is stated precisely: never load-bearing for correctness, and never needed for solo work, which runs fully offline — but genuinely needed to keep a pool working over time. Coordination crosses a server; your tensors are not meant to: the design moves the bulk of the bytes device to device, directly on most home and mobile networks — a data plane still in active bring-up.
Behind a corporate firewall — the locked-down institutional setting — a direct connection usually fails and traffic falls back to a relay. For that setting the relay is the steady state, and we say so instead of rounding it up to “device to device” — the relay itself is not deployed yet. One rule holds at every scale: only peers ever combine a result — the coordinator sequences and elects, it never sums — and a large pool spreads its coordination out rather than funnelling everything through one point.
Federated learning is a setting, not a subsystem
Federated learning is the same job in a different setting: each participating site keeps its raw data, trains on its own hardware, and sends only model updates, which a declared strategy averages. The strategies are ordinary catalog content, not engine code: FedAvg, FedProx, SCAFFOLD, DiLoCo, and the FedAdam family for stable consortia; FedBuff and gossip for fleets of devices that come and go; Ditto, FedPer, and clustered federation for the common case where one global model is the wrong goal. Writing a new one is ordinary authoring.
The recipe lives in Model View beside every other training setting — the strategy, who takes part each round, and the (ε, δ) privacy target; the clipping bound and the noise level are not yet settable there — and a live privacy-budget meter sits in the round monitor. The engineering is concrete: the update format lets a federated language-model run exchange small adapters instead of full weights — roughly a thousand times less to send — and compressing those updates without losing what they carry is what will make ordinary home connections workable at all. A site's contribution does not yet run end to end, so no federated run has happened in the product.
The privacy claim is stated at two levels, because they differ. “Raw data never leaves the device” is true of the bytes, and the format the update is sent in enforces it: there is no field a raw sample could travel in. But an update is a function of the data — sometimes a reversible one — so the guarantee about the information holds only with a floor that is always on: every update that leaves a pool beyond your own devices is to be clipped and carry accounted privacy noise, charged against a budget that refuses to overspend, with secure aggregation layered on where the cohort allows it — required between institutions, and never a substitute for the noise. That floor is not yet in force: today it binds only where a recipe declares a privacy target, the charged ε is supplied rather than computed, the noise, now drawn from the browser's cryptographically secure generator, is not yet applied by any product path, and secure aggregation assumes an honest-but-curious server. Regulated cohorts run in a consortium, and nowhere else.
Counted by verified work — never by the clock
| Capability | Status | What it means |
|---|---|---|
| Volunteer pooling | in bring-up | Own devices, volunteers, consortia — every accepted piece produces a record; no money moves. |
| The contribution ledger | implemented | A chained, tamper-evident history — an entry is minted by verification, never by elapsed time. |
| Capacity offers | implemented | Advertise a machine's idle hardware and the hours it is free — and browse jobs looking for compute. |
| Paying for compute time | a named next step | Escrow, a forfeitable deposit, and a provider bond ship together as one unit — or not at all. |
| The Copilot and money | barred by construction | No assistant — ours or yours — can create a paid pool or move money; it is refused by the way the system is built, not by a setting. |
Paying for compute adds payment rails, never new mechanics — but the volunteer pool that will exercise this machinery is itself still in bring-up: its parts are implemented and tested, not yet run end to end across browsers.
Acceptance and counting are the same boundary. A result enters the ledger only after it has been verified — today by a second, independent peer returning the identical result for the same piece; checking against the reference within a declared tolerance and spot checks a peer cannot predict are still in bring-up — and every accepted unit produces a contribution record whose cost the planner derives from the work itself, never from what the contributor claims. Elapsed time is never counted: it can be faked, it pays for slowness, and it is blind to whether the answer was right. In an open crowd the guarantee this aims at is probabilistic, economic, and auditable — never cryptographic and absolute; today a caught mismatch is flagged, not yet corrected or penalised.
What is built today is the volunteer economy's machinery: pools of your own devices, of volunteers, and of consortia — contribution records, a contribution history, and capacity offers through which a machine advertises idle hardware and browses jobs looking for compute — in active bring-up, since no browser has yet worked through a pooled job end to end. That is the supply side of a market for compute time, which does not exist yet: paying for it is a named next step and ships as one indivisible unit — escrow, a deposit that can be forfeited, a provider bond — because paying out without deterring fraud would make cheating profitable. It is a different thing from the Marketplace, which sells packs, models, and datasets, and never sells compute. And one rule holds on every plan: computation on your own device is never counted at all.