How did someone fit a computer inside a language model?

Qwenputer is a language model with a small computer built into its weights. Developer Divyansh Agrawal took Qwen3.5-4B, an open model from Alibaba's Qwen team, and added 11 layers that work as a 32-bit RISC-V CPU. Nobody trained those layers. A compiler calculated every weight, the way you would wire a circuit. The CPU stores its memory in a state the model already keeps while it reads, so when Qwen asks for a calculation, the answer is computed inside the model rather than guessed.

Agrawal announced it on X on October 28, 2026, and published the code on GitHub and the weights on Hugging Face and ModelScope.

Why would a language model need a computer?

A language model writes one token at a time, each a prediction of what comes next. That works well for prose and surprisingly well for short sums. For a long multiplication like 123456789 × 987654321, every digit is a prediction, and one slip ruins the answer.

The usual fix is a tool. The model writes a request, a program outside the model runs it in Python, and the result is pasted back into the conversation. That is reliable, but the arithmetic happens somewhere else. Qwenputer asks a stranger question: could the exact machine live inside the network itself?

Compiled, not trained

Most neural network weights are learned. You show the network examples and nudge millions of numbers until its outputs improve. Qwenputer's computer layers skip that. The README says none of their weights are learned, because a compiler computes every one from a description of the circuit.

The CPU is RV32IM, a standard 32-bit RISC-V design with integer multiply and divide, plus an extension and a coprocessor for very large numbers. The README says it passes the official riscv-tests suites. Its 11 layers sit in front of Qwen's 32, and the README says Qwen's own weights are unchanged.

The RAM was already there

A computer needs memory, and Qwen3.5 already keeps some while it reads. It mixes ordinary attention layers with a newer kind called Gated DeltaNet. Each DeltaNet head carries a state matrix that it updates at every token using the gated delta rule. That rule has two knobs, a gate (written α) that controls how much old state fades, and a write strength (β).

In the computer's heads, the gate is held fully open, so nothing fades, and the write strength is 1. Each key is a one-hot vector, all zeros except one position, so it points at exactly one row. An update then replaces that row with the new value and leaves every other row alone. That is a RAM write. Reading is the same head's query. A one-hot query returns exactly that row.

The README fills in the layout. The low bits of an address choose a head, the rest choose a row, and each row stores one byte. Registers, the program counter and the call stack get heads of their own. Even the gate earns a job. Setting it to 0 for one token wipes a whole head, and setting it to one half makes a head halve itself at every step, which the circuit uses as a counter.

Every token is a clock tick

Writes arrive through the stream of tokens the model generates. An ADDR token names a memory row, the VAL token after it carries the value, and STEP ends the instruction. A few tokens make one instruction. So the stream of special "trace" tokens is the machine's execution log, and the model is running a program by writing it out, step by step.

Choose a row, play the trace, and drag sideways to turn the matrix.

How Qwen asks for a sum

Qwen3.5 was already trained to call tools in a fixed format. Qwenputer piggybacks on that. Qwen writes a <tool_call> for a calculator exactly as it would for any tool. The computer layers read the call, run the calculator program on the CPU, and the model itself writes the <tool_response> with the answer, digit by digit. Qwen then reads the result as if it had written the number itself. The calculator program is firmware written in C, according to the design notes.

We have simplified one thing. The README says no runtime, sandbox or tool executor is involved, and that every token comes from the weights. In practice the author's RvChat driver loads the calculator program into the model's memory after the prompt and keeps the trace tokens away from Qwen's own layers. The design notes also describe a faster executor that runs the computer layers' arithmetic directly, checked against the model's layers. That's fair for a research demo, but there is still some careful plumbing around the weights.

Scrub through one illustrative calculation.

The model didn't learn to do math

The tempting reading is that Qwen got better at arithmetic. It didn't. Qwen still writes the request, and the README says its text behavior matches the base model's closely. What changed is that an exact machine sits in front of it, inside the same file, ready to do the part that should never be a guess.

What about MicroPython?

The announcement and README say the CPU runs C and MicroPython inside the model's forward passes. That is the author's claim, and the design notes add a qualifier. MicroPython has run on the standalone CPU and its executor, but "not yet inside the merged model". That needs another bridge build. The released merged model ships the C calculator.

Does it actually help?

These are the author's own results, with greedy decoding and 40 problems per set. Base Qwen got no tools and an instruction to do every step exactly. The Python column is base Qwen calling a real Python interpreter on the host.

The author also replayed about 230,000 of the computer's output positions through a reference model of the machine and reports zero mismatches. Forty problems is a small set, so treat single percentage points as noise. The overall pattern is clear, though. Qwen alone gets about half of the big multiplications right, and with the computer it lands level with the Python tool.

What it can't do

It is slow. The README puts the CPU at about 3,200 trace tokens a second on an Nvidia L4, and a single instruction takes a few tokens. It is big. The design notes give the merged checkpoint as 18.7 GB in bf16, roughly double the 9.3 GB base model, because a stock checkpoint makes every layer the same width.

It also doesn't make the model smarter. For the first version, which used a CHIP-8 machine, the README reports ties on GSM8K word problems, because the hard part there is reasoning, not arithmetic.

People are already building on it

Within two days, others reported their own builds. Drew Breunig (@dbreunig) says he used the same approach to build an entire Nintendo into about 1 GB of Qwen3.5 weights, which he calls Nesformer. His README describes the NES's 6502 CPU, its 2 KB of work RAM and a cartridge's program ROM running inside a stock Qwen3.5 checkpoint, with a small host program drawing the picture and reading the controller.

Yashwanth S.C. (@YASHWANTHSC) reports running DOOM on a Qwenputer-derived neural CPU, reaching one verified 320 by 200 frame after about 28.7 million tokens and 2 hours 21 minutes on an M3 Ultra. His README is careful to say it is a standalone checkpoint without Qwen's language weights, not the Qwenputer model itself, and that real-time play hasn't been achieved.

From delta rules to tool calls

Ask how the delta rule overwrites a row, or open Learnfold's lesson Tools, search, and agents below. For a reminder that confident output still needs checking, see how to check an AI explanation for mistakes. For another system that survives errors by design, see how QR codes repair themselves. And for what happens when one question leads to five, see following a rabbit hole.

Qwenputer is by Divyansh Agrawal (@divagr1925 on X). The code is MIT licensed and the weights are Apache-2.0, on GitHub and Hugging Face.