Claude Opus 5.5 compiled a Nintendo's CPU into Qwen weights in two prompts, and it runs Mario 150 times too slow

A day after we wrote about Qwenputer, the project that compiled a RISC-V CPU into the weights of a stock Qwen 3.5 model, someone has used the same trick to put a Nintendo Entertainment System's CPU into a Qwen checkpoint. nesformer, published on October 30 by Drew Breunig, runs the NES's 6502 processor, its 2 KB of work RAM and a cartridge's program ROM inside a Qwen3_5ForCausalLM model. Nobody trained the weights. A compiler computed them, and the model plays a game by predicting the CPU's execution log one token at a time. The README shows Super Mario Bros. World 1-1 running this way.

The more interesting part is how it got built. In the Hacker News thread, Breunig says Claude Opus 5.5 produced the working weights and code from two prompts. The first asked it to read the Qwenputer write-up and code and work out whether an NES could be emulated with the technique, and how big and how fast the model would need to be. It answered with charts showing any version would be slow. The second was, roughly, "build it anyway, it's okay if it's not fast."

Breunig doesn't credit the model alone. He calls it "a surprisingly well-structured challenge": Qwenputer's compiler did the weight-writing, which he calls "essential", and the NES emulation community has spent decades producing conformance tests. Opus found one of them, nestest, with a golden log of more than 3,000 instructions, and built against it. Agents tend to do well when there's a spec, a reference implementation and a test that says pass or fail. This is a vivid case of that.

What's in the checkpoint

The weights load with from_pretrained and need no custom code. Like Qwenputer, nesformer uses the model's Gated DeltaNet layers as memory: with the gate held open and one-hot keys, each token's update overwrites exactly one row of a head's 128×128 state matrix, so rows become memory cells for the cartridge, RAM and registers. Seven DeltaNet layers form the circuit, with an eighth, all-zero attention layer there only because Hugging Face's cache expects one. The model has 466.6M parameters, of which 9.3M are nonzero, which is why the weights compress to 3.3 MB.

Not everything is inside the model. A small host program draws the picture (the PPU is a scanline renderer outside the weights), reads the controller, fires the vblank interrupt and answers I/O reads by injecting tokens. There's no sound. Only NROM cartridges work, the simplest board without bank switching, so Super Mario Bros. and Donkey Kong run and most later games don't.

The checking is thorough for a hobby project. The free-running weights produced traces identical to a reference 6502 over runs of up to 2.6 million tokens, and every saved frame matched a conventional emulator.

How slow

Very. The optimized engine runs about 1,650 tokens a second on one CPU core. A real NES would need about 700,000. Even after skipping most of the idle loops games spend waiting for vblank, nesformer is 150 to 290 times slower than the console, and a frame takes 1 to 6 seconds. Through stock transformers it manages about 10 tokens a second.

That number is the useful corrective here. One HN commenter imagined compiling whole VMs into model weights so agents wouldn't need external tools; another pointed out that the speed gap shows how much compute separates an LLM from an ordinary program. Both reactions fit. Compiled weights are a real, verifiable technique, and now a portable one, since porting it to another CPU took two prompts. They are also, for now, a very expensive way to run a 1980s game console.