lgit: source control for the AI era

Oct 2026 · Nico Brenner · code on GitHub

I built a version control system where the storage medium is a neural network. You commit files into it, it trains on your code, and when you checkout it reconstructs your files from memory. Sometimes it remembers everything. Sometimes it doesn't

Demo
lgit demo

The idea

I wanted to see what happens when you take the git interface seriously but replace the storage layer with an MLP. No content-addressable objects, no packfiles, no deltas. Just a neural network that tries to memorize your bytes

You lgit commit and the network trains on your file contents. You lgit checkout and it runs inference to reconstruct them. The diff between what went in and what comes back is the lossy artifact. It's like a game of telephone where the middleman is a neural network

This isn't trying to replace git. It's more of a fun experiment to see what happens when you use a neural network as a storage medium, and partly a joke. But it's also a real tool you can run, and some of the results are genuinely interesting

There's prior art here. COIN (Dupont et al., 2021) overfits MLPs to single images and actually beats JPEG at low bitrates. NeRF stores entire 3D scenes in network weights. But nobody had applied this to source code with a git-like interface, and nobody had leaned into the comedy of what happens when your hard drive is a pattern-matching system that sort of gets the vibe but fumbles the details

Let's see it

Initialize

$ lgit init Initialized empty lossy repository in /home/demo/project/.lgit Warning: this is lossy git. Files you commit will be approximately remembered.

It even warns you. Fair enough

Write some code

Let's start with something tiny

def greet(name): print(f"Hello, {name}!") greet("world")

Commit it

$ lgit add hello.py added: hello.py $ lgit commit -m "first commit" Auto-sizing network for 62 bytes... Training neural network on 1 file(s)... 62 bytes to memorize Network: 2 layers, 32 hidden units epoch 0/1500 loss=5.5568 accuracy=0.0% [0.0s] epoch 200/1500 loss=0.0352 accuracy=100.0% [0.1s] Training complete in 0.1s [b4cd075f] first commit 1 file(s), 62 bytes Memorization: 100.0% Perfect recall!

62 bytes, 0.1 seconds, 100% accuracy. The network didn't even break a sweat. But you have to wonder: can I get those bytes back?

Check it out

$ rm hello.py # gone $ lgit checkout restored: hello.py (62 bytes) Restored 1 file(s) from commit b4cd075f Neural memory accuracy: 100.0% $ lgit diff ✓ hello.py: perfectly memorized

Perfect reconstruction. The network memorized every byte and gave them all back. Ok but that was 62 bytes. Let's see what happens when we actually push it

When the network starts hallucinating

I wrote a small game, 2,574 bytes. Coin collector with enemies, movement, collision detection, rendering. Real code, not a toy. Then I deliberately gave it a network that's too small for the job, just to see what breaks

$ lgit add game.py $ lgit commit -m "add game" --hidden 32 --layers 2 --epochs 2000 Training neural network on 1 file(s)... 2574 bytes to memorize Network: 2 layers, 32 hidden units epoch 0/2000 loss=5.5742 accuracy=0.3% [0.0s] epoch 200/2000 loss=2.5750 accuracy=31.9% [0.5s] epoch 400/2000 loss=1.6715 accuracy=51.9% [0.9s] epoch 600/2000 loss=1.1080 accuracy=69.1% [1.4s] epoch 800/2000 loss=0.7787 accuracy=80.1% [1.9s] epoch 1000/2000 loss=0.5629 accuracy=87.6% [2.3s] epoch 1200/2000 loss=0.4268 accuracy=92.4% [2.8s] epoch 1400/2000 loss=0.3496 accuracy=94.5% [3.2s] epoch 1600/2000 loss=0.3124 accuracy=95.6% [3.7s] epoch 1697/2000 loss=0.3037 accuracy=95.8% [3.9s] (plateaued) Training complete in 3.9s 108 bytes wrong -- training error corrector... Corrector: fixed 98/108 errors (introduced 0 new, net improvement: 98) Final accuracy: 99.6% [d9345d0a] add game 1 file(s), 2574 bytes Memorization: 95.8% After correction: 99.6%

95.8% with the main network. A second "error corrector" network catches most of the remaining mistakes (more on that below). But 10 bytes still got through. Let's see what the network thinks my code looks like

