Three laptops, one Monte-Carlo

The number you actually care about comes out of a pipeline you have been refining for weeks: seven measured inputs, each carrying an honest uncertainty, pushed through a chain of nonlinear transforms into one dimensionless ratio. The point estimate is easy. The error bar is not. First-order propagation — linearize everything, add the variances — assumes the pipeline is roughly straight across the spread of the inputs, and this one visibly is not: the third transform folds an input through a saturating curve, and saturation is where linearization goes to die. So you do what you do when the algebra stops deserving trust: sample the inputs from their distributions, run the pipeline on every draw, and let the output distribution speak for itself. Monte-Carlo. The only problem with Monte-Carlo is the problem it has always had — N.

You also own three laptops. That, it turns out, is the whole story.

The arithmetic that sends you looking for more machines#

The estimator is nothing exotic — a sample mean. Draw x₁ … x_N, evaluate the pipeline g on each draw, average. Its variance is Var(ĝ_N) = σ²/N, with σ² the variance of a single evaluation, so the standard error falls like σ/√N. That square root is merciless in both directions: quadruple the samples and the error only halves; ask for one more stable decimal digit and the bill is a factor of a hundred.

Say a pilot shard of 65,536 draws puts σ at about 0.31, and you want the interval stable into the fourth decimal — a standard error near 5·10⁻⁵. The arithmetic converts that into N ≥ (0.31 / 5·10⁻⁵)² ≈ 38 million evaluations. Round up to 640 shards of 65,536 samples each: 41,943,040 draws. Extrapolate the pilot rate and it is a long stretch of your fastest machine's undivided attention, fan included.

But notice what the math does not require. The draws are independent by construction; the mean does not care which machine evaluated which sample, as long as the random streams never overlap and the fold at the end is done correctly. Monte-Carlo is not merely parallelizable — it is embarrassingly parallel, the textbook good case, the one that distributed-compute brochures quietly generalize from. This is the good case. And there are two more laptops in the house.

One job, 640 shards, zero coupling#

Pooled work on Scellis is one mechanism: a content-addressed job is partitioned into shards, executed by a pool of devices, folded by a declared reduction, and spot-checked by independent re-execution before any receipt is minted. The sampler is already an ordinary workflow; making it poolable means declaring how it partitions. Partition by_seed: every shard shares the root seed and owns a disjoint counter range of the counter-based RNG, so shard 317 draws exactly its own 65,536 samples — the same ones on any machine, on any day — and no two shards can ever draw the same point. Per-shard reproducibility falls out of the partition itself, and between samples there is nothing to coordinate.

Shards return accumulators, not samples. Each one folds its evaluations into a constant-size state — count, mean, second central moment, and 256 histogram-bin counts over a range frozen from the pilot — a few hundred bytes in place of a megabyte-sized sample dump. The declared reduction merges two such states:

// merge two shard accumulators — associative, commutative
function merge(a, b) {
  const n = a.n + b.n;
  const d = b.mean - a.mean;
  return {
    n,
    mean: a.mean + d * (b.n / n),
    m2: a.m2 + b.m2 + (d * d * a.n * b.n) / n,
    bins: a.bins.map((c, i) => c + b.bins[i]),
  };
}

The best detail in the whole design: the platform is not meant to take your word for that algebra. A declared reducer's associativity and commutativity are to be property-tested before a pool may use it — random states, swapped orders, different tree shapes — because a combiner that quietly is not associative would tree-reduce into confidently wrong numbers, and nobody would ever see the seam. That check is still being built; until it lands, every reduction is a seeded builtin that must declare its algebra, and a user-authored one is not yet accepted.

Three laptops, one queue#

The pool here is the least dramatic kind Scellis has: your own devices. The everyday laptop, the old one that lives on the windowsill, and the heavy one from the desk — all signed into the same account, which is what the own-devices regime honestly requires. Setup is minutes: each machine asks once for its own compute consent, with a budget governor and a battery floor underneath. The windowsill laptop joins the moment it is plugged in — exactly the behavior you want from a battery floor.

