Qwenx86-4B (compact)

▶️ See it in action: Qwenx86 Debugger Space. Walk through actual recorded tool calls: the conversation, x86 registers and flags, code at the program counter, RAM and machine output, with all verified blocks on a timeline.

Qwen3.5-4B with a 64-bit x86 computer compiled into its weights: 13 transformer layers ahead of Qwen's own. There are no learned weights in them; all of their weights are computed by a compiler. Qwen invokes the computer through its own tool calls (<tool_call>), and the computer in the weights executes the tool. Calculator, Python, C compiler, notes store, physics/chemistry lookup and Python-docs lookup are all firmware in the checkpoint. This is the compact checkpoint: ~9 GB GPU memory, so it fits on a 16 GB GPU.

v2 adds Qwenx86 memory on the same weights: a filesystem, 1,000-fact store, 50,000-token verbatim recall, JPEG images, programmable heads, a search index, exact 64-bit arithmetic and state snapshots (see Qwenx86 memory). Those run beside the model and are driven by host code; the x86 tools run entirely in the weights.

v3 lets Qwen use that memory by itself: in a chat it decides when to save, read, search, list and delete notes, and writes the tool calls on its own (see New in v3).

From Qwenputer: circuit and machinery (see Credits for details)

• The CPU circuit itself. The Qwenx86 core is a fork of Qwenputer's RV32 core (rv/core.py): fetch, ROM, RAM (delta-rule memory cells in Gated DeltaNet state), register file, branches, multiply/divide and bignum unit, designed by divagr1925.
• The compiler that converts the circuit to Qwen3.5 layers. Tool-call bridge. Chat loop. State injection. Merge layout. MicroPython build.

New for Qwenx86

• x86 in the core. Added x86 flag micro-ops (FADD, FSUB, FAND, FOR, FXOR, FINC, FDEC) and conditional jumps (JCC with the x86 condition table) to the forked circuit. Added a translator from x86-64 to the core's 32-bit ops (64-bit values as register/RAM halves, flags rebuilt per instruction, bridge ports, a single shared return dispatch).
• Memory map. 64 KB RAM (the circuit grew from 11 to 13 layers). Read-only data wired to the x86 path.
• Firmware and tools. All firmware (calc, the qcc C compiler, notes, science and python_doc stores, an x86 machine that decodes raw x86 bytes with SSE and interrupts). Code to patch the MicroPython build into a tool. Baking the firmware into the checkpoint.
• Running. Compact 16 GB loader. Block verification.
• v2 memory. Named files, facts, word-for-word recall, images, functions, a search index, exact arithmetic and saved reading state, all on the released weights.

My previous projects (neural-n64, neural-x86-doom, neural-riscv) demonstrated what it takes to exactly emulate a real CPU. This model does it in the weights of a language model.

Qwenputer vs Qwenx86

What's in it

Tools Qwen calls (all answered by the computer in the weights)

Qwenx86 memory (new in v2)

v2 gives the model a memory it can write to and read back exactly: named files, a store of facts, long documents recalled word for word, images, small functions, a search index, exact arithmetic, and saved reading state. It uses the same weights as v1 (nothing retrained or re-merged); the code is in qwenx86/memory/. Every result below was measured on these weights, from this folder.

How to use it: v2/README.md.

How it works, and what it is not:

• Where the memory lives. Each of four of the model's layers (13-16) gets extra memory slots of the same kind the layer already uses (DeltaNet state). Ordinary text can't write to them or wear them down, so Qwen's own answers are exactly the same whether the memory is full or empty.
• What is not in the weights. The extra slots are run by code alongside the model, not stored as new weights. Finding a file by name (hashing it, comparing names, stepping through the directory) is also ordinary Python. So unlike the x86 tools above, which run entirely inside the model, the memory is driven from outside it, and in v2 you use it through Python calls (v3 adds a chat where Qwen calls it itself).
• How text comes back out. Stored text is printed through the model's own final layer: each stored token is turned into a signal the output layer turns back into that same token.

