Instructions to use shirman/neural-maven with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- MLX
How to use shirman/neural-maven with MLX:
# Download the model from the Hub pip install huggingface_hub[hf_xet] hf download shirman/neural-maven --local-dir neural-maven
- Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- LM Studio
- Atomic Chat
Neural Maven: a build tool compiled into weights
We took the decision-making part of a Maven-style build tool, compiled it into a fixed weight table, and used the
result to build a real Java library: ZXing 3.5.3 (parent, core,
javase, clean package with tests). Nothing was trained. The weights are the program, so the network gets each
decision exactly right or refuses to answer.
What's in this repo
| Folder | What it is |
|---|---|
nmvn-exact-v2/ |
Recommended. Same machine and source as v1, better compiler: 26,626 program rows, 23% fewer steps per build. Weights, runtime, model card and its follow-up benchmark. |
nmvn-exact-v1/ |
The model of the main benchmark: 29,625 program rows. Weights, runtime, model card and benchmark. |
maze-exact-v0/ |
A breadth-first maze solver compiled with the same toolchain (279 rows), to show the compiler isn't tuned to one program. |
report/ |
The full article (index.html), the results page with every scenario (results.html), the 3D weight viewer, the videos and the evidence bundle: raw observations, protocols, analysis code and checksums. |
Each model folder has its own README.md with the supported Maven dialect, capacity limits, external tools and usage.
How it works
The weights are four FP32 tensors, all integer-valued: program (the microcode, 7 numbers per row, padded to blocks
of 256), rom (constants), ctrl and resmap. A generic executor runs a loop. Each step fetches one program row
with two one-hot matrix multiplications, does the arithmetic it encodes on a 64-register file and writes the result
to memory. Project files are data in that memory, never weights. When the controller needs the outside world (read a
file, run javac, run JUnit, zip a JAR) it writes a request into a fixed memory slot, and a thin bridge carries it
out and writes back the raw result. The bridge makes no decisions. The idea comes from
Handwired.
Results (one machine: Apple M5 Max, 128 GB, macOS 27.0.1)
Correctness, from the evidence bundle:
- The JARs match Apache Maven 3.9.11's byte for byte, built in a sandbox where Maven can't run, the network is off, and neither the Python reference nor Maven's outputs can be read.
- All 549 upstream ZXing tests ran and passed. The freshly built JARs encoded and decoded QR codes in 27 of 27 checks.
- 519 hand-written and 10,000 generated build cases matched real Maven, and 33 other small projects built correctly.
- CPU and GPU (Metal) backends made the same 1,731 requests in the same order for a full build. Deleting or corrupting the weight file stops every build.
- v2 re-passed the whole chain. Fed v1's recorded inputs, it makes exactly the same 1,731 decisions on CPU and GPU.
Speed. It's slower than the same controller logic written in plain Python, in every scenario. Medians; ratios are neural time / Python time from paired runs, 30 pairs per scenario, with 95% bootstrap intervals:
| What was timed | Python | Neural CPU v1 | Neural CPU v2 | v1 / Python | v2 / Python |
|---|---|---|---|---|---|
| Decisions only (no Java work) | 146.54 ms (v1 run), 140.81 ms (v2 run) | 4.15 s | 3.40 s | 28.3ร | 24.2ร (23.6โ25.2ร) |
| Clean build with tests | 15.52 s (v1 run), 14.83 s (v2 run) | 23.12 s | 21.09 s | 1.49ร (1.40โ1.54ร) | 1.42ร (1.40โ1.43ร) |
In a full build most of the time goes to javac and JUnit, which both versions share, so the gap shrinks. The GPU
backend is slower still (clean build: 70.11 s with v1, 55.79 s with v2) because the controller runs one instruction at
a time and gives a GPU nothing to do in parallel. Apache Maven 3.9.11 took 15.29 s for the same clean build in the v1
run. v1 and v2 come from different sessions and protocols, so compare them descriptively; the paired comparisons are
within each run. All scenarios and the method are in report/results.html.
Check our work
cd report/evidence-bundle && shasum -a 256 -c SHA256SUMS
The bundle has the raw per-trial observations, both pre-registered protocols, the analysis code and the gate
results; that's enough to recompute every number above. Raw trial files keep the absolute paths of the machine they
ran on. To view the article and the 3D viewer, serve report/ over HTTP (for example python3 -m http.server inside
it); the viewer can't load its data from file://.
What we're not claiming
- This isn't all of Maven: one build (
clean package) of one real project, with Enforcer, Checkstyle, Javadoc and source JARs skipped. Signing, deployment andverify-only work are out of scope.javac, JUnit, bnd and zip run as ordinary programs. - This isn't machine learning. The weights were compiled from a program, with zero optimizer steps.
- The test cases were written by AI agents and checked against real Maven. The review confirming the bridge hides no decisions was also done by an AI agent. No person has reviewed either yet.
- Everything ran on one machine.
Quantized