Right now, as you read this, there is an astonishing amount of computing power doing nothing at all.
Think about the machines around you. A gaming PC with a graphics card more powerful than most people will ever fully use, idle while its owner sleeps. A 3D artist's workstation, flat-out for an hour during a render and then quiet for the rest of the day. A game console under the TV, a serious GPU spending most of its life on standby. An office floor with hundreds of capable machines that run nine hours a day and then sit dark all night and all weekend once everyone goes home. The laptop closed on the desk. Individually, none of it is remarkable. Added together, it is staggering — easily the equivalent of enormous data centers, scattered across millions of rooms, mostly switched on and mostly doing nothing.
We have built an entire industry around renting computing power from a handful of giant, centralized buildings. Meanwhile, a comparable amount of power already exists, already paid for, already plugged in — and it sits idle.
This is a piece about a simple question: what if all of that were a single ultracomputer — one that anyone could both feed and use?
Disclosure: I'm building a system in this space, so I'm not a neutral observer. This piece is about the idea, not a pitch — but you should know where I'm coming from before reading on.
The idea has a name: crowdcomputing. I define it like this — ordinary people's everyday devices connect through a coordinating service that turns scattered, mismatched machines all over the world into one heterogeneous cloud computer. It works like Kickstarter, but with computing instead of money: someone pitches a project that needs a lot of computing — rendering a short film, running a heavy simulation — and other people back it by pointing their own machines at it until it's done.
If you've come across BOINC — the software people have used for the last two decades to donate their computer's idle time to scientific research — this is something like that, pointed at ordinary use instead of science. Same basic bargain: spare cycles from machines that would otherwise sit idle, pooled into something far bigger than any one of them. What changes is who it's for.
Why now
None of this is a new idea. People have been pooling distributed machines for decades — grid computing in the 1990s, and volunteer computing soon after, which let the public donate spare cycles to science. "Lots of small machines standing in for one big one" is old and well-proven.
What's new is partly the machines, and partly us.
Start with the machines. The graphics card in an ordinary gaming PC today is a genuine parallel supercomputer by the standards of twenty years ago — and even fairly modest computers are now far more capable than their owners ever ask of them. There are hundreds of millions of these machines, the vast majority running well below their capacity for most of the day. And fast internet has reached the rooms they sit in: connections that once crawled now move real data as a matter of course.
Then there's us. Not long ago, letting your computer run code on behalf of strangers would have sounded reckless, and most people would have refused — with good reason. But the Overton window for what we'll allow on our own machines has shifted fast. We now install agents like OpenClaw and Codex and hand them the run of the place — reading our files, executing commands, doing more or less whatever they decide — because the payoff feels worth it. Set against an agent with that kind of reach, lending a slice of an idle GPU to a single, known job is a much smaller and much more contained thing to permit. With proper validation and real transparency about what runs, it stops being unthinkable and starts being ordinary.
Put those together — abundant idle power, networks fast enough to use it, and a real shift in what people will permit on their machines — and the wall that always stood in front of this idea starts to come down. The harder question isn't whether you can build it. It's what a computer like this is actually good for — and, just as much, where it isn't.
Where it fits — and where it doesn't
It's tempting to frame any new way of computing as a challenger to the cloud. This isn't one, and pretending otherwise would be the fastest way to be wrong about it.
The line that matters isn't how much power you have. It's the shape of the work. Some computations are a tight, chattering conversation between their parts: every piece needs constant, low-latency contact with every other piece, sharing state from one moment to the next. Training a large model, where thousands of processors stay in lockstep and exchange results on every step. A database serving live transactions. Anything interactive or real-time. That work belongs in a data center, next to fast interconnects and shared memory, and it always will. Spreading it across strangers' machines on ordinary internet would be absurd, and crowdcomputing has no business trying.
Crowdcomputing fits the opposite shape: work that breaks cleanly into independent pieces, each of which runs for a long time on its own before anyone needs the result. Render one frame of an animation. Run one variant of a simulation. The defining ratio is simple — the time it takes to send a piece of work is tiny next to the time it takes to compute it. A few seconds to ship a task that then runs for an hour. When that holds, it stops mattering that the machines are scattered across the world on home connections: the network is barely in use, because the machines are busy computing, not waiting on each other.
And here's the part I find more interesting than the rivalry framing. A great deal of what runs in data centers today isn't there because it needs the latency or the interconnect. It's there because there was nowhere else to put it. It takes up scarce, expensive capacity — expensive precisely because of the tightly-coupled work it was built for — and needs none of what makes it expensive. Move that loosely-coupled work onto a distributed network of idle machines, and you don't compete with the data center. You unclog it. You free the thing only it can do from the pile of things that never needed it. The two aren't rivals; they relieve each other.
What a computer like this computes
Everything that fits the shape from a moment ago — work that breaks into independent pieces, each running long enough that moving it around is free by comparison.
Rendering is the cleanest example, and probably the first place most people will see it work. A frame of animation is wholly self-contained: hand a machine the scene and a frame number and it can compute that frame with no knowledge of any other. A thousand frames is a thousand independent jobs. The same is true of simulation — run one model a thousand times with different seeds or parameters and explore the space — and of plain batch processing: convert, analyze, or transform a mountain of files where each file stands on its own.
Then there's the kind of work that has quietly become some of the most compute-hungry on earth, and almost none of it is the part people picture. Building the data that modern systems learn from: generating synthetic examples by the million, or rendering images to train on. Running a finished model across enormous inputs — millions of records, frames, or documents — one independent pass at a time. Scoring and checking a model's output at scale. Sweeping across thousands of configurations to find the one that works. All of it embarrassingly parallel, all of it a long compute for a small transfer — and all of it a natural fit for a computer made of idle machines.
It has to be easy — for everyone
A system like this only works if it's easy. The power is sitting there idle either way; whether it ever becomes one computer comes down to how little friction stands between people and using it. So the whole design goal is convenience, on every side.
It should be easy to contribute. You install something once, and your machine starts helping when it's idle — no configuration, no babysitting, nothing you need to understand about what's happening underneath. Lending your spare power should feel like flipping a switch.
It should be easy to get work done. When you need something computed, it should happen from inside the tools you already use — you ask for a result the way you always have, and it comes back. You shouldn't have to learn a new system, or even think about the fact that hundreds of machines were involved.
And it should be easy to build on. Anyone making software should be able to put their application's heavy work onto the network without standing up infrastructure of their own, and to extend what the network does simply by pointing new kinds of work at it. The more naturally it slots into the tools people already build and use, the more it stops being a destination you visit and becomes plumbing that quietly runs underneath everything.
Where this is already happening
None of this is hypothetical. The donate-your-cycles half has been proven for twenty years in volunteer computing; the newer part — ordinary people pointing their own machines at everyday work, through the tools they already use — is only starting to take shape now.
The system I'm building is OmnibusCloud. It lets people pool their machines into a shared computer and send work to it from inside the applications they already use, with rendering as the first kind of work it handles. You can try it today.
The bet
We've come to take it for granted that computing happens somewhere else — in a building you rent time in, owned and run by someone else. That model works and isn't going anywhere. But it trained us to think of computing power as something you fetch from a provider.
Crowdcomputing is a bet that it doesn't have to be. The power is already here — in the room you're sitting in, in the machines around you, far more of it than anyone is using. It has no single location and no one who owns the supply: it's assembled by the people who use it and used by the people who assemble it. The idle hour that would otherwise be wasted becomes someone's finished render, someone's answer.
An ultracomputer with no address, built from the machines we already have. That's the bet.