§ About
The instrument science was missing.
Scellis is a browser-native, local-first platform for scientific computing: you draw a workflow, and the engine compiles it to code that trains on the graphics card already in your machine — your team on the same workflow, their devices on the same job, every result re-runnable from a link. This is the story of why we are building it.
Abstract
Scellis treats a computation as something you can compose, inspect, share, and re-run. A small, stable engine runs in a browser tab; every capability — blocks, models, GPU code, viewers, connectors — arrives from a catalog and runs on the hardware you already own. There is nothing to install and nothing you have to upload. People and devices can join the same piece of work, and every committed result is re-runnable from its link.
§1 · Why Scellis exists
The detour between a question and an answer
For most people, running a real computation still means a detour. An afternoon disappears into an install that fights the operating system. A cloud bill meters every GPU-hour. Legal says the data may not leave the building. And — quietest and most corrosive — the result is one nobody else can reproduce, because the environment that produced it is already gone. None of that is science. It is the tax you pay to touch a computer at all.
Scellis is a bet on a shift most people walked past. The browser quietly became the most universal runtime we have — and with WebGPU it became a real compute substrate, able to reach the graphics card already sitting in the machine in front of you. That is the whole opportunity: if training, not just playback, can run in a tab, then the data-center detour was never essential. Computation stays local by default, not as a mode you switch on.
What that buys is deceptively simple. You open a tab: no install, no queue, no upload. You draw a workflow, press run, and it trains on your own GPU. You share the result as a link, and a colleague on another continent re-runs the identical computation on their hardware — reproducible by URL, not by screenshot. And when one machine is not enough, the same job can spread across the devices you can reach. The heavy machinery is still there. It has just moved out of the way.
We build Scellis because tools decide which science is easy, and easy science is the science that actually gets done. Make rigorous, reproducible, shareable computation the path of least resistance, and more of it happens — by more people, in more places. That is the entire ambition: not a faster GPU, but a lower floor, with the whole platform waiting in the one place everyone already has open.
§2 · What we're building
A small engine, and everything else as content
The compiled application brings almost nothing with it. That is the point.
What we compile and ship is a small engine. It knows how to turn a drawn workflow into code your graphics card can run, to check that code against a reference implementation, to train a model, and to hold the rules. It deliberately does not know what any scientific field is. Everything domain-shaped — blocks, models, GPU code, viewers, datasets, connectors — is content delivered from a catalog and cached on your device, never built into an app release.
That single line is the whole architecture. Because capability lives in content, you can author the same things we do — down to the GPU code and the gradient rules — and the engine cannot tell your work from ours at the moment it runs. You are not writing a plugin at the edge of someone else's program. A missing capability is never a queue you wait in; it is content you, or someone before you, can add.
The result is a platform that can grow faster than any one team could build it: more people author more content, the substrate gets more capable, and more people arrive. Many of them work on the same canvas at once, and many devices can pool their compute on one workflow. We keep the engine small and correct; everything built on top of it stays open.
§3 · Principles
Four commitments the engineering keeps
Not values on a wall — properties of the system, most of them checked automatically.
| Principle | What it means |
|---|---|
| Extensibility | Capability grows through content, never through an engine release. The core stays small on purpose; what you can build with it does not — the kernels, ops, and gradient rules you write run through exactly the same checks as ours. |
| Privacy | Computation and raw data stay on your device by construction, not by policy. Anything that leaves is a declared, consented effect — never ambient — and connector credentials are encrypted on the device and never synced. |
| Reproducibility | Every committed run has a content-addressed identity: the same link re-resolves the identical inputs and re-runs the identical computation, agreeing within a declared tolerance across different GPUs — bit-for-bit on the reference path. |
| Honesty over false comfort | Where the platform cannot control something, it says so. Limits are published, degradation is announced rather than hidden, and every guarantee is named together with the boundary at which it ends. |
That last row is a rule we hold ourselves to. We publish a page — honest limits — that lists, in plain language, exactly what Scellis cannot do and where each guarantee ends. A promise you can check is worth more than one you must trust, and drawing that boundary is how an instrument earns its place in science.
§4 · The road
Three milestones, in order
Computing together is the destination — three milestones, each stated with its honest limits in the same breath, none pinned to a date.
- 01
Federated networks
Many sites train one model while the raw data never leaves any device. The honest boundary comes in the same breath: model updates do leave, and an update can leak information about the data behind it — so accounted differential privacy and clipping are an always-on lower bound here, not an option, and this runs in permissioned consortia, never an open pool of strangers.
- 02
Crowdsourced compute
Idle laptops, tablets, and phones fuse into one cluster that runs any workload which splits into independent pieces — parameter sweeps, simulations, batch analysis, not only training. Only foregrounded, plugged-in devices contribute: a frozen background tab is not computing, and we never pretend otherwise. Speedup is close to linear for work that splits cleanly; synchronized training is held back by its slowest participant.
- 03
A market for compute time
Fleets rent out idle GPU time and are paid for verified work — dedicated, plugged-in machines only, where a contribution counts solely when verification passes. This is a market for compute time, not the content marketplace where packs and models are sold; the two are never the same thing. Volunteer pooling and the tamper-evident record of every accepted contribution are built; the priced market ships as one indivisible unit with its fraud deterrents, or not at all.
All three are one mechanism, not three products: a partitioned, verified job under three trust regimes — your own devices, a permissioned consortium, an open pool of strangers — that are never blurred into one. The distributed compute page states exactly how far each reaches, and precisely where it stops.
§5 · Who builds it
A small team, an unusual pairing
Scellis is built in Germany by a small team. The engine was designed and written end to end by one person — a machine-learning engineer at Helmholtz Munich and the Technical University of Munich — and the scientific judgment behind it comes from one of Europe's most cited scientists in machine learning for the sciences, a Leibniz Prize laureate. The first is why the system is coherent all the way to its foundations; the second is why its correctness claims carry error bars.
If you want the mechanics rather than the story, the docs go from your first workflow down to what the engine does underneath, and the field notes show the platform doing real work. Who is building it is one page over.