Updated Sep 8, 2026 · Week 1 board.
- Pre-Train Preview appears on the Advanced canvas at /build/[slug] the moment Train is clicked, before the run starts.
- A single side-effect-free async function chooses the backend: it does not initialize TensorFlow.js and does not load Pyodide.
- TF.js models climb WebGPU, then WebGL2, then WebGL1, then CPU; Python models route to Pyodide if available, or CPU if not.
- The WebGPU check requests a real adapter only to confirm one exists, then tries to read the vendor and device name, wrapped so a failed read cannot break the probe.
- A repository-wide search finds exactly two references to the preview component: its lazy import and its own test file; the guided /build root does not import it.
- Whether a live training run actually lands on WebGPU instead of falling back to CPU is not yet recorded in telemetry.
Hitting Train on a saved model's Advanced canvas, part of Studio at /build, opens a modal that names the backend the run will use before any training code executes. The name comes from a single async function that answers three questions in order: does WebGPU exist, does WebGL2 exist, is CPU the only option left. Python models skip that ladder and route to Pyodide, or to CPU if Pyodide is unavailable. TF.js models climb the ladder from WebGPU to WebGL to CPU, stopping at the first one the browser confirms.
One probe, four possible answers
The header comment on the file states the helper is side-effect-free: it does not initialize TensorFlow.js, does not load Pyodide, and does not request a WebGPU adapter beyond the existence check. The actual engine only initializes later, inside the training worker, after the modal is read and Confirm is clicked.
The WebGPU check still requests a real adapter, the same request a live session would make. It also tries to read the vendor and device name so the modal can name the actual card, wrapped so that read can never break the probe. Some browsers gate that detail behind a flag; the code falls back to a generic line rather than failing the check. The WebGL side asks for a WebGL2 context first, then falls back to WebGL1, because WebGL2 tracks more closely with the backend TF.js wants to use.
A wrong guess costs more than no guess
A backend badge that guesses wrong sends a run into GPU-speed expectations and CPU-speed reality, with no warning until the run is already slow. Building the preview as a pure probe, instead of a short trial run of the engine, keeps the modal's answer tied to what the browser can do right now rather than what the team hopes it will do.
A second modal, a plain-language Pyodide explainer, sits one tap away for the Python side. It loads only when opened, the same lazy pattern the Advanced canvas uses for the preview itself, so neither modal adds weight to the page until a reader asks about the backend.
The Receipts Drawer
The tell here matches earlier posts in this series: a comment inside the file naming exactly what it will not do, not just what it will. Side-effect-free is a claim a reader can check against the code, unlike a line about speed. What the file cannot answer is whether a real session lands on WebGPU instead of dropping to plain CPU; that split sits in telemetry nobody has pulled yet.
FAQ
Where does Pre-Train Preview appear? Right on that canvas, at /build/[slug], the moment you click Train and before the run starts.
Does the backend check load TensorFlow.js or Pyodide to find its answer? No. The probe is side-effect-free; it checks what is available without initializing either engine.
How does it choose between WebGPU, WebGL, and CPU for a TF.js model? In that order. WebGPU first if available, then WebGL, then CPU as the fallback everyone has.
What happens for a Python model instead? It routes to Pyodide if available, or CPU if Pyodide is not available. The WebGPU/WebGL ladder does not apply to Python models.
Does the modal load its own explainer, or does the page carry it by default? It loads on demand. A separate Pyodide explainer modal is lazy-imported only when you open it from the Advanced canvas.
