Erste Schritte

Schnellstart

Es gibt nichts zu installieren und kein Konto anzulegen. Scellis läuft dort, wo du ohnehin bist — in einem Browser-Tab. Beim ersten Öffnen läuft ein einmaliger Bootstrap von wenigen Sekunden und füllt eine lokale Datenbank mit dem Arbeitsset der Engine; ab dann läuft alles, was du hast, vollständig offline — Authoring, Compute, Training, Commits — und nur das Entdecken neuen Contents erreicht das Netz. Scellis ist derzeit eine Development Preview — lies das hier als den Ablauf, um den die Plattform gebaut ist: sechs Schritte vom leeren Tab zu einem Ergebnis, das jemand anderes aus einem Link reproduzieren kann.

1. Öffne die App#

Öffne das Studio in einem aktuellen Browser. Der erste Besuch holt die Engine und füllt deine lokale Datenbank — die Blöcke, Ops, Viewer und Templates, mit denen du startest — in Sekunden, genau einmal. Danach ist der Tab local-first: Klapp den Laptop zu, steig ins Flugzeug, arbeite weiter. Nichts, was du baust oder ausführst, braucht eine Verbindung; das Netz kommt erst zurück, wenn du Content suchst, den du noch nicht hast. Das ist das ganze Versprechen hinter Local-first — der Server verstärkt deine Arbeit, er steht nie in ihrem kritischen Pfad.

Hinweis

Ohne Login bist du kein eingeschränkter Nutzer. Auf deinem eigenen Gerät kannst du jede Berechnung erstellen und ausführen — unbegrenzt — eine Untergrenze, die in jedem Plan gleich ist, auch ganz ohne Konto. Ein Konto legt Plattformdienste obendrauf: Sync über deine Geräte, Teilen, Zusammenarbeit. Meldest du dich später an, übernimmt Scellis deine lokale Arbeit einmalig und idempotent ins Konto — nichts geht verloren, nichts baust du doppelt.

dein Gerätlokale DatenbankEngine + dein Contentalles läuft hierbauen · trainieren · committendas Netzein Bootstrapdann: Entdeckung
Abb. 1 — Dein Gerät ist die Grenze. Es hält die Datenbank und alles, was dagegen läuft; das Netz berührt es nur, um Content zu liefern — einmal beim Bootstrap und danach nur für Content, den du suchst.

2. Setze einen Workflow zusammen#

Eine leere Canvas ist keine leere Seite. Die Studio-Canvas bietet Starter, eine Template-Galerie samt Beispieldatensätzen und einen Pfad für den ersten Lauf, gebaut für genau diesen Moment — jedes mitgelieferte Template läuft Ende zu Ende, von den Daten bis zur ersten Metrik, ohne einen einzigen Edit. Nimm eines, oder bau von Grund auf: Zieh Blöcke aus dem Katalog auf die Canvas und verdrahte sie zu einem typisierten Graphen — laden, aufbereiten, trainieren, evaluieren. Der Editor validiert, während du baust: Ein Typfehler zeigt sich beim Verdrahten, nicht mitten im Lauf. Was ein Block wirklich ist — eine versionierte, vertraglich gebundene Einheit statt eines Schnipsels — ist Thema der Kernkonzepte.

Allein komponierst du nur, wenn du willst. Der Copilot kann von der ersten Minute an Blöcke entwerfen, verdrahten und den Graphen erklären — über dieselbe API wie du, sodass alles, was er tut, auch klickbar gewesen wäre, und alles, was du klickst, er lesen kann. Ein Copilot-Startkontingent ist inklusive; deinen eigenen Model-Key bringst du später mit.

3. Bring deine Daten mit#

Lokale Dateien sind der Standard und der schnelle Weg: Zeig mit einem Block auf eine Datei, und sie streamt an Ort und Stelle von der Platte — hochgeladen wird nichts, denn „Daten laden“ heißt lesen, nicht senden. Liegen die Daten woanders, holst du sie über Connectors — HTTP, Cloud-Speicher, Object Storage —, jeder ein deklarierter, einwilligungspflichtiger Effekt, mit Zugangsdaten, die verschlüsselt auf deinem Gerät bleiben und nie synchronisiert werden. Einen Schlüssel, den die Plattform strukturell nie hält, kann sie auch nicht preisgeben.

