Quickstart — Scellis

There is nothing to install and no account to create. Scellis runs where you already are — a browser tab. The first time you open it, a one-time bootstrap of a few seconds populates a local database with the engine's working set; from then on everything you have runs fully offline — authoring, compute, training, commits — and only the discovery of new content reaches the network. Scellis is in development preview today, so read this as the flow the platform is built around: six steps from an empty tab to a result someone else can reproduce from a link.

1. Open the app#

Open the Studio in a current browser. The first visit fetches the engine and populates your local database — the blocks, ops, viewers, and templates you start with — in seconds, exactly once. After that the tab is local-first: close the laptop, board a plane, keep working. Nothing you author or run needs a connection; the network returns only when you go looking for content you do not have yet. That is the whole promise behind local-first — the server enhances your work, it is never in the critical path of it.

Note

A login-free user is not a limited user. On your own device you may author and run any computation, unbounded — a floor that is identical on every tier, including no account at all. An account adds platform services on top: sync across your devices, sharing, collaboration. Sign in later and Scellis claims your local work into the account once, idempotently — nothing is lost, nothing is redone.

Fig. 1 — Your device is the boundary. It holds the database and everything that runs against it; the network touches it only to deliver content — once at the bootstrap, and afterwards only for content you go looking for.

2. Compose a workflow#

An empty canvas is not a blank page. The Studio canvas offers starters, a template gallery with sample datasets, and a first-run path built for exactly this moment — every built-in template runs end to end, from data to a first metric, with zero edits. Pick one, or build from scratch: drag blocks from the Catalog onto the canvas and wire them into a typed graph — load, prepare, train, evaluate. The editor validates as you build, so a type mismatch surfaces at wiring time, not mid-run. What a block actually is — a versioned, contracted unit rather than a snippet — is the subject of core concepts.

You compose alone only if you want to. The Copilot can draft blocks, wire them, and explain the graph from the first minute — through the same API you use, so anything it does you could have clicked, and anything you clicked it can read. A starter Copilot allotment is included; you bring your own model key later.

3. Bring your data#

Local files are the default and the fast path: point a block at a file and it streams from disk, in place — nothing is uploaded, because “load data” means read, not send. When the data lives elsewhere, you pull it through connectors — HTTP, cloud storage, object stores — each a declared, consent-gated effect, with credentials that stay encrypted on your device and are never synced anywhere. The platform cannot leak a key it structurally never holds.

4. Preflight, then run#

Press run and the first thing that happens is nothing. The planner computes the peak memory plan for the whole graph and checks feasibility against your actual device — not a nominal one — before a single buffer is allocated. It answers in three colours:

Verdict	Meaning
Green	The plan fits your device. Run it.
Yellow	It fits with a named change — a smaller batch, checkpointing, a different precision.
Red	It does not fit as declared. The planner names what to change before anything is allocated.

You adjust before anything executes — not after an out-of-memory crash. Then the graph lowers through an inspectable IR ladder to WebGPU and runs on the GPU already in your machine, every result checked against a CPU reference within declared tolerances — the same correctness regime that gates built-ins and your own code alike. A device without usable WebGPU runs the same workflow on a slower CPU path, behind a loud, persistent banner, never a silent substitution; a device with neither still opens the Studio to compose and inspect.

Fig. 2 — Nothing allocates until the planner checks the whole plan against your actual device and returns a verdict; only green runs unprompted.

5. Watch and iterate#

A run is not a black box you wait out. A live loss curve, live diagnostics, and budget warnings stream as they happen; you pause, resume, or cancel at any point. Checkpoints are content-addressed bundles of weights, optimizer state, and RNG state, so a resumed run is the run you paused — the exact random sequence continued, not an approximation. Long runs are cared for, too: backgrounded-tab throttling is announced, an optional wake lock and a detached run window keep a training loop alive, and a crashed tab reconciles to “interrupted” with one-click resume-from-checkpoint.

When a result is worth keeping, commit it. A commit is a content-addressed version of your work — an immutable hash over the exact program, its inputs, and its declared precision. Share the link and the other side re-resolves the identical program, the same inputs, and the same determinism tier, then reproduces the result on their own device. The distinction Scellis holds you to is small and strict: you collaborate on a draft; you cite a commit.

Watching that link reproduce end to end — provenance, fork, and all — is its own short walkthrough: reproduce a result. The guarantees underneath it — hash identity, dataset and split hashes, the two honest tiers of “same result” — are reproducibility.