The Training Page

/editor/train trains a model for an AI bot on your own machine: the bot plays games against itself with your rules kernel, a small neural network learns from them, and each generation's checkpoint is measured against fixed opponents. It is a separate page from the editor (opening it is a full page load, and it is not indexed by search engines). Training a bot model is the walkthrough; this page is the reference.

Two modes#

Project mode — /editor/train?project=<id>, which is what Manifest ▸ Bots ▸ Train a model… opens. The page trains on the const kernel declared in your project's scene scripts as the editor last saved them on this device, and says when that was. Edits you have not saved are not there. It can only read a project the editor has opened on this device — it reads the editor's local copy, read-only, and needs no sign-in — so a link cannot point it at a project you do not own. A project you own can still hold code you did not write (a fork, an imported project), which is why its kernel is walled off when it runs (below). A script whose kernel cannot be trained on is listed with the reason (kernel-impure, kernel-missing or kernel-unparsable) and the compiled line.

Demo mode — /editor/train with no project. It trains on the built-in Reversi and tic-tac-toe rules, to show how training behaves on your device. Runs are kept in the browser and a checkpoint can be downloaded, but there is no project to export to.

The first time you train on a project, the page asks before it runs your rules code on this device. The kernel runs in background workers rather than the table's sandbox, after a purity check, and those workers are walled off: they are created inside an isolated frame on a separate site, training.diceytable-sandbox.com, with no access to this one (not your other projects, your account or the network), and inside them the browser's built-ins are locked so the code cannot change them and every global but a few language built-ins is hidden from it. On WebGPU the graphics card is driven by a separate worker in that frame; the rules code can only hand it board positions to evaluate, never use the GPU itself. What the code can still do is use your processor and memory for as long as the run lasts — train on projects whose scripts you wrote, have read, or trust.

If the sandbox site cannot be reached (a network that blocks it, or the moment between two deploys), the page says so and runs the same workers in an isolated frame of its own instead — on WebAssembly only, since that frame has no WebGPU.

Run settings#

More settings adds evaluation games per opponent (40), the replay window (5 generations), batch size (64), epochs per generation (2), learning rate, L2, a step cap per generation, games per worker at once (only useful on WebGPU), leaf batch, and the number of opening moves played with randomness. What to expect estimates games per second, the length of a generation and what the run will reach in its time, from measurements on this device.

Running#

▶ Start, ⏸ Pause / ▶ Resume and ■ Stop. The status line shows the phase, running time, time left before the ceiling, the generation and the screen wake lock.

Keep the window open and in the foreground. The page holds a screen wake lock while it runs and warns before the tab is closed, but closing it, a sleeping laptop, or the browser discarding the tab to save memory (Chrome's Memory Saver does this to background tabs) stops the run.

Every generation is committed as a checkpoint, so a stopped, crashed or reloaded run resumes from the last one: Unfinished runs lists it with Resume. A run can be trained in one tab at a time; another tab is told the run is busy. All runs in this browser lists every run, to view, resume or delete. Pausing or resuming changes nothing about what is learned: each generation's training starts a fresh optimiser, as the trainer CLI's does, so a resumed run trains exactly as an uninterrupted one would. A run whose saved settings are not ones the form would accept is refused on resume, with the reason.

The strength gauge#

After each generation the new checkpoint plays every opponent, colours alternating from shared random openings:

The heuristic search is what a host that cannot run your model falls back to, so a model that does not beat it makes your bot heavier for nothing. With 40 games per opponent a win rate is only accurate to about ±15 points.

Checkpoints#

Pick a generation, then:

• Download checkpoint (.onnx) — the model file, for diceytable-bot-trainer model check or eval.
• Export records (.jsonl) — every generation's self-play games as one file, for the trainer CLI.
• Delete older than 10 — free space, keeping the newest ten generations.

In project mode, Export kernel for the CLI… (above the settings) downloads the selected kernel as a JavaScript module, <kernel id>.kernel.mjs — the same code this page trains on, cut out of the scene script with the helpers it uses — ready for diceytable-bot-trainer … --kernel <file>. ⚠ The CLI runs that file with your full permissions: there is no sandbox on the command line. Export only kernels you wrote, have read, or trust.

• Export checkpoint to project as model… (project mode) — enter a model id and a label. The page prepares ai/<id>.onnx and its manifest entry next to its runs, never inside your draft, and links to the editor; the Bots tab there offers the trained model and adds it through the ordinary model import (validation, the credit gate, the file write), so Save and Publish include it. It works whether or not an editor tab is open.

Runs are stored in your browser's private storage (ai-training/<project or demo>/<run>/ with run.json, gen-<n>.weights.json, gen-<n>.onnx, records-<n>.jsonl and eval-<n>.json — the CLI's loop uses the same names). Nothing is uploaded.

The compatibility is one way. The CLI can read, evaluate and continue a browser run's files. The browser cannot pick up generations the CLI added: run.json is its commit record, and on Resume it deletes every generation file above the one run.json vouches for, as the remains of an interrupted step.

What to expect#

Measured on a fast desktop: a 30-generation demo run of the tiny network on Reversi (about 6 minutes) beat random 70% of the time, roughly matched greedy, and lost to the heuristic search (18%). No overnight run has been measured. Small networks, a few thousand games and a good heuristic to beat: expect to need the CLI and a GPU for a model that clearly earns its place.

AI agents cannot drive this page: it has no agent tools.

See also#

• Training a bot model — the whole path, including the CLI.
• Manifest ▸ Bots — where Train a model… lives and where an export is imported.
• RulesKernel — the kernel convention.