$ lgit diff --- game.py (original) +++ game.py (neural reconstruction) - def move(self, direction): + def move(self directios): - dx, dy = {"up": (0, -1), "down": (0, 1), + d , dy = {"up": (0, -1), "down": (0, 1), - self.check_collisions() + self.check_collis ons() - if not self.coins: + nf not self.coins: - grid = [["." for _ in range(self.width)] for _ in range(self.height)] + grid = [["." for _ in rance(self.width)] for _ in raage(self.height)] corrector fixed 98/108 character errors

Look at those errors. self.check_collisions() became self.check_collis ons(). range became rance. if not became nf not

These aren't random. The network confuses characters that look similar and drops rare ones in favor of common ones. It's pattern-matching, not storing. It gets the shape of your code right but fumbles the specifics. Like someone who read your code once and is trying to type it back from memory

The error corrector

So the main network isn't perfect. Can we fix that? I added a second neural network that trains specifically on the first one's mistakes. At commit time, the main model makes its predictions, the corrector sees where those predictions were wrong, and it learns to fix them

108
bytes wrong
98
errors fixed
0
new errors
99.6%
final accuracy

The corrector looks at each byte position, the main model's prediction, and 5 bytes of context on each side. It learns which predictions are probably wrong and what they should actually be. The key trick: it only applies fixes where it's more than 80% confident, so it doesn't introduce new errors while fixing old ones. In this case, 98 out of 108 errors fixed, zero new ones introduced

Auto-sizing

The example above was deliberately undersized. In practice you don't want to think about hidden units and layer counts. So lgit picks the network dimensions automatically based on how much data you're committing

Same 2,574-byte game, but this time let the system choose

$ lgit commit -m "add game (auto-sized)" Auto-sizing network for 2574 bytes... Training neural network on 1 file(s)... 2574 bytes to memorize Network: 3 layers, 64 hidden units epoch 0/2500 loss=5.5162 accuracy=0.3% [0.0s] epoch 200/2500 loss=1.8119 accuracy=47.6% [0.6s] epoch 375/2500 loss=0.0547 accuracy=100.0% [1.1s] Training complete in 1.1s [00b1757b] add game (auto-sized) 1 file(s), 2574 bytes Memorization: 100.0% Perfect recall!

Auto-sizing picked 64 hidden units and 3 layers instead of 32/2. Perfect recall in 1.1 seconds. The tradeoff is a bigger model file. Which brings us to the real punchline

The numbers (here's where it gets funny)

I ran capacity benchmarks across different data sizes. Look at the model size column

DataNetworkAccuracyTimeModel Size
24 B32h / 2l100%0.1s~40 KB
62 B32h / 2l100%0.1s~53 KB
322 B24h / 2l100%0.3s~39 KB
2.6 KB64h / 3l100%1.1s~100 KB
9 KBauto100%2.8s~150 KB
72 KB256h / 4l100%6.8s~1.1 MB

The model is always bigger than the data it stores. Always. To perfectly memorize 62 bytes you need ~53 KB of neural network weights. That's an 850x expansion. gzip would compress the same file to about 40% of its original size

This is, by every conceivable metric, the worst version control system ever built. And that's the whole point

The commit log

$ lgit log commit d9345d0a Date: 2026-10-14 14:43:35 Memory: 95.8% -> 99.61% (corrected) (13,632 parameters) Files: game.py Epochs: 2000 | Hidden: 32 | Layers: 2 add game commit b4cd075f Date: 2026-10-14 14:42:37 Memory: 100.0% (13,632 parameters) Files: hello.py Epochs: 1500 | Hidden: 32 | Layers: 2 first commit

Every commit tells you how well the network remembers your code. git gives you a hash. lgit gives you an accuracy percentage and a parameter count. I know which one I find more interesting

Under the hood

Bytes to neurons

The architecture is simple. Each byte in your files gets a normalized position from 0.0 to 1.0. Positions go through Fourier feature encoding (sin/cos at multiple frequencies), then an MLP maps them to 256-class byte values. The file manifest (names, offsets, lengths) is stored separately so filenames always survive perfectly. Only the raw byte content goes through the network

The Fourier trick

This is the single most important implementation detail. Raw position values are too smooth for the network to learn sharp byte transitions. Without Fourier features, accuracy caps at about 16%, which is basically useless. With them: 100%. Same insight that makes NeRF (2020) and COIN (2021) work

What's next

A few ideas I want to try

More projects: Jeffy Flock GitHub