Distribution is a pull, never an assignment. A device leases a shard from the queue, computes, returns the accumulator, leases the next. Nobody models who deserves how much work: the fast machine simply comes back sooner and ends up with more, and the slow one nibbles its honest share. And one thing this is not, even among three laptops that all belong to you: serverless. The data plane is designed to be peer-to-peer — on a LAN the three would talk to each other directly, a path still in bring-up — but a coordinator session stays in the loop for membership and leases for the whole run. A solo run needs no server at all; a pooled run needs one for the control plane, and Scellis says that sentence out loud instead of mumbling it.

The windowsill laptop goes to sleep#

Now break it on purpose. Let the windowsill laptop fall asleep mid-run — nobody propped that lid open, and the operating system always wins that argument. The platform does not pretend otherwise; what it does is survive it. The shard board shows a small cluster of leases going stale. An expired lease simply re-enters the queue, and the other two machines steal the orphaned work without being asked. Work-stealing, straggler recovery, and crash recovery are the same mechanism here — a lapsed lease is a lapsed lease, whether the cause is a slow shard, a killed tab, or a lid that should have been propped open.

Wake the machine and it rejoins, leasing again as if nothing had happened — from the queue's point of view, nothing had. The cost of the nap is the work that machine would have done while asleep, plus the shards it was holding — redone elsewhere from their own seeds — and not one draw more.

Fold only what has been verified#

In the design, accepted results are the only results: a shard folds into the total after verification — and the pipeline does not special-case your own hardware. It is the same acceptance path every trust regime gets: a deterministic slice of shards is re-executed as spot checks. Among your own devices that check is meant to guard against flakiness rather than fraud, but today it cannot vouch there at all: a receipt is minted only when an independent account's re-execution agrees, and three laptops under one account count as one principal. A disagreement is caught and flagged, not yet corrected — the disputed value stays in the output, marked unverified — and the coordinator still compares results by content hash, which suits exact results only. The design is tolerance, not equality — three different GPUs do not produce bit-identical floats, and Scellis never claims they do. On the GPU path, “agree” is to mean “within the declared tolerance class”; the engine's tolerance verifiers exist, but the coordinator does not use them yet. The full acceptance story — leases, verification, regimes — is in the guide.

When the fold closes, what comes out is the thing the cheap error bar was hiding: a distribution with a visible shape. A linearized standard deviation that undershoots the sampled one, a symmetric interval that misses a heavy right tail, a mean that sits above the plug-in value. The nonlinearity was the point, and now you can see it rather than assume it away. Commit the run and the program, the partition, the root seed and the engine version are pinned behind one URL, with any single shard replayable alone from its seed and counter range. There are earlier chapters of most computational lives in which one would have paid real money for that sentence.

The honest scaling note#

Now the caveat that makes the rest worth believing. This scales because the work splits into independent pieces: zero coupling between draws, an associative fold, a few hundred bytes of traffic per shard. For work shaped like this — parameter sweeps, ensembles, k-fold validation, batch analysis, Monte-Carlo — the arithmetic lets a lease queue scale close to linearly, and to far more than three peers, though today's coordinator still caps one job at roughly a thousand verified shards. But be precise about what three laptops can buy: the ceiling is the sum of what the three deliver, and against your fastest machine alone that is something like 2×, not 3×, because the machines are unequal. The linearity lives in delivered capability, not in the count of lids.

And synchronized training is not like this. Gradient steps couple every peer at every step, stragglers gate the barrier, and that path — not yet wired across browsers — is bounded at tens of stable peers, not thousands, extended by relaxing synchrony, never by wishing. Federated learning scales in participants and statistical power, not wall-clock. Scellis prints these limits on the box, which is exactly why the label on the favorable case is worth trusting: when the estimator is a mean of independent draws, σ/√N is the law, the law parallelizes perfectly — and three laptops really can be one Monte-Carlo. Every draw replayable and the whole afternoon citable by URL, by design; “every shard verified” is the part still being built.