What OmnibusCloud is
OmnibusCloud is a crowdcomputing platform. Ordinary, mismatched machines — a gaming PC, a workstation, a laptop on a different operating system entirely — connect through one coordinating service that makes them behave as a single computer. You contribute a machine when it's idle, and you put work on the network from inside the tools you already use.
The first model is public and simple: it works like Kickstarter, but with computing instead of money. Someone pitches a project that needs a lot of computing — rendering a short film, finishing a heavy 3D scene — and other people back it by pointing their own machines at it until it's done.
The world doesn't lack computers. It lacks a trustworthy way to coordinate them. That coordination layer is what OmnibusCloud is building, and rendering is where it starts — a clear, measurable workload with a community that already feels the cost of compute.
Two ways to take part
Everything starts on the portal.
Contribute with your machine
If you have a desktop, laptop or workstation, you can help projects by letting it work when it's idle. Install the OmnibusCloud client once — it connects your machine to the network, and nothing runs without your say-so. Join a project you care about, choose exactly which machines contribute, and set your terms. Your machine works only when it's free, within the rules you set, and you can pause it anytime. When it's eligible, OmnibusCloud assigns work that fits its capabilities — heavier tasks to a strong GPU, lighter ones to a smaller machine — and reassigns automatically if it goes offline. You don't manage any of it.
Put work on the network
There are two ways to get help:
- Public projects. Put a project up for the whole community — a short film, a heavy shot. Give it a story, a goal and visuals, publish it, and people who like it point their machines at it until it renders. This is crowdcomputing in the open: the more your work pulls people in, the more help it gets.
- Private groups. Make a closed group with people you already know — your studio, your class, a few friends with capable machines. Pool everyone's computers and render each other's work without publishing anything, on machines that belong to people you trust.
Participation is per machine, not per user — your gaming PC on one project, your workstation in a private group, your laptop left out entirely. It's your call, machine by machine.
Built for heterogeneous hardware
Real machines aren't identical, and OmnibusCloud treats that diversity as the design, not an exception. Every machine is benchmarked, and work is matched to what each one can actually do — then allocated proportionally, so a strong GPU and a modest laptop both contribute and finish at roughly the same time, neither holding the other back. Work only reaches machines that meet a job's requirements, and only while a machine is idle and within its owner's rules.
The beta runs on desktop-class machines — Windows, Linux and macOS (Apple Silicon). Not every machine fits every job: a project may require a certain OS, GPU or amount of memory, and OmnibusCloud matches work to machines by capability. (Support across a far wider range of devices is where this is heading — see The Ultracomputer.)
What it renders today
The first workload is 3D rendering, and it's real, not a placeholder.
- Blender — Cycles, Eevee / Eevee Next and Grease Pencil; stills, animations, tiled single frames split across machines, and straight-to-video output. External dependencies a scene needs — linked libraries, Alembic/USD caches, OpenVDB volumes, image sequences — are carried to the machines automatically, so a scene that isn't fully self-contained still renders.
- 3ds Max — rendering through the same distributed network.
Most scenes render as-is. Some dynamic simulations need to be baked before they're submitted — distributed rendering splits a job into independent frames, and an unbaked simulation won't survive that split. Rendering is the first kind of work the network handles; more workloads follow through new controllers (see below).
How it works
OmnibusCloud is one platform built in three layers — not three products. The same engine powers an organization's private cluster and the global public network; what changes between them is not the engine, but how widely it reaches.
- WitEngine — the execution core. The distributed-computing foundation: it defines units of work, distributes tasks across heterogeneous machines, balances load by capability, handles retries and failures, and manages the controllers that carry workload logic. It runs identically behind a firewall or across the public internet.
- WitCloud — the deployable server. Install it on your own hardware and your machines become a private cluster — client registration, controller distribution, health monitoring, capability-based matching, scheduling and result aggregation, with nothing leaving your boundary.
- OmnibusCloud — the public network. WitCloud opened to the internet: it adds the portal where projects are published and people join with their machines, and the wider network that coordinates owners, creators and developers. It launches as crowdcomputing.
How a job flows
A workload moves through the same lifecycle, whether it's a public crowdcomputing project or an internal job:
A controller defines the work — what it needs, how it splits, how results are validated. A script composes the job. Machines are matched by capability, the work is divided into units (frames, tiles), and tasks are scheduled only to machines that are capable, idle and permitted. Work runs and returns, results are validated — useful compute has to be verified compute — and progress shows up on the portal. If a machine drops offline mid-task, its work is reassigned automatically.
Why this model
OmnibusCloud isn't trying to sell cheaper cloud — it's creating a new source of compute, drawn from machines that already exist rather than from new datacenters.
- Efficient by design. Machines contribute only during their natural idle periods — no new hardware to manufacture, no servers running hot around the clock for work that doesn't need them.
- Scales by participation. The network grows with every machine that joins. There's no fixed capacity ceiling.
- Resilient. Machines come and go constantly; a gaming PC drops off the moment its owner starts playing, and the network adapts. There's no single point of failure and no maintenance window.
- Location-independent. Capacity isn't tied to where the datacenters are — it's wherever the machines already are.
This complements datacenters rather than competing with them. Tightly-coupled, latency-sensitive work belongs in a datacenter and always will; OmnibusCloud is for work that splits into independent pieces, each running long enough that moving it around is cheap by comparison. Rendering fits that shape naturally.
Where it is today
OmnibusCloud is in open beta. The public crowdcomputing portal is live, the first workload is rendering (Blender and 3ds Max), and both ways of getting help — public projects and private groups — work today. Contributor clients run on Windows, Linux and macOS (Apple Silicon).
This is the concrete beginning of a much larger idea: prove that real people will connect real machines to help real projects produce real results. From there the path expands — more workload types, private on-premise clusters for organizations, and a developer ecosystem around the SDK.
Build on it
OmnibusCloud is extensible by design. Everything the network can do comes from controllers — plugins that add new data types and operations, including the rendering workflows above. Scripts then compose activities from different controllers into one pipeline, so each controller added to the network increases what every script can do. Anyone can write one.
- Explore the open controllers and SDK: github.com/OmnibusCloud/ — sample controllers and a public SDK for building and debugging your own extensions.
- The SDK lets you develop a controller, test its distributed behavior locally, and then deploy it to a private WitCloud cluster or the public OmnibusCloud network. Every controller is reviewed before it runs on contributors' machines, and stays self-contained when it does.
Documentation and guides live at omnibuscloud.io.
The Ultracomputer
Everything above is the beginning. Here's where it's heading.
The ultracomputer won't be built in one datacenter. It will be assembled from the machines already around us — desktops, laptops, workstations, gaming PCs, office computers, and eventually phones, consoles and more. Machines in homes, studios, schools, labs and companies, most built for moments of peak use and idle the rest of the time.
It isn't a supercomputer in one place, and it isn't a cloud run by one company. It's a global, heterogeneous compute fabric — many devices, many participants, many workloads, coordinated into one. The goal isn't merely to use idle computers; it's to make idle computation programmable, governable, and economically useful.
The economic model
An economic model will grow around it. Crowdcomputing — contributing to a project for its own sake — stays a permanent, first-class part of OmnibusCloud. Alongside it, the network is meant to support a wider compute economy: owners earn benefits for keeping a capable machine available, people and organizations pay for the compute they use, and developers extend what the network can run. Together, that turns idle machines into a genuine new supply of computing — value for the people who provide it, verified compute for the people who use it.
The two sources of compute are pulling apart. Building new datacenter capacity keeps getting more expensive — the same demand driving the need for compute has pushed up the price of the hardware itself. The machines already in homes and offices are the opposite: bought and paid for, much of their capacity acquired before that run-up. One source adds capacity at a rising cost; the other puts capacity that's already been paid for to work.
The reward model rests on one principle that keeps it trustworthy: contributors are rewarded for qualified availability, not utilization. Connect an eligible machine, follow the rules, and stay available for the agreed time, and you receive the benefit — whether the network used your machine for five hours or fifty is a scheduling question on OmnibusCloud's side, not yours.
And none of it runs on tokens. Value is denominated in ordinary terms — subscriptions, credits, access, savings — familiar and bounded, without the volatility and friction a crypto network would add.
The destination is a governed fabric: visible projects, reviewed workloads, owner control, open controller examples, and result validation. Open enough to grow; controlled enough to trust.
It won't appear all at once. It begins with early contributors, creators and developers — and with a simple action: connect a machine, create a project, tell the story, join the beta.
OmnibusCloud begins with crowdcomputing. It grows toward the ultracomputer.
Get started
- Try it: omnibuscloud.com — open the portal, contribute a machine or create a project.
- Learn more: omnibuscloud.io — the vision, the architecture, and the docs.
- Build on it: github.com/OmnibusCloud/ — write your own controllers.
Let's build the ultracomputer together!