Give a large model 40 big-number multiplication problems, no tools allowed, every step must be exact. Original Qwen3.5 (4B parameters) gets 22 right. With a CPU installed: 39. With real Python: 40.
That CPU isn't outside the model. It lives in the model's weights.
In late October, developer Divyansh Agrawal open-sourced Qwenputer: 11 layers prepended to Qwen3.5's 4B parameters, and together those 11 layers form a 32-bit RISC-V CPU. Not a single step was trained—every weight was computed by a compiler and filled in directly, and Qwen's original weights were untouched. Loading still uses Qwen's own standard model class, not a new architecture.
Parts Qwen already had
A CPU needs two things: memory that stores numbers exactly, and circuits that compute exactly. Qwen happens to have both—it just had never been used this way.
- Memory: the Gated DeltaNet state matrix. In Qwen 3.5's linear attention layers there's a continuously running state whose delta-rule job is "remember the new, fade the old." Qwenputer sets gate and write strength to 1 and aims keys at a single row—at that point the state's behavior changes: writing a row exactly overwrites it, no forgetting, no cross-talk. Each row becomes a memory cell. The matrix built for remembering is repurposed as RAM.
- Circuits: feed-forward layers. The compiler translates each CPU instruction into a combination of table lookups and additions; the FFN weights are that lookup table.
- Slow. One calculator call takes 0.5–1 second on an L4 GPU—and that's with the author's acceleration (Triton version at 3,200 execution tokens/sec, fused version 5,500).
- Big. Model file grows from 9.3 GB to 18.8 GB (the README's own figure is 14.65 GB merged; the extra weights are almost all zeros, so download size stays close to the original—the bloat is sparse).
- Needs a boot driver. Without it, the CPU won't start.
How does Qwen "call" this CPU? Through its own trained tool-call format. The model writes a calc tool-call block as it normally would—except nothing external actually executes; the computation happens in the weights. At generation time, an external driver loads CPU firmware into the DeltaNet state and boots the CPU to its start position; the CPU's execution trace tokens are consumed before Qwen's own layers, so they don't pollute Qwen's text behavior. Benchmarked, Qwen's text distribution differs from the original by only KL 6e-4, against a noise floor of 5e-4—install a computer, and the chat feel is unchanged.
Same recipe, smaller scale
The method doesn't depend on model size. Compiling an 8-bit toy CPU the same way into a 4-layer mini network (8,362 non-zero weights), 1,000 random programs—over 1.16 million instructions—matched a reference interpreter one by one. An easter egg: change just the register table's gate from 1 to 0.999—forgetting one-thousandth per cycle—and 13 × 11 evaluates to 132. Between exactness and error sits 0.001.
The author's 11 layers were also tested alone: 123456789 × 987654321 generated 1,111 tokens, and a C CRC-32 program generated 6,283 tokens, each matching the reference machine instruction-for-instruction, with results identical to Python. The author's own replay was harsher: 230,000 output positions checked against the reference machine, zero mismatches.
The costs
What Hacker News argued about
On October 29, Qwenputer hit the Hacker News front page: 697 points, 145 comments. The most technically rigorous critic was user gcr: after praising "Really cool work," he pointed out that the "no external runtime" claim needs an asterisk—firmware loading, booting the CPU to its start state, and compiling/loading the program to run are all still done by a custom host runtime; during execution, that same runtime manually skips Qwen's own layers so only the CPU layers run. He hoped the author would be more candid about these limitations.
The author's October 20 actions read as a kind of response: a firmware bug was fixed (large-number registers weren't zeroed at the start of each call, so consecutive calls inherited dirty registers), and the claim "has never printed a wrong result" was removed from the README's RISC-V section—the CHIP-8 legacy section kept it; only the new version's was deleted.
Imitators have arrived
On October 30, Drew Breunig open-sourced nesformer: using the same compilation approach, the NES's 6502 processor, 2 KB of memory, and a cartridge program ROM were compiled into original Qwen3.5 weights—196 stars in one day. The community has gone further: someone ran Doom's E1M1 map on the in-weights RISC-V, and others are pushing toward RV32IMA with the goal of running Linux inside.
Where this sits
The previous narrative was models absorbing external scaffolding—tools, retrieval, orchestration, layer by layer folded into the model's own capabilities. Qwenputer is the most aggressive step on that road: even the CPU got eaten. But gcr's comment points out the other half—the thing that loads firmware, boots the CPU, and skips layers is still the runtime outside the model. It didn't disappear; it just renamed itself *driver*.
As for the distance between exactness and forgetting: 0.001. Gate set to 1, the in-weights CPU never gets a bit wrong; set to 0.999, and 13 × 11 becomes 132.
---
*Qwenputer: github.com/divagr18/qwenputer (326 stars); model: huggingface.co/divagr1925/Qwen3.5-4B-Qwenputer; nesformer: github.com/dbreunig/nesformer. Benchmark figures come from the repo README (DeepMind mul_big, greedy decoding, 40 problems); measured data is from this post's reproduction and the author's replay.*