Nesformer Compiles an NES Processor Into a Qwen-Style AI Model

Nobody trained nesformer. Its creator, Drew Breunig, used a compiler to calculate every weight in a model built on the Qwen3.5 architecture, so that the model behaves exactly like the processor inside the Nintendo Entertainment System of the mid-1980s. Released on GitHub on 30 October under the MIT licence, nesformer loads like any other checkpoint in Hugging Face’s transformers library and plays NES games by predicting the processor’s next step, one token at a time.

It is a toy, and an openly slow one, but it makes a serious point about what the numbers inside a language model can be. Most models get their weights from training on huge amounts of data. Nesformer shows that the same file format and the same architecture can hold a hand-built, exactly checkable program instead.

What compiled weights mean in plain English

A trained model learns its weights by trial and error, adjusting billions of numbers until its guesses improve. A compiled model skips that. The nesformer README says “Nobody trained these weights; a compiler computed every one”. Breunig worked out, mathematically, which numbers would make each layer perform one specific job, such as decoding an instruction or adding two bytes.

The trick that makes this possible comes from Qwen3.5’s Gated DeltaNet layers, which carry a grid of numbers from one token to the next. Nesformer treats each row of that grid as a memory cell, so the console’s memory, its registers and the game’s code all live inside the model’s running state. When a game plays, the model writes out the processor’s execution log token by token, and a small host program reads that log to draw the picture and handle the controller.

Breunig credits the idea to Qwenputer by Divyansh Agrawal, which compiled a CHIP-8 and then a RISC-V processor into Qwen3.5-4B, and he reuses its compiler. Announcing the project on X, Breunig, who lists himself as Bay Area-based, wrote: “I used Divyansh’s approach to build an entire Nintendo into ~1GB of Qwen3.5 weights.” In a reply he said he had given Anthropic’s Opus 5.5 “two prompts”, one to judge whether an NES model was feasible and one to build it.

What runs in the model, and what does not

“Entire Nintendo” overstates it, and the README is careful about where the line sits. The model holds the 6502 processor core with all 151 official instructions, 2 KB of working memory and 32 KB of game code. The picture processing unit that draws the graphics, the palette, the controllers and the frame timing all run in ordinary Python on the host. There is no sound, and only the simplest cartridge type (NROM, mapper 0) is supported.

The checkpoint is large but almost empty. It has 466.6 million parameters (933 MB), of which only 9.3 million are nonzero, so the weights compress to 3.3 MB. On one CPU core the fastest engine manages about 1,650 tokens a second, and stock transformers about 10. A real NES would need roughly 700,000, so nesformer runs 150 to 290 times slower than the console, at one to six seconds per frame.

The checks are strong but specific. For the bundled test programs, nestest and two freely licensed homebrew games, Full Game and Thwaite, every saved frame matched a conventional 6502 emulator exactly. Super Mario Bros. appears in a demo animation, but the frame-for-frame match is claimed only for the bundled games. No commercial game ships with the project: users supply their own ROM.

A program you can audit, written in a model’s own format

Nesformer will not change how anyone plays games, and it says nothing about whether trained models can reason. Its interest lies elsewhere: it shows that the weights of a mainstream architecture can encode a deterministic program that is checked against a reference, token for token. That is the opposite of the usual problem with AI, where nobody can say exactly why a trained model produced a given answer.

That matters for the growing work on smaller and more specialised models. TSN has covered models that loop the same block of layers to trade compute for quality, models that answer in a single pass, and compact agents such as Microsoft’s 4B Mage-VL-Cowork. Compiled components point to a different kind of hybrid, in which some parts of a model are learned and others are exact, readable circuits. The README’s own numbers show the cost: a 466-million-parameter file doing work a 1980s chip does far faster. For anyone unsure where this fits among machine learning, deep learning and LLMs, the answer is that it borrows a language model’s shape without its learning.

It also shows how quickly these ideas now move. Qwenputer went up on GitHub on 19 October, 11 days before nesformer, and Breunig says a coding model did much of the build from two prompts. Claims of the “AI became a Nintendo” kind will spread faster than READMEs, so the useful habit is to check what sits inside the weights and what the host quietly does.

The next test is in the README’s limitations list: supporting bank-switching cartridges, which would let most of the NES library run and would require storing a whole game ROM inside the model’s state.

Sources

• nesformer on GitHub (Drew Breunig; README, licence and test-ROM sources)
• Drew Breunig on X, 30 Oct 2026
• Drew Breunig on X, reply on how it was built, 30 Oct 2026
• Qwenputer on GitHub (Divyansh Agrawal)
• Spotted via @RoundtableSpace on X

Related stories

• NVIDIA Releases Nemotron Labs Dory1.0-4B Looped Open-Weight Model
• Microsoft Open-Sources Mage-VL-Cowork, a 4B Agent That Clicks or Codes
• Small Open Models That Answer in One Pass: Liquid AI’s d1 and Perplexity’s pplx-embed-v2-late

Image: Evan-Amos / Wikimedia Commons, public domain, modified by TSN