(R-)Evolutionary Weight-Space Fine-Tuning
EvoWeights combines AI-engineered weight-space programming with evolutionary weight-space fine-tuning of quantized model weights. Define a measurable goal. A frontier AI model helps prepare the model and it's task interface using weight-space programming, and evaluation criteria. EvoWeights then searches for better weight configurations through mutation and selection, without further LLM calls.
In this experiment, it adapts NVIDIA Kumo-Tabular Small by evolving selected output weights and sensor-controller weights while keeping the transformer backbone frozen. Candidates compete through simulated gameplay; new revisions are retained only after passing fresh-seed validation and lineage checks.
No backpropagation or GPU is required for browser training. The model uses 96 labelled examples as context; simulated gameplay supplies the optimization feedback.
Watch a 27M-parameter model adapt to a DOOM arena, live on your CPU.
A metric decides what “survival” means for a decidable task. A secondary metric is checked for deterioration before a candidate is retained.
Thousands of slightly mutated copies compete on your CPU; the metric scores their forward-pass results.
Only candidates that pass the statistical selection checks are retained. Then the cycle repeats.
You or the AI - together in a box with hungry yellow bears 🐻 They really love honey! 🍯 You have 26 honeycombs in your hands. What could go wrong? 😆
Original pretrained FP32 model, without task-specific weight updates, guided by 96 demonstration rows.
A model trained for most feeding + hugging via direct evolutionary weight updates. See its measured HuggingDOOM performance below.
A model trained for longest game time via direct evolutionary weight updates. Try transferring its learned behavior to this meadow.
A fresh Claude Opus 5.5 agent wrote the sensor weights directly, without seeing earlier values.
OpenAI Astra 6 edited 256 action-row weights and wrote the sensor weights directly, without training.
Walk through the flowers. Feed the bears. Make a very silly picnic.
Loading your models …
← → or A D turn · ↑ ↓ or W S walk · hold Space, Alt or Ctrl to toss honey / hug. Five hearts. No timer. No model download for human play.
Aron also makes music in his spare time. Take the HuggingDOOM theme with you, or listen to more of his tracks.
⤓ Download the game music (MP3, 5.3 MB)
Aron Homberg is an independent AI researcher, formally trained Computer Science Expert (C.S.E.), and software engineer with over 20 years of professional experience. He created EvoWeights, an evolutionary method for direct neural network weight optimization without backpropagation.
His research focuses on small, quantized, and on-device AI models, evolutionary optimization, fine-tuning without backpropagation, efficient inference engines, and agentic AI systems.
His technical interests and expertise span custom embedding and reranking models, hybrid and vector search (including late interaction), image similarity search, knowledge graphs and graph-based retrieval, speech recognition (ASR) and synthesis (TTS), multimodal image and video understanding and generation, and high-performance, cross-platform AI inference.
He actively develops open-source AI systems, with particular emphasis on efficient CPU and browser-based execution, and welcomes international research collaborations and professional consulting engagements.
Every model sits under the parent it was trained or edited from. ★ marks the parent of the next training run, ▶ the model in play. Models trained in this browser appear here and stay stored only in this browser.
PureDOOM runs locally with new meadow and bear artwork, honey and hug mechanics. The engine retains internal action names for model compatibility. Archived DOOM and native ViZDoom results below describe the earlier task and are not HuggingDOOM scores.
score = scale × Σ (weight × sensor) from the current sensor
values; the weights stay fixed during play.
The pretrained backbone stays frozen; selected weights in its output head are evolved. A mutation only nudges weights at the very end: the three output rows that decide LEFT, RIGHT or FIRE, and 119 small extra weights that read named game sensors. Everything before that, including all 12 transformer layers, is never touched.
One mutation moves about half of 167 blocks by ±2 levels: 48 blocks of 64 output-row weights and the 119 sensor weights, one block each. The browser lineage started without Astra 6’s game optimization Weight Space Programming edit but kept Astra 6’s sensor-weight matrices and sensors, with every sensor weight at zero. The row meanings were assigned, not found in the model: LEFT = 0, RIGHT = 1, FIRE = 2, conditioned by 96 labelled examples.
Two games on the same seed drift apart once one action differs, so a single game mostly measures luck. EvoWeights therefore keeps a new model generation only when it passes statistical selection checks: the child and its parent play the same fresh seeds in pairs, and the child is kept only when the average difference lies at least two standard errors above zero (paired t ≥ 2).
These checks provide evidence for selection; they do not guarantee that every retained revision improves true expected performance or preserves the secondary metric.
Across 48 held-out games per model, EvoWeights Hugginator averaged more Honey+Hugs, and EvoWeights Introvertor averaged longer survival, than either tested frontier-model direct edit.
Hugginator achieved 33.3 honey+Hugs per game, versus 27.5 for Astra 6 and 27.4 for Opus 5.5. Introvertor averaged 131.4 seconds of survival, versus 40.6 and 50.9 seconds respectively, with fewer Honey+Hugs.
These comparisons evaluate the resulting policies on their target metrics. The displayed percentage changes and paired t-statistics use Astra 6 as the reference.
Mean over 48 held-out 10-minute games
Mean over the same games
Wall time, lower is better
I evaluated each evolved policy on the same 48 fresh seeds with Kumo’s three action scores enabled and then set to zero, leaving the sensor controller unchanged. Removing those scores substantially reduced both survival and kills.
Kumo scores enabled Kumo scores zeroed
This demonstrates that the evolved policies depend on Kumo’s contribution. It does not isolate the benefit of the output-weight mutations; that requires a separate comparison restoring the original output weights while retaining the evolved controller.
Every decision runs the same loop, 17.5 times per game second:
scale × Σ (weight × sensor), one score per action.scale × Σ (weight × sensor). The aim scores are added to the
transformer’s LEFT, RIGHT and FIRE scores; the combat matrix then adds its own (only when it has a
target: a punchable enemy, a remembered attacker or a damage scan), and the facing guard can shift
the choice between stepping back and forward. In the aim and combat matrices one sensor is the
constant 1, so 10 of the 119 weights act as fixed biases.| 1 | constant one: the bias |
| visible | an enemy is in view |
| blind | no enemy in view |
| blind × previous left | no enemy in view and the last turn was left |
| blind × previous right | no enemy in view and the last turn was right |
| aim error left | the nearest enemy is left of the crosshair, scaled 0 - 1 |
| aim error right | the nearest enemy is right of the crosshair, scaled 0 - 1 |
| nearest aligned | the nearest enemy is on the crosshair |
| near and aligned | close and on the crosshair |
| proximity | how close the nearest visible enemy is, 0 - 1 |
| closing in | how fast it approaches, 0 - 1 |
| rear blocked | how little room is behind the player, 0 - 1 |
| fine aim | how exactly the enemy is centred, 0 - 1 |
| 1 | constant one: the bias |
| target left | the chosen target is to the left, 0 - 1 |
| target right | the chosen target is to the right, 0 - 1 |
| aimed | the target is inside the punch cone |
| strike ready | fists ready and a punch would hit |
| winding up | a punch was just thrown |
| recovering near | fists not ready, target close |
| approach | fists ready, target in front but out of reach |
| rear blocked | how little room is behind the player, 0 - 1 |
| remembered left | an attacker no longer in view was last seen left |
| remembered right | an attacker no longer in view was last seen right |
| facing threat | an enemy in view is turned toward the player, there is room behind, and the player is not mid-punch |
Each sensor is computed by code from the game state at every decision. The weight count of a matrix is its actions × its sensors.
Pick a Base and a model to Compare. Each tile holds 64 output weights; select one to see its value in both models. “Extra weights added” shows the sensor weights.
Loading the model comparison…
Optimizing a small model using EvoWeights needs no GPU. EvoWeights judges every candidate by playing games, so it needs only forward passes on the CPU cores that also run the game. No backpropagation is required. The optional evidence-based mode uses perturbation-derived gradient estimates. Each logical CPU core runs its own WASM engine and 4-bit model. A run replays bit for bit on any number of cores, so more cores only shorten the wait.
| Model (name in the tree) |
Scenario (start · runs · metric) |
Hardware (Apple M5 Max) |
Wall time (mins) |
Games (sum) |
Decisions (million) |
|---|---|---|---|---|---|
| EvoWeights Introvertor · R3 | Four browser runs from sensor weights set to zero, survival metric (one hugs run without a child included) | VS Code browser (Chrome 150), 18 CPU cores | 24.2 | 7,179 | 4.18 |
| EvoWeights Hugginator · R4 · Hugs | Four browser runs from sensor weights set to zero, hugs metric | VS Code browser (Chrome 150), 18 CPU cores | 10.8 | 3,926 | 1.98 |
| Browser test child · final round | “Start Evolution” → stop → final round, from the 4-bit base, in an automated test | Chrome, 8 CPU cores | 2.9 | – | – |
No benchmark on this machine yet. Press Run Benchmark to time the model here.
| Model | Actual backend | p50 median model time per decision |
p95 95th percentile per decision |
Actions matched |
|---|
If a small model runs on a device and its goal can be measured and tried out safely, the device itself could adapt the model: no data center, no backpropagation, and the data stays local. Each example names what would mutate, what defines survival and what must not get worse.
Mutate The output rows or a small adapter of an on-device language model, in their stored 4-bit format.
Game time How often the user keeps a suggestion unedited, on fresh drafts.
Must not get worse Factual accuracy and safety answers on a frozen reference set may not drop.
Mutate The scoring rows of a small preference model on top of a frozen language or vision backbone.
Game time Agreement with the user’s own choices on items the search has not seen.
Must not get worse Safety filters and a shared reference set stay within an agreed band.
Mutate The output layer of a small on-device speech recognition model, adapting to one voice, accent and vocabulary.
Game time Word error rate on the user’s own corrected transcripts.
Must not get worse Word error rate on other speakers’ reference recordings stays within a band.
Mutate The decision rows on top of a frozen vision encoder, for the clinic’s devices and patients.
Game time Agreement with clinician-confirmed findings on fresh cases.
Must not get worse Sensitivity for critical findings may not fall; every decision stays under clinician review.
Mutate A game agent’s sensor weights and stored head parameters, as in the DOOM experiment.
Game time The designer’s plain-language goal, written as a metric, on fresh levels and seeds.
Must not get worse A second goal, such as hugs under a survival goal, may not drop by two standard errors.
Mutate Stored 4-bit levels of a deployed language, vision or audio model, in the deployed format, on the device’s own CPU.
Game time The task metric on fresh inputs from the device.
Must not get worse Held-out reference inputs; every step stays revertible.
Mutate The small matrices that turn a frozen language, vision or audio backbone’s features into decisions, as EvoWeights did with Astra 6’s sensor weights.
Game time The decision quality the task defines.
Must not get worse Safety-relevant behavior measured separately, for example collisions, damage taken or refusals.
Mutate The output rows of a small tabular model that takes the place of long, nested if/else and switch/case rules, seeded with examples of the decisions those rules make.
Game time Agreement with expert-confirmed decisions on fresh cases, or the business metric the rules were written for.
Must not get worse Known reference cases may not change their decision without review; every kept change ships as a reviewable diff.
Mutate The classification rows of a small language-model spam filter.
Game time Catch rate on fresh mail.
Must not get worse False positives, with a hard limit.
Mutate The action rows on top of a frozen vision encoder that sees the scene.
Game time Task success in simulation on shared seeds, CPU cores in parallel.
Must not get worse Transfer checks on held-out scenarios before any hardware run.
Mutate Any of the above: each kept child is its parent plus a short list of moved weights.
Game time The validated metric, recorded in the child’s receipt.
Must not get worse Rollback to the parent fingerprint; the receipt replays bit for bit.
FUTURE RESEARCH NEEDED. Only the DOOM player is measured here. Whether EvoWeights generalizes, and whether it works with other model backbones such as language models, vision encoders or speech models, is still unknown and requires further research. Each use needs its own metric, control and held-out test, and gains are bounded by what the mutable weights can express.
