One interactive brief — shape a river with a real water simulation, dial its flow, raise ridges, dig channels — given to the same Qwen3.8-27B checkpoint on a Mac Studio and on a DGX Spark, thinking off and on, two seeds each. Eight games, all different. The two long thinking-on runs on the Spark (84–99K tokens, 36–41 minutes) built the only two that behave like a river; the Mac's thinking-on runs stopped after 3–5 minutes and came out middling. Thinking off produced four fast, mostly dark or broken sandboxes.
Ranked by eye, best first. Every clip plays the same scripted input: idle, flow to zero, flow to max, a ridge dragged across the middle, a channel dug diagonally.
84,000 tokens (217K chars reasoning) · 40m30s · 34.57 tok/s · 29 KB
Best of the eight. A winding river over lit, textured terrain; flow 0 shrinks it (HUD: "seeping away"), max floods the low end into a lake; the ridge and dig shift its shape a little. Zero console errors.
98,741 tokens (243K chars reasoning) · 35m52s · 45.88 tok/s · 32 KB
Good. Clean lit scene and HUD; water collects into a valley lake and the volume readout climbs 562 → 5,195 with flow. Rerouting around the ridge/dig is not obvious in the clip.
12,074 tokens · 2m31s · 79.75 tok/s · 32 KB
Partial. Terrain renders near-black, but channels show and the ridge visibly raises ground with water spreading around it.
11,070 tokens (18K chars reasoning) · 2m54s · 63.63 tok/s · 13 KB
Partial. Coloured terrain; water pools and grows at max flow — floods like a lake rather than a river.
16,960 tokens (34K chars reasoning) · 4m44s · 59.64 tok/s · 12 KB
Weak. The valley sits under a sheet of water even at flow 0.
9,435 tokens · 2m02s · 78.03 tok/s · 25 KB
Weak. Polished HUD, but terrain renders near-black and there is one streak of water; the flow slider has no visible effect in the clip.
11,511 tokens · 2m42s · 71.09 tok/s · 29 KB
Weak. Near-black terrain, HUD prints raw <small> tags, a faint patch of water.
11,289 tokens · 2m40s · 70.4 tok/s · 29 KB
Broken as shipped: `water` declared twice (a Float32Array and the water mesh), so the module never runs. Two one-line fixes tried (rename the mesh; a for-loop that never incremented x); a third error then appeared (water volume goes NaN, TypeError every frame) and the repair was stopped per the three-error rule. The playable link is the untouched original.
Prompt, verbatim:
Create a single self-contained HTML file: a three.js mini-game where the player shapes a river. Load three.js and OrbitControls from a CDN via an import map; no other assets. - Terrain: a 128x128 heightfield valley sloping from one edge to the opposite edge, rendered as a lit mesh with grass, dirt and rock colouring by height and slope. - Water: simulate it on the same grid (shallow-water or virtual-pipe heightfield, not a pre-drawn path). A spring at the high edge adds water every step; water drains off the low edge. Render depth as a translucent surface above the terrain, lighter or foamy where it moves fast. - Tools: left-drag raises terrain (drop rocks/land); shift-drag or right-drag lowers it (dig). A brush-size slider. Water must visibly find a new path within a few seconds of a change. - Flow: a slider plus the +/- keys set spring rate from 0 (the river dries up) to high (it floods its banks). - HUD: flow rate, total water volume, FPS, a Reset button. - Camera: orbit with the middle mouse or while holding Space, so it doesn't fight the tools. Keep the sim stable at any setting; clamp so it never blows up. Output only the HTML.
Serving. Qwen3.8-27B as Vontra's MLX 4-bit checkpoint with z-lab's DFlash2 drafter, on TensorFold 0.3.6.3 on both machines: the MLX lane engine on a Mac Studio M4 Max (128 GB, 262K window) and the CUDA engine on one DGX Spark (196,608 window — a 262K window hung that Spark earlier the same day). Sampling on every arm: temperature 0.7, top_k 20, top_p 0.95, max_tokens 196,000, seeds 42 and 43.
Same seed, different game. Metal and CUDA diverge within the first few hundred characters, so each machine's run is an independent sample — this is not a determinism test. With two seeds per cell, the pattern here (the Spark's thinking runs going 5–9× longer and building better games) is a result, not yet a rule; more seeds would settle whether it is the engine or the draw.
Repairs. None on seven of eight arms. Spark / thinking off / seed 43 ships a module that cannot run (water declared twice); two one-line fixes were tried and a third error appeared, so it is published broken with the attempt documented in REPAIRS.md. Its clip shows the unrunnable original.
Recording. Headless Chromium on Metal, 1280×720, fixed 24 fps clock, 32 s per arm, identical scripted mouse and slider input on every arm. Math.random was pinned on the capture side only; the published files are untouched. A fixed clock steps each game at 24 fps, so slow simulations may still be settling at the end of the clip — open the originals to play them live.