4. Erst der Preflight, dann der Lauf#

Drückst du auf Start, passiert zuerst: nichts. Der Planner berechnet den Spitzenspeicherplan für den ganzen Graphen und prüft die Machbarkeit gegen dein tatsächliches Gerät — nicht gegen ein nominelles —, bevor ein einziger Puffer alloziert wird. Er antwortet in drei Farben:

BefundBedeutung
GrünDer Plan passt auf dein Gerät. Führ ihn aus.
GelbEr passt mit einer benannten Änderung — kleinerer Batch, Checkpointing, eine andere Präzision.
RotSo deklariert passt er nicht. Der Planner benennt, was zu ändern ist, bevor irgendetwas alloziert wird.

Du justierst, bevor irgendetwas ausgeführt wird — nicht nach einem Out-of-Memory-Absturz. Dann senkt sich der Graph über eine inspizierbare IR-Leiter zu WebGPU ab und läuft auf der GPU, die schon in deinem Rechner steckt — jedes Ergebnis gegen eine CPU-Referenz innerhalb deklarierter Toleranzen geprüft, dasselbe Korrektheitsregime, das Built-ins und deinen eigenen Code gleich behandelt. Ein Gerät ohne nutzbares WebGPU läuft denselben Workflow auf einem langsameren CPU-Pfad, hinter einem lauten, dauerhaften Banner, nie als stille Ersetzung; ein Gerät ohne beides öffnet das Studio trotzdem — zum Komponieren und Inspizieren.

WorkflowPlannerSpitzenspeicherplanpasstpasst mit Änderungabgelehntmit benanntem Fix
Abb. 2 — Nichts wird alloziert, bis der Planner den ganzen Plan gegen dein tatsächliches Gerät geprüft und einen Befund geliefert hat; nur Grün läuft ungefragt.

5. Beobachte und iteriere#

Ein Lauf ist keine Blackbox, die du aussitzt. Eine Live-Loss-Kurve, laufende Diagnosen und Budget-Warnungen strömen in dem Moment, in dem sie entstehen; du pausierst, setzt fort oder brichst ab — jederzeit. Checkpoints sind inhaltsadressierte Bündel aus Gewichten, Optimizer-Zustand und RNG-Zustand: Ein fortgesetzter Lauf ist der Lauf, den du pausiert hast — die exakte Zufallssequenz fortgeführt, keine Annäherung. Auch lange Läufe sind versorgt: Das Throttling im Hintergrund-Tab wird angesagt, ein optionaler Wake Lock und ein abgekoppeltes Lauf-Fenster halten eine Trainingsschleife am Leben, und ein abgestürzter Tab versöhnt sich zu „unterbrochen“ mit Ein-Klick-Fortsetzen-vom-Checkpoint.

6. Committe und teile#

Ist ein Ergebnis es wert, behalten zu werden, committe es. Ein Commit ist eine inhaltsadressierte Version deiner Arbeit — ein unveränderlicher Hash über das exakte Programm, seine Eingaben und seine deklarierte Präzision. Teil den Link, und die Gegenseite löst dasselbe Programm, dieselben Eingaben und dieselbe Determinismus-Stufe wieder auf und reproduziert das Ergebnis auf ihrem eigenen Gerät. Die Unterscheidung, an der Scellis festhält, ist klein und strikt: Zusammengearbeitet wird am Entwurf; zitiert wird ein Commit.

Diesen Link Ende zu Ende reproduzieren zu sehen — Provenienz, Fork und alles — ist ein eigener kurzer Rundgang: ein Ergebnis reproduzieren. Die Garantien darunter — Hash-Identität, Dataset- und Split-Hashes, die zwei ehrlichen Stufen von „dasselbe Ergebnis“ — sind Reproduzierbarkeit.