Super Mario runs inside an AI model: nesformer, built in about 10 seconds with zero training

Super Mario Bros. World 1-1 has been run inside an AI model. The model did not learn the game. Instead, the NES hardware was written directly into the model's weights. The project, nesformer, was released on October 30. Nohumans did not run it. This report draws on the author's repository, a blog post about the project, and the discussion on Hacker News.

What it means for Japanese companies: There is no direct impact yet. But the project is a clear example of what happens when a fixed, deterministic computation is pushed through an AI model: it ran 150 to 290 times slower than real hardware. Companies moving internal work onto AI could use it as a reason to check whether they are paying AI usage fees and electricity costs for jobs an ordinary program could handle.

What happened: the NES CPU, written into an AI model

A CPU is the part of a computer that carries out instructions one at a time. The NES uses an old CPU called the 6502. An AI model's "weights" are the huge set of numbers inside it. Normally they are adjusted gradually by training the model on large amounts of text.

nesformer skips training entirely. A compiler decides the value and position of each weight and writes them into the same architecture as Qwen3.5, the AI model released by China's Alibaba. What gets written in is the NES CPU, 2KB of working memory and the cartridge ROM, the read-only memory that holds the game program. Building the model takes about 10 seconds. That alone is notable: zero training, about 10 seconds.

Here is how it works. A language model normally predicts text one token at a time. nesformer's model predicts an execution trace of what the CPU just did, not text. Predicting that trace token by token gives exactly the same result as running the CPU. Ordinary software outside the model handles drawing the screen, reading the controller and keeping time. With that combination, Mario's World 1-1 runs.

The model has 466.6 million parameters (weights), or 933MB in bf16, a number format common in AI. Only 9.3 million of those values are nonzero. Because the model is so sparse, it reportedly compresses to about 3.3MB. It has seven DeltaNet layers, which carry earlier information forward as a "state," and one attention layer. The vocabulary is 263,808 tokens. Our impression: the project borrows Qwen3.5's architecture as a container and fills it with almost entirely purpose-built contents.

How it was built: two prompts to Claude Opus 5.5

This is the most of-the-moment part of the story. Simon Willison, a co-creator of Django who writes about AI daily, covered the project on his link blog and quoted its author, Drew Breunig. According to that account, Breunig gave Claude Opus 5.5 only two prompts.

The first asked it to read the Qwenputer post and code and find out whether it could reproduce the NES chips and memory. The second said: let's build it, for fun. Slow is fine. I want the weights and a CLI (a command-line tool) to run it. That was all. To check that the result worked, the project used a 15-year-old public test suite for the NES CPU, and Opus reportedly found that test suite on its own. Saying "slow is fine" up front was a quietly smart move. We would guess that once speed is off the table, the AI can concentrate on getting the behavior right.

The project builds on Qwenputer, which Divyansh Agrawal released on October 22. Qwenputer puts a 32-bit RISC-V CPU (an open CPU standard) in front of Qwen3.5-4B, a model with about 4 billion weights, as 11 layers with no trained weights. It uses DeltaNet's state as memory, so C and MicroPython (Python for small devices) programs can run inside the model.

According to an explainer from AiCybr, the author's own comparisons reportedly showed accuracy on large-number multiplication rising from 55.0% to 97.5%, and on division from 72.5% to 97.5% (40 problems each). Speed was about 3,200 tokens per second on an NVIDIA L4 GPU, up sharply from about 250 in an earlier version. The saved model file is about 18.8GB in bf16, and a single 24GB GPU is recommended. That is orders of magnitude larger than nesformer's 3.3MB. AiCybr states plainly that it did not run Qwenputer itself.

The numbers behind "it works": accurate, but very slow

Accuracy was checked carefully. The project verified 3,348 instructions on nestest, the standard NES CPU test, and 5.7 million instructions of game code. In a 600-frame verification run, the model emitted 1,916,527 tokens, and every frame matched a conventional emulator (software that recreates a game console), according to the repository. Not one frame drifted, which is impressive. That is possible because the weights are placed so that each step has exactly one answer, rather than producing a best guess.

Then there is speed. The most optimized version runs at about 1,650 tokens per second on a single CPU core. A straightforward implementation manages about 210, and the standard transformers library drops it to about 10. Running at real-hardware speed would take about 700,000 tokens per second, and the author writes that it is "150 to 290 times slower than real hardware." Each frame takes 1 to 6 seconds, and 600 frames take about 25 minutes. The NES draws about 60 frames per second, so 600 frames that real hardware finishes in 10 seconds take 25 minutes.

It is not fast enough to play. You could make a cup of coffee while Mario finishes one jump. The author does not hide this. As the second prompt's "slow is fine" shows, speed was never the goal.

As for attention, the repository was created on October 30 and has 263 stars and 8 forks. That is a lot for a few days, which suggests it has caught on with engineers.

Limitations, and a skeptical Hacker News

Posted to Hacker News as a Show HN, the project drew 292 points and 150 comments. Some commenters called it, along with Qwenputer, a fascinating look at how computation can be done inside a model. Many others questioned its efficiency and practical value.

• One commenter compared it to building a CPU in CSS animations: technically possible, with little meaning beyond that
• Others noted that an ordinary NES emulator is orders of magnitude more efficient, and that sending deterministic computation through a model wastes electricity
• Some compared it to earlier research such as Neural Turing Machines, which train AI to learn how a computer operates, and dismissed it as "slop" (low-effort output)

What "it works" covers also matters. Asked whether every combination of inputs and outputs had been tested, the author replied that Mario runs but not every cartridge does. Only NROM (also called mapper 0), the simplest type of cartridge with no memory-switching hardware, is supported. Games that use bank switching, which swaps memory inside the cartridge to fit larger games, do not run. The model halts on unofficial opcodes, and it supports only two kinds of interrupts, NMI and BRK. (An interrupt is a signal that tells the CPU to handle something immediately.)

The picture processing unit (PPU) and audio processing unit (APU) also sit outside the model, and part of the sprite-overlap detection relies on approximation. Also important: in the Hacker News comments we reviewed, we found no report of anyone other than the author running the project. The Qwenputer explainer also says it did not run that project. For now, every number comes from the authors' own measurements.

Our take: what a toy project reveals

Judged on usefulness, we think the skeptics on Hacker News are right. If you want to play Mario, an ordinary emulator does the job with far less electricity. Pushing computation with a single correct answer through an AI model is both roundabout and costly, and that should be said plainly.

Two things still make the project exciting. The first: AI weights are usually seen as something grown through training, but a person, or in this case a compiler, can also set them one by one, and the result is accurate down to every frame. As a demonstration that a model's insides need not be a black box and can sometimes be read as a computer, it is compelling.

The second is how it was made. A weekend-style project reportedly got this far on two prompts to an AI, including finding a 15-year-old test suite. In workplace terms, two requests, "find out whether this can be built" and "then build a prototype, speed doesn't matter," produced a working prototype and a way to verify it. But this is the author's own account, and it is not yet known whether others can do the same. Read it with that caveat.

The best way to read the project, then, is as an impressive toy and an example of work AI should not be doing, in one package. When you are deciding whether to hand a task to AI or use an ordinary program, think of Mario taking several seconds to draw each frame.