OxBee/Qwenx86-4B-compact

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.

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.

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

	Qwenputer	Qwenx86
CPU	RV32IM + Zba (RISC-V) core	x86-64 core: a fork of the RV32 circuit with x86 flag micro-ops and conditional jumps
Programs	RISC-V code	x86-64 integer code from MSVC-compiled C, translated to core ops (the python tool still runs on the core's RISC-V path)
Chip layers	11	13
RAM	32 KB	64 KB
Read-only data	128 KB	128 KB, also wired to the x86 path
x86 decoder, semantics, tests	none	from my Zen2 research; 2,000/2,000 lockstep cases vs Unicorn
Tools	calc and MicroPython (RISC-V builds)	calc, python (Qwenputer's MicroPython, patched), c (qcc), notes, science, python_doc, all baked into the checkpoint as boot states
Running	chat loop with the chip layers per token	same loop + compact 16 GB loader + block verify (up to 256 machine tokens per pass)
Shared base	compiler (chipformer), tool-call bridge, chat loop, state injection, merge layout	the same, reused under MIT

What's in it

Part	What it is
x86-64 core	13 chip layers (64 RAM heads, 16-bit program counter). Qwenputer's RV32 circuit, forked, with x86 flag ops, conditional jumps and 64 KB RAM added. x86 decoding, semantics and tests from my Zen2 research. Runs the integer instruction set used by compiled C: 8/16/32/64-bit ALU (incl. ADC/SBB), shifts, rotates, MUL/IMUL/DIV/IDIV, MOVZX/MOVSX, SETcc/CMOVcc, BT/BTS/BTR/BTC, BSF/BSR, string ops with REP, calls and returns. Verified against Unicorn on 2,000 lockstep cases: all registers and flags after each instruction. MSVC-compiled C is translated once into the core's own ops.
Memory	64 KB RAM, 256 KB code ROM, 128 KB read-only data. All in the model's Gated DeltaNet state.
Firmware in the checkpoint	6 boot states (model/boot/*.safetensors). Each loads a tool's entire machine (code, data, registers, PC) from the checkpoint. No program loading on the host side.
x86 machine firmware	x86vm (in the dev tree, not shipped as a tool in this release). Decodes raw x86-64 bytes at run time. SSE doubles in software (bit-identical to a real SSE unit on 3,200 random ops). Interrupts (IDT, INT n, IRETQ, STI/CLI, HLT, timer). Ran hello for 1.44 M tokens through the compiled circuit, 0 wrong.

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

Tool	Firmware	Notes
calc	exact rational calculator in C (+ - x / parens decimals)	GSM8K (first 28 test questions): 26/28 with calc vs 23/28 plain Qwen
python	MicroPython (Qwenputer's prebuilt RISC-V build, patched to read the tool call)	one-line expressions print their value; long programs in #more parts
c	qcc, a small C compiler + runner for this core	int, char, unsigned, long, pointers, arrays, functions, recursion, if/while/for, printf; long programs in //more parts
notes_put / notes_search / notes_get	notes store in machine RAM	no host routing; the notes are the machine's saved state
science	647 CODATA constants, unit conversions and the periodic table (NIST / scipy.constants), inverted index in read-only data	exact recall 647/647, retrieval@1 98.0%
python_doc	1,003 Python API signatures + docstrings, grammar-compressed (204 KB -> 110 KB) in read-only data	exact recall 1,003/1,003

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.

Chat	What happened	Machine tokens	Time
calc	(1200 - 350) / 5 = 170	56,667	41.0 s
python	2**100 = 1267650600228229401496703205376	39,526	46.8 s
c	Qwen wrote a C program that prints 6 * 7. Compiled and executed: 42	169,293	71.2 s
notes	1) "save a note called bike..." saved. 2) Same chat: "what's the code?" -> 7193	117,746 + 74,798	81.6 s
science	Avogadro constant: 6.02214076e+23 mol^-1	402,834	128.9 s
python_doc	math.gcd signature: math.gcd(*integers)	55,684	44.3 s

• 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/.

Files

Path	Contents
model/compact.safetensors	compact weights (8.75 GB): all maps' nonzero rows x columns
model/boot/*.safetensors	baked machine states for the 6 tools
model/*.json, tokenizer	config, chipformer.json (merge layout), Qwen tokenizer
machines/*.pkl, tools.json	reference parked machine for each tool (checks all tokens), tool schema
qwenx86/	runtime: loader, x86 core circuit, uop machine, block verify, CLI
chipformer/	Qwenputer's compiler and RISC-V core and tools (MIT, Divyansh Agrawal)

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).
• 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.
• 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).