Notes: the arithmetic tables come from the author's Zen2 work and ship as model/atoms.safetensors (60 KB). The image features use Qwen3.5-4B's own vision encoder, loaded separately, because this checkpoint is text-only. Background reading: docs/state_writes.md (why writing to this kind of memory doesn't need a full model run) and docs/d1_trace.html (every table lookup behind the arithmetic results, checked by an independent program, 0 mismatches).

New in v3: Qwen uses its memory itself

In v2 you drive the memory from Python. In v3, Qwen does it: in a chat it gets five memory tools (save, read, search, list, delete), decides when to use them, and writes the tool calls itself. Python carries out each call and hands the result back, the same way the v1 tools answer. The memory is saved after every message, so it is still there in the next chat. Same weights as v1 and v2; nothing retrained.

A real chat on the released model:

you> Remember that my locker number is 412. Save it in your memory.
  [memory_save {"name": "locker_number", "text": "412"} -> saved]
qwen> Okay, I've saved your locker number as 412.
you> What is my locker number? Check your memory.
  [memory_read {"name": "locker_number"} -> 412]
qwen> Your locker number is 412.

Every tool in one chat. python -m qwenx86.mixed offers all eleven tools at once: the six v1 tools, run by the computer in the weights, and the five memory tools, run by Python. Qwen picks; the chat sends each call to the right place. A v1 call still runs inside the model with every machine token checked against the reference, exactly as in v1.

All 8 right, each call went to the tool Qwen named, and 0 of 581,205 machine tokens differed from the reference.

How to use it: v3/README.md.

The tests

Is the model still Qwen?

• Text match vs stock Qwen3.5-4B. 3 normal text prompts (48 token positions) run through both stock Qwen and Qwenx86. The most likely next token is the same at each position (48/48). The distributions have a KL divergence of 4.1e-4; the layer widening alone is ~5e-4. So the computer layers don't change Qwen's own behavior.
• Text logits with memory loaded. Qwen's text logits differ by exactly 0.0 between notes/store state loaded and empty. No leakage of computer state into Qwen's text.

Is the CPU a proper x86-64 CPU?

• Instruction coverage (2,000 cases). 4 generators from my Zen2 research: general instructions, 2-byte opcodes, multiply/divide, string. 500 cases each. Each case runs on our core and on Unicorn (a real x86-64 emulator) in lockstep. All 16 registers and all flags x86 defines must be the same after each instruction. 2,000 / 2,000.
• Compiled C programs. MSVC-compiled C programs (hello, a small library with string/sort routines, a program with recursion/multiply/divide/hex print) run on our core and on Unicorn. Printed output and registers after each instruction are the same.
• Through the compiled circuit. The same programs run through the actual transformer layers (not just the reference), token by token: hello 386, lib 16,370, prog 358,501 tokens, 0 wrong each.
• 64 KB RAM. A program that fills and reads back the upper 32 KB (new in this model) prints the same checksum as on Unicorn.

Do the firmwares compute the correct answers?

• calc. 125 expressions (random arithmetic + GSM8K-like steps with decimals). Exact fraction arithmetic. Same firmware on Unicorn. 0 wrong.
• python. 9 programs through the bridge: 2**100, sums, list comprehensions, recursion, an error traceback, strings, a 3-part #more program. Correct output in chat framing.
• c (qcc). 10 programs: sum of squares, recursive Fibonacci, prime counting, strings, pointers, unsigned long long, divide by zero, a syntax error, a too-long call, a 3-part //more program. Each output is as expected AND the same as the same firmware on Unicorn.
• notes. 10 operations: save, replace, case-insensitive get, search, no match, not found.
• science. All 647 records looked up by name: 647/647 exact. 849 natural queries: correct record first 98.0% of the time (the word-overlap ceiling). The firmware's answer is the same as a Python copy of its algorithm for all 1,496 lookups.
• python_doc. All 1,003 records looked up by name, decompressed byte-exact: 1,003/1,003. An unknown name answers "not found".

Does it work as a chat on real weights?

• Live chats on a 16 GB card (compact checkpoint, computer booted from the baked firmware, block verify): Qwen wrote the tool call, the machine executed it, and Qwen replied based on the result. 0 lock errors in all cases. These are the runs shown in the Space; times include recording the debugger frames.

• Notes across processes. Save notes in one process, write the machine state to disk, boot a new process from it. All 3 notes found.
• GSM8K with calc (first 28 test questions, greedy). 26/28 with the calc tool, 23/28 with just Qwen. 31 calc calls, 2.2 M machine tokens, 0 lock errors.
• Speed. A C chat (168,578 machine tokens): 582 s token by token, 44.5 s with block verify (13x).

Screenshots

All runs from the Space, at the end of the run.

Run it

Needs a CUDA GPU with 16 GB of memory (the model uses ~9 GB, plus room for the run), Python 3.12 and the packages from requirements.txt (PyTorch with CUDA, transformers==5.22.1).

pip install -r requirements.txt
python -m qwenx86.run --tool calc    "What is (1200 - 350) / 5? Use the calc tool."
python -m qwenx86.run --tool c       "Write a C program that prints 2 to the power 40. Run it with the c tool."
python -m qwenx86.run --tool python  "What is 2 to the power 100 exactly? Use the python tool."
python -m qwenx86.run --tool science "What is the Avogadro constant? Use the science tool."
python -m qwenx86.run --tool pydoc   "What is the signature of math.gcd? Use the python_doc tool."
python -m qwenx86.run --tool notes   "Save a note called bike. The bike lock code is 7193."
python -m qwenx86.run --tool notes   "What's the code for my bike lock? Check your notes."

Run from this folder. The model loads in ~25 s. The transcript goes to stdout; the summary (machine tokens, verified blocks, lock status) goes to stderr. The notes tool stores its memory in ./qwenx86_notes/.

The v2 memory checks (results and saved state go to ./qwenx86_memory/):

python -m qwenx86.memory files save
python -m qwenx86.memory files load
python -m qwenx86.memory facts save
python -m qwenx86.memory facts load
python -m qwenx86.memory verbatim
python -m qwenx86.memory arithmetic
python -m qwenx86.memory images save
python -m qwenx86.memory images load

python -m qwenx86.memory lists them all; how to use the memory is in v2/README.md.

v3, a chat where Qwen uses the memory itself, and one chat with every tool (v3/README.md):

python -m qwenx86.memory chat
python -m qwenx86.mixed

Files

Limits

• Code per tool call: ~60 tokens per part (the bridge captures 80 tokens of a tool call). Longer programs go in //more / #more parts (up to 3,000 chars).
• The x86 translator has no indirect jumps and no hardware SSE (x86vm does SSE in software, but is not shipped as a tool). The python tool is Qwenputer's minimal MicroPython build (e.g. no slice steps, a small heap).
• Long runs: the longest local chat was 814,561 machine tokens (science, "atomic mass of iron", 202 s); machine tokens skip Qwen's layers, so they don't fill Qwen's KV cache.
• Memory (v2): it runs alongside the model and is driven by Python code, not by the model itself. File names are at most 6 tokens.
• Memory chat (v3): qwenx86.memory chat offers only the memory tools; qwenx86.mixed offers every tool. With both note systems available, name the tool you want, or Qwen picks one.
• Speed: the machine makes 1 token per step. Block verify batches the checks, but a C compile + run is 0.1–6 M machine tokens.
• x86 decoding: programs are translated to core ops before running. Raw x86 bytes are decoded by firmware, not by circuit layers. Qwenputer also stores RISC-V code pre-decoded.
• Qwen's text: Qwen3.5-4B's text, unmodified, and not trained on these tools. It sometimes restyles a tool's value in its answer (e.g. 6.02214076e+23 -> 6.02214076 × 10²³).

Credits

• Qwenputer by Divyansh Agrawal (@divagr1925, github.com/divagr18/qwenputer, MIT) is the base of this model. From Qwenputer:
  • chipformer: the compiler that converts the circuit to Qwen3.5 layers (q35 IR, emitter, primitives). Included here unmodified, MIT license (chipformer/LICENSE).
  • The RV32 core (chipformer/rv/core.py), with delta-rule memory cells, ROM, DROM and the bignum unit. Qwenx86's x86 core is a fork of it (+ x86 flag uops, conditional jumps, 64 KB RAM).
  • The tool-call bridge (rv/bridge.py): captures <tool_call>, runs the machine, echoes the output to the chat. The reference Session for checking all tokens.
  • The chat loop (rv/chat.py, RvChat). HF emission/state injection (rv/hf.py). The merge layout (rv1). The circuit executor. The nonzero block compaction idea (q35/fast.py).
  • The MicroPython build (mpy-s1.elf, from Qwenputer's tests). We patch it word by word into the python tool.
  • v2 memory: the design of the file store follows Qwenputer's filesystem (divagr1925/Qwen3.5-4B-Qwenputer-Filesystem): how tokens are packed into memory slots, how names are found in the directory, the size limits, and keeping Qwen's own layers untouched while the memory is used. The code that runs it on Qwenx86, the printing and the tests are our own.
• From my previous work: the x86-64 reference and atoms from my Zen2 research, and lessons from neural-n64, neural-x86-doom and neural-riscv.
• Model weights: Qwen/Qwen3.5-4B (Apache-2.0). Qwen's own weights are unmodified. Data: NIST CODATA / scipy.constants (public domain), periodictable (public domain), CPython docstrings (PSF license). Unicorn was used as the x86 reference for tests.

Citation

If you use this model, please cite this model and Qwenputer, which it is based on:

@misc{quazim0t02026qwenx86,
  author       = {Quazim0t0},
  title        = {{Qwenx86}: 64-bit x86 computer compiled into weights of {Qwen3.5-4B}},
  year         = {2026},
  publisher    = {Hugging Face},
  howpublished = {\url{https://huggingface.co/Quazim0t0/Qwenx86-4B-compact}},
  note         = {x86 side from author's Zen2 research. CPU circuit forked from Qwenputer}
}

@software{agrawal2026qwenputer,
  author  = {Agrawal, Divyansh},
  title   = {{Qwenputer}: a computer compiled into the weights of a pretrained language model},
  year    = {2026},
  version = {0.1.0},
  url     = {https://github.com/divagr18/qwenputer},
  license = {MIT}
}

License

The weights are Apache-2.0 (a modified version of Qwen/Qwen3.5-4B, LICENSE-Qwen3.5). We widen the config and add the computer layers, but don't modify Qwen's own weights. chipformer/ is MIT, © 2026 Divyansh Agrawal (chipformer/LICENSE).