TL;DR
Get business pricing on tech for your team
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
Simon Edwardsson says he fine-tuned a 360-million-parameter model to imitate terminal behavior by predicting screen updates from individual keypresses. The browser demo can reproduce activities such as editing files and playing Snake, but it has no real shell or filesystem, so its output is simulation rather than command execution.
Developer Simon Edwardsson has built a 360-million-parameter model that imitates a computer terminal by predicting how its screen changes after each keypress. The browser demo has no shell or filesystem behind it: it generates simulated terminal updates, a distinction that matters because its apparent commands and files are not being executed or saved by a real operating system.
Edwardsson’s report says the model is based on Qwen2.5-Coder-0.5B, which he fine-tuned using recordings of terminal sessions generated from real programs running inside Docker containers. The resulting model is described as 360 million parameters. The author reports that the demo can imitate tasks including creating files, using Vim and tmux, and playing Snake. Those examples show what the model can simulate; they do not establish that the demo performs real file operations.
Instead of generating ordinary text alone, the model predicts changes to a character grid. Each session begins with a screen snapshot, including its dimensions, contents and cursor position. A user’s keypress is passed to the model, which returns instructions for rewriting rows and positioning the cursor. It can also receive timed wait inputs, allowing it to model activity such as Snake moving without another keypress.
To reduce the cost of representing screen changes, Edwardsson added a row-copy operation for shifts such as scrolling. He says the model uses a 333-token vocabulary and grammar-constrained decoding so its screen-update output follows the permitted format. His training set contains 336,000 episodes, equivalent in the report to about 2 billion tokens. Edwardsson also identifies teaching the model to correct its own mistakes and decoding screen rows in parallel as major improvements, though the supplied report excerpt does not provide detailed benchmark results for those techniques.
Why Terminal Simulation Matters
The project tests a narrower version of an idea associated with world models: rather than responding to a command by running software, a model predicts what a user would see next. Terminals are a practical test case because their output is a grid of characters rather than a large sequence of image pixels, and a developer can generate aligned examples by recording real programs.
For readers, the key distinction is between convincing output and actual execution. A simulated terminal could be useful for experiments in interactive modeling, but it should not be treated as a dependable command line, a secure environment, or a place to store work. Edwardsson specifically suggests typing “pythoon” as a way to see that the demo is not a real shell. The model’s apparent ability to handle familiar programs does not mean those programs are running inside it.
Linux command line for beginners book
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
How Edwardsson Built the Demo
Edwardsson says the project began after he saw Genie 3 and started thinking about applications learned from interaction rather than written as conventional software. Without access to a large GPU cluster or a large video dataset, he narrowed the experiment from a game world to a terminal. He describes the terminal as a manageable setting where the next state can be represented as text-grid changes and training examples can be recorded from real shells.
The training sessions were generated in Docker with randomized usernames, hostnames, prompts, terminal sizes, directories and files. Activities included editing files and using tools such as Vim, Python and tmux. The report says the generator tracked session state so that users generally opened files that existed, and introduced typing errors at a 1.2% typo rate. About 35% of sessions began partway through an activity, and the data used several screen sizes rather than only one. These are details of Edwardsson’s dataset design, not an independent evaluation of the demo’s accuracy.
“There’s no shell or filesystem behind it: every keypress goes in, and the model predicts how the screen changes.”
— Simon Edwardsson, in the report’s TL;DR
What the Demo Cannot Establish
The report is an account by the project’s creator, and the material supplied here does not include an independent assessment of how often the model produces correct screen updates or keeps files and application state consistent over longer sessions. The description that it “usually” remembers recent input is Edwardsson’s characterization; the report excerpt does not specify a measured success rate or test protocol for that behavior.
It is also unclear from the supplied material how the model performs across a broad range of commands, unfamiliar programs, unusual terminal behavior or extended sessions. Since no real shell or filesystem is connected, simulated file creation and command output cannot confirm that an actual task was completed. The report recommends a desktop browser with WebGPU and a physical keyboard, says Chrome or Edge is the best place to try it, and warns that a modern phone may run it slowly. The excerpt does not give a detailed device-by-device performance comparison.
Trying the Browser-Based Model
Edwardsson has made the demo available to try in a browser; the report says it is about 208 MB and designed for a desktop browser with WebGPU. He recommends Chrome or Edge and a physical keyboard, while describing phone use as possible but painfully slow. Readers testing it should treat the display as generated output, not as a live command line, and should not rely on it to execute commands or preserve files.
The next useful evidence would be a fuller account of the model’s evaluation: how consistently it follows keypresses, handles errors, and maintains simulated state across longer interactions. The supplied report does not announce a release schedule, product plans or a follow-up benchmark, so it remains unclear whether Edwardsson intends to extend the project beyond the published demo.
Key Questions
Is WorldTUI a real terminal?
No. Edwardsson says there is no shell or filesystem behind the demo. The model predicts screen changes, so its output imitates terminal activity rather than executing commands on a computer.
What model does it use?
The report says the model is based on Qwen2.5-Coder-0.5B and was fine-tuned to 360 million parameters using recorded terminal sessions.
What can the demo imitate?
Edwardsson reports that it can simulate activities such as creating files, using Vim and tmux, and playing Snake. These are demonstrations of generated terminal behavior, not proof that the demo runs those tools or saves files.
How can I try it?
The report points to a browser demo of about 208 MB and recommends a desktop browser with WebGPU, preferably Chrome or Edge, and a physical keyboard. Edwardsson says it may work on a modern phone but run slowly.
Source: hn
Halloween Picks
halloween
As an affiliate, we earn on qualifying purchases.
