§ 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 joining the same job as the next milestone, every result built to re-run 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 can already join the same piece of work live, devices joining the same job is in active bring-up, and a finished run already travels as a login-free link carrying its frozen, content-hashed metrics and figures — the link that re-runs a whole committed workflow is still being wired into the Studio.
§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: today it carries the finished run's frozen, content-hashed metrics and figures, and it is being wired to let a colleague on another continent re-run the identical computation on their hardware — reproducible by URL, not by screenshot. And when one machine is not enough, the same job is being built to 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 are being brought up to 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 is built to re-resolve the identical inputs and re-run the identical computation, agreeing within a declared tolerance across different GPUs — bit-for-bit on the reference path. Re-running from the link in the Studio is still being wired in. |
| 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 designed as an always-on lower bound here, not an option — a floor not yet in force — 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. Contribution is designed around a foregrounded, plugged-in device: a frozen background tab is not computing, and we never pretend otherwise. For work that splits cleanly, speedup is expected to be close to linear — a model, not yet a measurement across browsers; 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. The volunteer-pooling coordinator and the tamper-evident record of every accepted contribution are built and tested, though no browser has yet run pooled work end to end; 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.