Diffusion Text Lab

Approach

Offline (before the page is written), train a small absorbing-state discrete diffusion language model in Python/numpy on a fixed corpus of ~300 short template-generated sentences over a ~300-word vocabulary, sequences padded/truncated to 10 tokens. The model is a 1-layer transformer with embed dim 32 (token + positional embeddings, one self-attention block, one small MLP, output projection back to vocab logits), trained by the standard masked-diffusion objective: corrupt a random fraction of tokens to a MASK token at a random noise level and predict the originals. Export the trained weights (roughly 35-45k floats total) as a single JSON literal and inline it directly into index.html as `window.__DIFFUSION_WEIGHTS__`, so the shipped page has zero fetches and zero dependencies. In-browser vanilla JS reimplements the exact forward pass (matmul, softmax, attention) to run reverse diffusion sampling client-side: starting from an all-MASK sequence, at each of ~18 steps it scores confidence per position and unmasks the most-confident tokens, redrawing the sentence with a mask glyph standing in for still-noisy positions. This is plain JS/typed-array math on tiny matrices, so no WebGL, no build step, and no bundler are needed — a single static HTML file is sufficient and more reliable than a toolchain for an artifact this small.

The source post

https://x.com/Chenfeng_X/status/2110838802029625820

Scoring

Pick

ORL-DLM's pitch is that diffusion language models denoise text the way image diffusion denoises pixels, which almost nobody outside the research crowd has actually watched happen. That's reshapeable into something small and honest: train a toy diffusion LM ahead of time, bake its weights into a static page, and let a visitor hit generate and watch tokens visibly resolve from noise into a sentence over the real denoising steps, no account, no key, no network call at any point. Every other candidate either needed live model weights we can't fetch during this network-less build, a live API call per interaction, specialized hardware, or was too large to run client-side at all, so this was the only one of the eight that could be both genuinely demonstrated and fully self-contained.

source: https://x.com/Chenfeng_X/status/2110838802029625820

Review

mean 4.75/5

No change: the gate passed first time with no repairs, pick/plan had one well-reasoned candidate (seven others correctly rejected for needing weights or live calls this sandbox can't fetch), build's declared-default executor continues its clean streak, and the artifact is honestly represented with its limitations disclosed rather than papered over. Nothing here points at scout noise, pick taste, a repeatable build lesson, or an underperforming executor. The one real issue tonight — the custom domain serving 522/TLS-handshake-failure for roughly a minute right after publish before settling to 200 — is the same gap escalated on 2026-10-13 (publish.py defines wait_for_https() to distinguish 'certificate still issuing' from 'actually broken', but stage_publish never calls it, so published.json is written without confirming the domain actually serves 200) and is pipeline code, not a prompt or routing block this stage may edit. It has now recurred on four consecutive ship nights (10-13, 10-14, 10-15, 10-16) — no longer weather, but still outside this stage's editable scope.

escalated: Re-raising 2026-10-13's finding: publish.py's wait_for_https() exists specifically to tell a slow cert from a dead host, but stage_publish never calls it before writing published.json. Every one of the last four ship nights (10-13 through 10-16) has shown the custom domain returning 522 or a TLS handshake failure for 30-90 seconds immediately after deploy before settling to 200 on its own. Every night has self-corrected by the time of review, so no night has actually shipped a dead URL yet — but that is luck in the review's timing, not a guarantee, and the gate stage runs before publish so it never observes this window at all. Four consecutive recurrences is enough to stop calling it noise; wiring wait_for_https into stage_publish (or recording its result in published.json) would let a night where the domain stays stuck be caught as a failure instead of silently recorded as shipped.

Cost

metered APIs only, summed across every attempt at this project; Claude and Codex run on flat-rate subscriptions and have no marginal cost per night

What it looked at

Gate

Stages

Notes

Omitted for lack of

None. This experiment needs no runtime service or generated imagery.