WorldTUI: I trained a 360M model to pretend to be a terminal
A · Strong evidence A single-builder write-up by V7's co-founder with full method, ablations, held-out tests, a runnable browser demo and an honest failure list; benchmarks are self-made but the numbers are checkable.
Summary based on the full text·Original: about 14 minutes to read
In short
A 21 October 2026 post by Simon Edwardsson, co-founder of V7, on WorldTUI: a fine-tuned Qwen2.5-Coder-0.5B, cut to about 360M parameters, that acts as a terminal with no shell or filesystem behind it. Each keypress goes in, and the model predicts which screen rows change. It runs vim, tmux, a Python REPL and snake, and often remembers file contents a few commands later. The two changes that mattered most were training the model to repair its own mistakes and decoding rows in parallel.
Key numbers
- 80/106ShellBench commands right for WorldTUI, against 52 and 60 for prompted Qwen2.5-Coder-0.5B and Qwen3-0.6B
- 336ksynthetic terminal sessions (about 2B tokens) recorded from real programs in Docker
- roughly 75 GPU-hourstotal training compute on one RTX 4090
- 6.7 s to 0.87 slarge-frame p95 latency after decoding screen rows in parallel
- 208 MBint4 model size running in a browser tab via WebGPU
As reported by the source.
English·Web page·opens simedw.com
What it reports
- Screen updates are encoded with a 333-token vocabulary (256 byte tokens, 64 row tokens, a few operations, including a COPY op so a scroll costs three tokens per row instead of about 96). Decoding is grammar-constrained.
- Training data: 336k synthetic sessions from real programs in Docker with randomised personas, sizes and a 1.2% typo rate; 35% start partway through an application.
- Self-correction (a DAgger-style method): the model predicts 1-4 events, and if its screen is close to the real one, it is trained on a correction frame. Corrections may only use words seen earlier on real screens, to avoid rewarding hallucination. With extra data, PresetBench went from 24/47 to 38/47 at int4.
- Results: ShellBench 80/106 versus 52 and 60 for prompted baselines; file readbacks 9/13 versus 2/13 and 3/13.
- Parallel row decoding cut large-frame p95 latency from 6.7 s to 0.87 s on an RTX 4090; speculative verification by the same model fixes rows that need to coordinate. In the browser on an M4 Mac, a keypress takes about 60 ms.
- Dropping unused embeddings took the model from 494M to about 360M parameters; int4 brought it to 208 MB.
- Distillation finding: removing layer 7 barely changed next-token accuracy (99.3% to 98.9%) but exact memory readbacks fell from 64/64 to 0/64.
How they got it
Supervised fine-tuning plus three rounds of self-correction, evaluated on three handwritten test sets not in the training data (ShellBench, PresetBench, a 32-world memory test). Prompted baselines got three worked examples each, on a slightly different task framing.
Limits
- Benchmarks are small and written by the author; PresetBench is drawn from failures he found in the demo.
- Memory tests are short-gap (0-1 intervening commands); combining familiar commands in new ways often breaks state.
- Python output beyond simple operations is unreliable; nested directories confuse it; Firefox ran about 20 times slower.
- Weights are not yet published.
Why it matters for companies
There is no direct business use, as the author says. The useful lessons are about evaluating small models: next-token accuracy can look unchanged while a capability (here, state memory) disappears, so task-level tests matter more than loss curves. Training on the model's own errors and constrained output formats are cheap techniques that carry over to narrow in-house models. The cost (one consumer GPU, about 75 hours) shows how far a single engineer can now take a specialised model.
Summary based on the full text. Read the original for the full argument and data.Read the original on simedw.com