decomp-synth-lifter-gtp0c-qwen3.8-27b-lora

decomp-synth lifter gtp0c — Qwen3.8-27B LoRA

A LoRA adapter that turns Qwen3.8-27B into a byte-exact decompilation matcher for PowerPC/Xbox 360 MSVC C++. This is the v10 recipe run verbatim on the newer Qwen3.8-27B base: byte-identical training corpus, same LoRA shape, same window — a controlled base-generation transplant, released as a matched pair with its sibling.

The project

This adapter comes out of a campaign teaching fleets of AI coding agents to reconstruct shipped game binaries byte-for-byte — matching decompilation, the console-preservation community's gold standard: rewrite C++ until the original vintage compiler, at the original flags, reproduces the retail machine code exactly. In that campaign, agent swarms byte-matched over 44,000 functions of a stripped retail Xbox 360 binary in about ten weeks — with every proposal judged by the real compiler and objdiff, never by a model.

decomp-synth is the search-and-ML side of that system: an engine that searches behavior-preserving C++ rewrites against the real build, and mines its own verified attempts into training data. The adapters published under this account are the resulting proposer models. The design rule the whole system is built on: models propose, deterministic oracles dispose — a fuzzy match score is a search gradient and an adversary, and byte-exact recompilation is the only terminal judge.

Background reading, in order:

• How agent swarms decompile games byte-for-byte — the campaign, and what byte-exact matching actually demands
• LLM-assisted decompilation: tools, not prompts — why the model is never allowed to judge its own work
• Forking the decompilation toolchain — the compiler, splitter, and diff stack underneath
• Infrastructure for running agent swarms — what running the fleet takes

Model facts

Evaluation

Same instrument and session as the v10 sibling (drift roster r3, 380 rows, k=20, T=0.6, objdiff-cli 4.2.8, none ruler, 2026-08-26 paired scoring):

• 9 / 380 byte-exact solves (raw+reloc equal, fresh-recompile verified)
• best-of-k fuzzy: mean 46.6, median 18.7, 48 rows ≥90, 20 rows ≥99
• compile rate 71.4% of 7,600 draws
• Δ best-of-k fuzzy vs the untouched-tree null: +7.10 (restored method)

Head-to-head vs v10: a statistical tie — paired restored Δ +0.37, 102/92/186 better/worse/tied, sign-test p=0.52. The shape differs: the 3.8 arm moves the distribution up (p25 +3.7, +11 rows ≥10 fuzzy, higher compile rate) while v10 concentrates more byte-exact solves (12 vs 9, with 6 of v10's 12 resting on a single draw of twenty vs 1 of 9 here). Read it as coverage vs depth, not better vs worse. The recipe transplants onto the new base and fully recovers; it does not establish an edge.

How to use it

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel

base = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3.8-27B", dtype="bfloat16", device_map="auto")
tok = AutoTokenizer.from_pretrained("Qwen/Qwen3.8-27B")
model = PeftModel.from_pretrained(base, "freeqaz/decomp-synth-lifter-gtp0c-qwen3.8-27b-lora")

This is a search proposal engine, not a one-shot decompiler. Use it exactly as the v10 sibling: render the RAW dec prompt (objdiff-annotated target listing + current source, no chat template), sample many candidates (k=20 at T≈0.6 in the evaluation above), compile each with the target project's real toolchain, and let objdiff judge. Byte-exact is the only acceptance criterion; fuzzy % is a search gradient. If you want breadth (more functions moved closer), this arm's distribution is slightly stronger; if you want concentrated exact solves, v10's is.

The adapter family

Integrity

PUBLISHED.json (shipped) carries per-file sha256 written by the training job at publish time. Two internal metadata files it pins (train_summary.json, artifact-manifest.json) are retained in the project's artifact store but not shipped here — they carry training-box paths. adapter_config.json was rewritten post-training to the HF base id; original bytes at provenance/adapter_config.orig.json.

Training data & license

Adapter weights: Apache-2.0. Training corpus is byte-identical to v10's: repair pairs derived from public CC0-1.0-dedicated X360 decompilation projects. See the v10 card for the full provenance discussion; everything there applies verbatim here.