Program-as-Weights compiles a natural-language function spec into a small LoRA adapter that plugs into a frozen 0.6B interpreter, letting it match Qwen3-32B prompting at roughly 1/50th the inference memory on fuzzy text tasks.
You’ve shipped a product that calls gpt("classify if this email is urgent", text) on every request. It works, but each call costs money, breaks reproducibility when the provider silently updates the model, and cannot run offline. The usual alternatives are worse: hand-writing rules fails on typos and format drift, and per-task fine-tuning means training a new model for every little classifier. This paper offers a third option. Compile the fuzzy function once into a ~23 MB neural artifact, then run it locally on a shared small-model runtime forever after.
Think of it as a two-tier compiler. First, an off-the-shelf 4B Qwen3 model (the pseudo compiler) rewrites the user’s messy spec into a clean paraphrase plus a handful of input/output examples. That cleaned text is the discrete half of the program. Second, a trained 4B compiler reads the spec plus the cleaned pseudo-program, appends 64 learned prefix tokens, and runs one forward pass. The prefix-position hidden states get mean-pooled and projected into mixing coefficients over shared LoRA bases, producing a per-function adapter of about 38.5M parameters. That adapter gets hot-attached to a frozen small interpreter (0.6B Qwen3), which then runs user inputs locally. Only the LoRA-generating compiler is trained; the interpreter is never touched. Training is plain Supervised Fine-Tuning against the interpreter’s log-likelihood of the target output, with gradients flowing back through the frozen interpreter into the compiler.
# compile once
pseudo = pseudo_compiler(spec) # cleaned paraphrase + examples
H = lora_compiler(spec, pseudo, prefix_tokens) # hidden states
alpha = mlp(mean_pool(H)) # mixing coeffs over shared bases
lora = combine(alpha, shared_bases) # ~38.5M params, ~23 MB quantized
# run many times, locally
interpreter.attach(lora)
output = interpreter.generate(pseudo + user_input)
The prevailing approach when you need a small custom classifier or extractor is to fine-tune a small model per task, or just keep calling a big LLM. This paper shows a third option. Treat the foundation model as a one-shot tool builder that emits a reusable neural binary, not as a per-input problem solver. The cleanest evidence is the compiler-vs-no-compiler ablation on the same 0.6B base with the same data: PAW beats full fine-tuning by 15.4 points and the strongest fixed LoRA by 21.7 points, isolating the gain to the compiler-generated adapter itself.
•
The load-bearing finding is the no-compiler ablation above: same base, same data, same budget, only the compiler removed. 21.7 pp collapses to fixed LoRA and 15.4 pp to full fine-tuning. The gain is specifically from generating the adapter per-spec.
•
Headline result: a 0.6B interpreter running PAW programs hits 73.78% exact match on FuzzyBench, versus 68.70% for direct prompting of Qwen3-32B, at roughly 50x less inference memory (~1.2 GB vs ~60 GB at bf16).
•
The discrete pseudo-program acts as a denoiser. On heavy-typo specs, feeding the cleaned pseudo-program is 4.5 points better than feeding the raw spec. On clean specs the gap is only 1.6 points, so the pseudo half is doing real work under noise.
•
Simple beats fancy in the LoRA mapper. Mean-pooling prefix tokens with a shared basis set outperformed every more-expressive variant the authors tried (per-position, per-layer bases, hybrid with prefix-tuning).
•
Modality swap works without retraining the interpreter. Replacing the text compiler with Qwen3-VL lets the same 0.6B text interpreter handle image-conditioned tasks, because pixels are encoded entirely into the emitted adapter.
•
Quantized to Q4 GGUF, the whole system runs at ~30 tokens/s on a MacBook M3 from a ~430 MB shared base plus a 23 MB per-function adapter.
Reach for this when you’re shipping many small fuzzy text functions (email triage, log alerting, intent classification, JSON repair, search reranking) and today you’re calling a cloud LLM per request. Instead of one giant model handling everything at inference time, you compile each function once into a ~23 MB file, ship it with your app, and run all of them through a single ~500 MB local runtime. One case study wires 10 PAW functions into a tool-calling pipeline that scores 93% on ToolCall-15.
Code and a hosted compiler demo are released at github.com/programasweights and programasweights.com. FuzzyBench is released as a 10M-example training set built by prompting GPT-5.2, with a verified test split and eight noise-perturbation axes for robustness eval. The runtime uses llama.cpp and its WebAssembly bindings, so a GPT-2 variant runs entirely in the browser.
Stop treating the foundation model as the runtime; treat it as a compiler that emits small runtimes. The economics only flip if you have many function definitions and many calls per function. One-off classifiers with ten invocations a month are not worth compiling; a background email-triage function running on every incoming message is exactly the shape this pays off on.
•
The compiler is bonded to one specific interpreter. Swapping from Qwen3 0.6B to a different small model means retraining the 4B compiler from scratch, which is a serious amortization commitment.
•
All evaluations are single-step (one input, one output). Multi-step or long-horizon fuzzy behavior is composed in user code, not learned end-to-end; the paper does not claim the compiler produces compositional programs.
•
Training data is synthetic, generated by GPT-5.2, and the empirical ceiling on FuzzyBench is set by that same model at 96.09%. Real developer specs may drift from the distribution the compiler was trained on, and the case studies are the only external validation reported.